- 16 May, 2024 1 commit
-
-
Russell King (Oracle) authored
-
- 15 May, 2024 1 commit
-
-
Geert Uytterhoeven authored
Booting an LPAE-enabled kernel built with CONFIG_CC_OPTIMIZE_FOR_SIZE=y fails when starting userspace: Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 1 PID: 1 Comm: init Tainted: G W N 6.9.0-rc1-koelsch-00004-g7af5b901 #1930 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x78/0xa8 dump_stack_lvl from panic+0x118/0x398 panic from do_exit+0x1ec/0x938 do_exit from sys_exit_group+0x0/0x10 ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 ]--- Add the missing memory clobber to cpu_set_ttbcr(), as suggested by Russell King. Force inlining of uaccess_save_and_enable(), as suggested by Ard Biesheuvel. The latter fixes booting on Koelsch. Closes: https://lore.kernel.org/r/CAMuHMdWTAJcZ9BReWNhpmsgkOzQxLNb5OhNYxzxv6D5TSh2fwQ@mail.gmail.com/ Fixes: 7af5b901 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement") Acked-by:Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
-
- 08 May, 2024 1 commit
-
-
Russell King (Oracle) authored
Report an error when an attempt to register a clkdev entry results in a truncated string so the problem can be easily spotted. Reported by: Duanqiang Wen <duanqiangwen@net-swift.com> Signed-off-by:
-
- 07 May, 2024 1 commit
-
-
Linus Walleij authored
Commit 9385/2 introduced a few branches inside function prototypes when using CFI in order to deal with the situation where CFI inserts a few bytes of function information in front of the symbol. This is not good for older CPUs where every cycle counts. Commit 9386/2 alleviated the situation a bit by using aliases for the cache functions with identical signatures. This leaves the coherent cache flush functions *_coherent_kern_range() with these branches to the corresponing *_coherent_user_range() around, since their return type differ and they therefore cannot be aliased. Solve this by a simple ifdef so at least we can use fallthroughs when compiling without CFI enabled. Link: https://lore.kernel.org/linux-arm-kernel/Zi+e9M%2Ff5b%2FSto9H@shell.armlinux.org.uk/Suggested-by:
-
- 29 Apr, 2024 9 commits
-
-
Linus Walleij authored
Support Control Flow Integrity (CFI) when compiling with CLANG. In the as-of-writing LLVM CLANG implementation (v17) the 32-bit ARM platform is supported by the generic CFI implementation, which isn't tailored specifically for ARM32 but works well enough to enable the feature. Tested-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
-
Linus Walleij authored
This registers a breakpoint handler for the new breakpoint type (0x03) inserted by LLVM CLANG for CFI breakpoints. If we are in permissive mode, just print a backtrace and continue. Example with CONFIG_CFI_PERMISSIVE enabled: > echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT lkdtm: Performing direct entry CFI_FORWARD_PROTO lkdtm: Calling matched prototype ... lkdtm: Calling mismatched prototype ... CFI failure at lkdtm_indirect_call+0x40/0x4c (target: 0x0; expected type: 0x00000000) WARNING: CPU: 1 PID: 112 at lkdtm_indirect_call+0x40/0x4c CPU: 1 PID: 112 Comm: sh Not tainted 6.8.0-rc1+ #150 Hardware name: ARM-Versatile Express (...) lkdtm: FAIL: survived mismatched prototype function call! lkdtm: Unexpected! This kernel (6.8.0-rc1+ armv7l) was built with CONFIG_CFI_CLANG=y As you can see the LKDTM test fails, but I expect that this would be expected behaviour in the permissive mode. We are currently not implementing target and type for the CFI breakpoint as this requires additional operand bundling compiler extensions. CPUs without breakpoint support cannot handle breakpoints naturally, in these cases the permissive mode will not work, CFI will fall over on an undefined instruction: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT ARM CPU: 0 PID: 186 Comm: ash Tainted: G W 6.9.0-rc1+ #7 Hardware name: Gemini (Device Tree) PC is at lkdtm_indirect_call+0x38/0x4c LR is at lkdtm_CFI_FORWARD_PROTO+0x30/0x6c This is reasonable I think: it's the best CFI can do to ascertain the the control flow is not broken on these CPUs. Reviewed-by:
-
Linus Walleij authored
When we annotate the loop delay code with SYM_TYPED_FUNC_START() a function prototype signature will be emitted into the object file above each site called from C, and the delay loop code is using "fallthroughs" from the different assembly callbacks. This will not work as the execution flow will run into the prototype signatures. Rewrite the code to use explicit branches to the other code segments and annotate the code using SYM_TYPED_FUNC_START(). Tested on the ARM Versatile which uses the calibrated loop delay. Tested-by:
-
Linus Walleij authored
Each CPU type ("proc") has assembly calls for initializing and setting up the MM context, idle and so forth. These calls have the C form of e.g.: void cpu_arm920_init(void); However this prototype is not really specified, instead it is generated by the glue code in <asm/glue-proc.h> and the prototype is implicit from the generic prototype defined in <asm/proc-fns.h> such as cpu_proc_init() in this case. (This is a bit similar to the "interface" or inheritance concept in other languages.) To be able to annotate these assembly calls for CFI, they all need to have a proper C prototype per CPU call. Define these in a new C file that is only compiled when we use CFI, and add __ADDRESSABLE() to each so the compiler knows that these will be addressed (they are not explicitly called in C, they are called by way of cpu_proc_init() etc). It is a bit of definitions, but we do not expect new ARM32 CPUs to appear very much so it should be pretty static. Tested-by: -
Linus Walleij authored
Type tag the remaining per-processor assembly using the CFI symbol macros, in addition to those that were previously tagged for cache maintenance calls. This will be used to finally provide proper C prototypes for all these calls as well so that CFI can be made to work. Tested-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Linus Walleij authored
Instead of defining all cache flush operations with an assembly macro in proc-macros.S, provide an explicit struct cpu_cache_fns for each CPU cache type in mm/cache.c. As a side effect from rewriting the vtables in C, we can avoid the aliasing for the "louis" cache callback, instead we can just assign the NN_flush_kern_cache_all() function to the louis callback in the C vtable. As the louis cache callback is called explicitly (not through the vtable) if we only have one type of cache support compiled in, we need an ifdef quirk for this in the !MULTI_CACHE case. Feroceon and XScale have some dma mapping quirk, in this case we can just define two structs and assign all but one callback to the main implementation; since each of them invoked define_cache_functions twice they require MULTI_CACHE by definition so the compiled-in shortcut is not used on these variants. Tested-by:
-
Linus Walleij authored
The cache functions to flush user cache (*_flush_user_cache_all) are in many cases just a branch to the corresponfing userspace or kernelspace function. These functions also have the same arguments. Simplify these by using SYM_FUNC_ALIAS() in all affected sites. The NOP cache has very many similar calls which are just returns, but it would be confusing to use aliases here, so leave all the explicit returns and drop a comment on why we are not using aliases. Reviewed-by:
-
Linus Walleij authored
Tag all references to assembly functions with SYM_TYPED_FUNC_START() and SYM_FUNC_END() so they also become CFI-safe. When we add SYM_TYPED_FUNC_START() to assembly calls, a function prototype signature will be emitted into the object file at (pc-4) at the call site, so that the KCFI runtime check can compare this to the expected call. Example: 8011ae38: a540670c .word 0xa540670c 8011ae3c <v7_flush_icache_all>: 8011ae3c: e3a00000 mov r0, #0 8011ae40: ee070f11 mcr 15, 0, r0, cr7, cr1, {0} 8011ae44: e12fff1e bx lr This means no "fallthrough" code can enter a SYM_TYPED_FUNC_START() call from above it: there will be a function prototype signature there, so those are consistently converted to a branch or ret lr depending on context. Tested-by: -
Ard Biesheuvel authored
Instead of avoiding CFI entirely on the TLB flush helpers, reorganize the code so that the CFI machinery can deal with it. The important things to take into account are: - functions in asm called indirectly from C need to be defined using SYM_TYPED_FUNC_START() - a reference to the asm function needs to be visible to the compiler, in order to get it to emit the typeid symbol. The latter means that defining the cpu_tlb_fns structs is best done from C code, so that the references in the static initializers will be visible to the compiler. Signed-off-by:
-
- 18 Apr, 2024 24 commits
-
-
Linus Walleij authored
Several architectures defines this stub for the graph tracer, and it is needed for CFI, as it needs a separate symbol for it. The trick from include/asm-generic/vmlinux.lds.h to define ftrace_stub_graph to ftrace_stub isn't working when using CFI. Commit 883bbbff contains the details. Tested-by:
-
Linus Walleij authored
With LPAE enabled, privileged no-access cannot be enforced using CPU domains as such feature is not available. This patch implements PAN by disabling TTBR0 page table walks while in kernel mode. The ARM architecture allows page table walks to be split between TTBR0 and TTBR1. With LPAE enabled, the split is defined by a combination of TTBCR T0SZ and T1SZ bits. Currently, an LPAE-enabled kernel uses TTBR0 for user addresses and TTBR1 for kernel addresses with the VMSPLIT_2G and VMSPLIT_3G configurations. The main advantage for the 3:1 split is that TTBR1 is reduced to 2 levels, so potentially faster TLB refill (though usually the first level entries are already cached in the TLB). The PAN support on LPAE-enabled kernels uses TTBR0 when running in user space or in kernel space during user access routines (TTBCR T0SZ and T1SZ are both 0). When running user accesses are disabled in kernel mode, TTBR0 page table walks are disabled by setting TTBCR.EPD0. TTBR1 is used for kernel accesses (including loadable modules; anything covered by swapper_pg_dir) by reducing the TTBCR.T0SZ to the minimum (2^(32-7) = 32MB). To avoid user accesses potentially hitting stale TLB entries, the ASID is switched to 0 (reserved) by setting TTBCR.A1 and using the ASID value in TTBR1. The difference from a non-PAN kernel is that with the 3:1 memory split, TTBR1 always uses 3 levels of page tables. As part of the change we are using preprocessor elif definied() clauses so balance these clauses by converting relevant precedingt ifdef clauses to if defined() clauses. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
-
Linus Walleij authored
This is a clean-up patch aimed at reducing the number of checks on CONFIG_CPU_SW_DOMAIN_PAN, together with some empty lines for better clarity once the CONFIG_CPU_TTBR0_PAN is introduced. Signed-off-by:
-
Linus Walleij authored
This patch implements cpu_get_ttbcr() and cpu_set_ttbcr() and replaces the corresponding asm statements. Signed-off-by:
-
Linus Walleij authored
These macros will be used in a subsequent patch. At one point these were part of the ARM32 KVM but that is no longer the case. Since these macros are only relevant to LPAE kernel builds, they are added to pgtable-3level-hwdef.h Signed-off-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-11-4517b091385b@linaro.orgAcked-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-5-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-15-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-12-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-9-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-8-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-6-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-18-4517b091385b@linaro.orgReviewed-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-2-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-19-4517b091385b@linaro.orgReviewed-by:
Eric Auger <eric.auger@redhat.com> Acked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-17-4517b091385b@linaro.orgAcked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-16-4517b091385b@linaro.orgAcked-by:
Vinod Koul <vkoul@kernel.org> Acked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-14-4517b091385b@linaro.orgAcked-by:
Andi Shyti <andi.shyti@kernel.org> Acked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-13-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-10-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-7-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-4-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Amba bus core already sets owner, so driver does not need to. Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-3-4517b091385b@linaro.orgAcked-by:
-
Krzysztof Kozlowski authored
Modules registering driver with amba_driver_register() often forget to set .owner field. The field is used by some of other kernel parts for reference counting (try_module_get()), so it is expected that drivers will set it. Solve the problem by moving this task away from the drivers to the core amba bus code, just like we did for platform_driver in commit 9447057e ("platform_device: use a macro instead of platform_driver_register"). Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-1-4517b091385b@linaro.orgReviewed-by:
-
- 24 Mar, 2024 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds authored
Pull EFI fixes from Ard Biesheuvel: - Fix logic that is supposed to prevent placement of the kernel image below LOAD_PHYSICAL_ADDR - Use the firmware stack in the EFI stub when running in mixed mode - Clear BSS only once when using mixed mode - Check efi.get_variable() function pointer for NULL before trying to call it * tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: fix panic in kdump kernel x86/efistub: Don't clear BSS twice in mixed mode x86/efistub: Call mixed mode boot services on the firmware's stack efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min or higher address
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: - Ensure that the encryption mask at boot is properly propagated on 5-level page tables, otherwise the PGD entry is incorrectly set to non-encrypted, which causes system crashes during boot. - Undo the deferred 5-level page table setup as it cannot work with memory encryption enabled. - Prevent inconsistent XFD state on CPU hotplug, where the MSR is reset to the default value but the cached variable is not, so subsequent comparisons might yield the wrong result and as a consequence the result prevents updating the MSR. - Register the local APIC address only once in the MPPARSE enumeration to prevent triggering the related WARN_ONs() in the APIC and topology code. - Handle the case where no APIC is found gracefully by registering a fake APIC in the topology code. That makes all related topology functions work correctly and does not affect the actual APIC driver code at all. - Don't evaluate logical IDs during early boot as the local APIC IDs are not yet enumerated and the invoked function returns an error code. Nothing requires the logical IDs before the final CPUID enumeration takes place, which happens after the enumeration. - Cure the fallout of the per CPU rework on UP which misplaced the copying of boot_cpu_data to per CPU data so that the final update to boot_cpu_data got lost which caused inconsistent state and boot crashes. - Use copy_from_kernel_nofault() in the kprobes setup as there is no guarantee that the address can be safely accessed. - Reorder struct members in struct saved_context to work around another kmemleak false positive - Remove the buggy code which tries to update the E820 kexec table for setup_data as that is never passed to the kexec kernel. - Update the resource control documentation to use the proper units. - Fix a Kconfig warning observed with tinyconfig * tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/boot/64: Move 5-level paging global variable assignments back x86/boot/64: Apply encryption mask to 5-level pagetable update x86/cpu: Add model number for another Intel Arrow Lake mobile processor x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Documentation/x86: Document that resctrl bandwidth control units are MiB x86/mpparse: Register APIC address only once x86/topology: Handle the !APIC case gracefully x86/topology: Don't evaluate logical IDs during early boot x86/cpu: Ensure that CPU info updates are propagated on UP kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address x86/pm: Work around false positive kmemleak report in msr_build_context() x86/kexec: Do not update E820 kexec table for setup_data x86/config: Fix warning for 'make ARCH=x86_64 tinyconfig'
-
