Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2 2022-10-19T16:25:39+00:00 2022-10-19T16:25:39+00:00 Guilherme G. Piccoli gpiccoli@igalia.com 2022-10-13T21:06:46+00:00 urn:sha1:38b91847c314f49c80e30062549d4709a3754ea6 The pstore dump function doesn't alert at all on errors - despite pstore is usually a last resource and if it fails users won't be able to read the kernel log, this is not the case for server users with serial access, for example. So, let's at least attempt to inform such advanced users on the first backend writing error detected during the kmsg dump - this is also very useful for pstore debugging purposes. Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221013210648.137452-2-gpiccoli@igalia.com 2022-10-17T20:14:10+00:00 Guilherme G. Piccoli gpiccoli@igalia.com 2022-10-06T22:42:07+00:00 urn:sha1:6a14f1982e6b476c84938c9ca011d258a6bba24d Currently we only show the registered ones in the kernel log; users that change backend for some reason require first to unregister the current one, so let's confirm this operation with a message in the log. Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221006224212.569555-4-gpiccoli@igalia.com 2022-10-17T20:14:10+00:00 Guilherme G. Piccoli gpiccoli@igalia.com 2022-10-06T22:42:06+00:00 urn:sha1:8f5de3fd38b7e64112017bb1630f9df6e1b3331d Currently this tuning is only exposed as a filesystem option, but most Linux distros automatically mount pstore, hence changing this setting requires remounting it. Also, if that mount option wasn't explicitly set it doesn't show up in mount information, so users cannot check what is the current value of kmsg_bytes. Let's then expose it as a module parameter, allowing both user visibility at all times (even if not manually set) and also the possibility of setting that as a boot/module parameter. Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221006224212.569555-3-gpiccoli@igalia.com 2022-10-17T20:14:10+00:00 Guilherme G. Piccoli gpiccoli@igalia.com 2022-10-06T22:42:05+00:00 urn:sha1:d85644dc5cf4023bf1a325f476d58a16bcc0798b The pstore infrastructure supports one single backend at a time; trying to load a another backend causes an error and displays a message, introduced on commit 0d7cd09a3dbb ("pstore: Improve register_pstore() error reporting"). Happens that this message is not really clear about the situation, also the current error returned (-EPERM) isn't accurate, whereas -EBUSY makes more sense. We have another place in the code that relies in the -EBUSY return for a similar check. So, make it consistent here by returning -EBUSY and using a similar message in both scenarios. Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221006224212.569555-2-gpiccoli@igalia.com 2022-09-30T15:16:06+00:00 Guilherme G. Piccoli gpiccoli@igalia.com 2022-09-29T21:55:15+00:00 urn:sha1:40158dbf7eb2b13d8851fe0b875b4c3170ea15db This reverts commit e4f0a7ec586b7644107839f5394fb685cf1aadcc. When using this new interface, both efi_pstore and ramoops backends are unable to properly decompress dmesg if using zstd, lz4 and lzo algorithms (and maybe more). It does succeed with deflate though. The message observed in the kernel log is: [2.328828] pstore: crypto_acomp_decompress failed, ret = -22! The pstore infrastructure is able to collect the dmesg with both backends tested, but since decompression fails it's unreadable. With this revert everything is back to normal. Fixes: e4f0a7ec586b ("pstore: migrate to crypto acomp interface") Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220929215515.276486-1-gpiccoli@igalia.com 2022-08-03T21:38:02+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-08-03T21:38:02+00:00 urn:sha1:97a77ab14ffac749ec2419c92ec2954111c22d22 Pull EFI updates from Ard Biesheuvel: - Enable mirrored memory for arm64 - Fix up several abuses of the efivar API - Refactor the efivar API in preparation for moving the 'business logic' part of it into efivarfs - Enable ACPI PRM on arm64 * tag 'efi-next-for-v5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (24 commits) ACPI: Move PRM config option under the main ACPI config ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64 ACPI: PRM: Change handler_addr type to void pointer efi: Simplify arch_efi_call_virt() macro drivers: fix typo in firmware/efi/memmap.c efi: vars: Drop __efivar_entry_iter() helper which is no longer used efi: vars: Use locking version to iterate over efivars linked lists efi: pstore: Omit efivars caching EFI varstore access layer efi: vars: Add thin wrapper around EFI get/set variable interface efi: vars: Don't drop lock in the middle of efivar_init() pstore: Add priv field to pstore_record for backend specific use Input: applespi - avoid efivars API and invoke EFI services directly selftests/kexec: remove broken EFI_VARS secure boot fallback check brcmfmac: Switch to appropriate helper to load EFI variable contents iwlwifi: Switch to proper EFI variable store interface media: atomisp_gmin_platform: stop abusing efivar API efi: efibc: avoid efivar API for setting variables efi: avoid efivars layer when loading SSDTs from variables efi: Correct comment on efi_memmap_alloc memblock: Disable mirror feature if kernelcore is not specified ... 2022-06-24T18:40:04+00:00 Ard Biesheuvel ardb@kernel.org 2022-06-22T07:31:31+00:00 urn:sha1:8ca869b24538a7b5501af368e87e4a59b0c04117 The EFI pstore backend will need to store per-record variable name data when we switch away from the efivars layer. Add a priv field to struct pstore_record, and document it as holding a backend specific pointer that is assumed to be a kmalloc()d buffer, and will be kfree()d when the entire record is freed. Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2022-05-12T16:31:00+00:00 Ard Biesheuvel ardb@kernel.org 2022-04-26T17:56:18+00:00 urn:sha1:e4f0a7ec586b7644107839f5394fb685cf1aadcc The crypto 'compress' interface is deprecated, so before adding new features, migrate to the acomp interface. Note that we are only using synchronous implementations of acomp, so we don't have to deal with asynchronous completion. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> 2022-03-15T18:08:23+00:00 Jann Horn jannh@google.com 2022-03-14T18:59:53+00:00 urn:sha1:8126b1c73108bc691f5643df19071a59a69d0bc6 pstore_dump() is *always* invoked in atomic context (nowadays in an RCU read-side critical section, before that under a spinlock). It doesn't make sense to try to use semaphores here. This is mostly a revert of commit ea84b580b955 ("pstore: Convert buf_lock to semaphore"), except that two parts aren't restored back exactly as they were: - keep the lock initialization in pstore_register - in efi_pstore_write(), always set the "block" flag to false - omit "is_locked", that was unnecessary since commit 959217c84c27 ("pstore: Actually give up during locking failure") - fix the bailout message The actual problem that the buggy commit was trying to address may have been that the use of preemptible() in efi_pstore_write() was wrong - it only looks at preempt_count() and the state of IRQs, but __rcu_read_lock() doesn't touch either of those under CONFIG_PREEMPT_RCU. (Sidenote: CONFIG_PREEMPT_RCU means that the scheduler can preempt tasks in RCU read-side critical sections, but you're not allowed to actively block/reschedule.) Lockdep probably never caught the problem because it's very rare that you actually hit the contended case, so lockdep always just sees the down_trylock(), not the down_interruptible(), and so it can't tell that there's a problem. Fixes: ea84b580b955 ("pstore: Convert buf_lock to semaphore") Cc: stable@vger.kernel.org Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220314185953.2068993-1-jannh@google.com 2021-11-09T00:55:21+00:00 Nick Terrell terrelln@fb.com 2020-09-11T23:49:00+00:00 urn:sha1:cf30f6a5f0c60ec98a637b836bef6915f602c6ab This patch: - Moves `include/linux/zstd.h` -> `include/linux/zstd_lib.h` - Updates modified zstd headers to yearless copyright - Adds a new API in `include/linux/zstd.h` that is functionally equivalent to the in-use subset of the current API. Functions are renamed to avoid symbol collisions with zstd, to make it clear it is not the upstream zstd API, and to follow the kernel style guide. - Updates all callers to use the new API. There are no functional changes in this patch. Since there are no functional change, I felt it was okay to update all the callers in a single patch. Once the API is approved, the callers are mechanically changed. This patch is preparing for the 3rd patch in this series, which updates zstd to version 1.4.10. Since the upstream zstd API is no longer exposed to callers, the update can happen transparently. Signed-off-by: Nick Terrell <terrelln@fb.com> Tested By: Paul Jones <paul@pauljones.id.au> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v13.0.0 on x86-64 Tested-by: Jean-Denis Girard <jd.girard@sysnux.pf>