aboutsummaryrefslogtreecommitdiffstatshomepage
AgeCommit message (Collapse)AuthorFilesLines
2024-05-16Merge branches 'amba', 'cfi', 'clkdev' and 'misc' into for-linusRussell King (Oracle)64-989/+2591
2024-05-15ARM: 9398/1: Fix userspace enter on LPAE with CC_OPTIMIZE_FOR_SIZE=yGeert Uytterhoeven2-2/+2
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-g7af5b901e847 #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: 7af5b901e84743c6 ("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>
2024-05-08clkdev: report over-sized strings when creating clkdev entriesRussell King (Oracle)1-2/+33
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: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-05-07ARM: 9393/1: mm: Use conditionals for CFI branchesLinus Walleij20-0/+42
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: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9392/2: Support CLANG CFILinus Walleij1-0/+1
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 <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9391/2: hw_breakpoint: Handle CFI breakpointsLinus Walleij2-0/+36
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: Kees Cook <keescook@chromium.org> Tested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9390/2: lib: Annotate loop delay instructions for CFILinus Walleij1-6/+10
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: Kees Cook <keescook@chromium.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9389/2: mm: Define prototypes for all per-processor callsLinus Walleij2-0/+501
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: Kees Cook <keescook@chromium.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9388/2: mm: Type-annotate all per-processor assembly routinesLinus Walleij26-274/+434
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: Kees Cook <keescook@chromium.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9387/2: mm: Rewrite cacheflush vtables in CFI safe CLinus Walleij27-259/+688
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: Kees Cook <keescook@chromium.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9386/2: mm: Use symbol alias for cache functionsLinus Walleij19-54/+22
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: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9385/2: mm: Type-annotate all cache assembly routinesLinus Walleij22-373/+544
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: Kees Cook <keescook@chromium.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-29ARM: 9384/2: mm: Make tlbflush routines CFI safeArd Biesheuvel9-58/+119
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: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9382/1: ftrace: Define ftrace_stub_graphLinus Walleij1-0/+4
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 883bbbffa5a4 contains the details. Tested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablementLinus Walleij10-6/+155
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: Kees Cook <keescook@chromium.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9357/2: Reduce the number of #ifdef CONFIG_CPU_SW_DOMAIN_PANLinus Walleij2-10/+27
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: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9356/2: Move asm statements accessing TTBCR into C functionsLinus Walleij2-4/+15
This patch implements cpu_get_ttbcr() and cpu_set_ttbcr() and replaces the corresponding asm statements. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9355/2: Add TTBCR_* definitions to pgtable-3level-hwdef.hLinus Walleij1-0/+17
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: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9379/1: coresight: tpda: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9378/1: coresight: etm4x: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9377/1: hwrng: nomadik: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9376/1: coresight: tpdm: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9375/1: coresight: stm: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9374/1: coresight: etb10: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9373/1: coresight: funnel: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9372/1: memory: pl353-smc: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9371/1: coresight: cti: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9370/1: vfio: amba: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9369/1: Input: ambakmi - drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9368/1: dmaengine: pl330: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Vinod Koul <vkoul@kernel.org> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9367/1: i2c: nomadik: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9366/1: coresight: tpiu: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9365/1: coresight: tmc: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9364/1: coresight: replicator: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9363/1: coresight: etm3x: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9362/1: coresight: catu: drop owner assignmentKrzysztof Kozlowski1-1/+0
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.org Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-04-18ARM: 9361/1: amba: store owner from modules with amba_driver_register()Krzysztof Kozlowski2-6/+16
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 9447057eaff8 ("platform_device: use a macro instead of platform_driver_register"). Link: https://lore.kernel.org/r/20240326-module-owner-amba-v1-1-4517b091385b@linaro.org Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-03-24Linux 6.9-rc1Linus Torvalds1-2/+2
2024-03-24Merge tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds4-2/+14
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
2024-03-24Merge tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds15-89/+80
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'
2024-03-24Merge tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-0/+3
Pull scheduler doc clarification from Thomas Gleixner: "A single update for the documentation of the base_slice_ns tunable to clarify that any value which is less than the tick slice has no effect because the scheduler tick is not guaranteed to happen within the set time slice" * tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/doc: Update documentation for base_slice_ns and CONFIG_HZ relation
2024-03-24Merge tag 'dma-mapping-6.9-2024-03-24' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds2-12/+42
Pull dma-mapping fixes from Christoph Hellwig: "This has a set of swiotlb alignment fixes for sometimes very long standing bugs from Will. We've been discussion them for a while and they should be solid now" * tag 'dma-mapping-6.9-2024-03-24' of git://git.infradead.org/users/hch/dma-mapping: swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE iommu/dma: Force swiotlb_max_mapping_size on an untrusted device swiotlb: Fix alignment checks when both allocation and DMA masks are present swiotlb: Honour dma_alloc_coherent() alignment in swiotlb_alloc() swiotlb: Enforce page alignment in swiotlb_alloc() swiotlb: Fix double-allocation of slots due to broken alignment handling
2024-03-24efi: fix panic in kdump kernelOleksandr Tymoshenko1-0/+2
Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware. Fixes: bad267f9e18f ("efi: verify that variable services are supported") Signed-off-by: Oleksandr Tymoshenko <ovt@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-03-24x86/efistub: Don't clear BSS twice in mixed modeArd Biesheuvel1-1/+2
Clearing BSS should only be done once, at the very beginning. efi_pe_entry() is the entrypoint from the firmware, which may not clear BSS and so it is done explicitly. However, efi_pe_entry() is also used as an entrypoint by the mixed mode startup code, in which case BSS will already have been cleared, and doing it again at this point will corrupt global variables holding the firmware's GDT/IDT and segment selectors. So make the memset() conditional on whether the EFI stub is running in native mode. Fixes: b3810c5a2cc4a666 ("x86/efistub: Clear decompressor BSS in native EFI entrypoint") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-03-24x86/efistub: Call mixed mode boot services on the firmware's stackArd Biesheuvel1-0/+9
Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. Cc: <stable@kernel.org> # v6.1+ Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-03-24x86/boot/64: Move 5-level paging global variable assignments backTom Lendacky1-9/+7
Commit 63bed9660420 ("x86/startup_64: Defer assignment of 5-level paging global variables") moved assignment of 5-level global variables to later in the boot in order to avoid having to use RIP relative addressing in order to set them. However, when running with 5-level paging and SME active (mem_encrypt=on), the variables are needed as part of the page table setup needed to encrypt the kernel (using pgd_none(), p4d_offset(), etc.). Since the variables haven't been set, the page table manipulation is done as if 4-level paging is active, causing the system to crash on boot. While only a subset of the assignments that were moved need to be set early, move all of the assignments back into check_la57_support() so that these assignments aren't spread between two locations. Instead of just reverting the fix, this uses the new RIP_REL_REF() macro when assigning the variables. Fixes: 63bed9660420 ("x86/startup_64: Defer assignment of 5-level paging global variables") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/2ca419f4d0de719926fd82353f6751f717590a86.1711122067.git.thomas.lendacky@amd.com
2024-03-24x86/boot/64: Apply encryption mask to 5-level pagetable updateTom Lendacky1-1/+1
When running with 5-level page tables, the kernel mapping PGD entry is updated to point to the P4D table. The assignment uses _PAGE_TABLE_NOENC, which, when SME is active (mem_encrypt=on), results in a page table entry without the encryption mask set, causing the system to crash on boot. Change the assignment to use _PAGE_TABLE instead of _PAGE_TABLE_NOENC so that the encryption mask is set for the PGD entry. Fixes: 533568e06b15 ("x86/boot/64: Use RIP_REL_REF() to access early_top_pgt[]") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/8f20345cda7dbba2cf748b286e1bc00816fe649a.1711122067.git.thomas.lendacky@amd.com
2024-03-24x86/cpu: Add model number for another Intel Arrow Lake mobile processorTony Luck1-0/+1
This one is the regular laptop CPU. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20240322161725.195614-1-tony.luck@intel.com
2024-03-24x86/fpu: Keep xfd_state in sync with MSR_IA32_XFDAdamos Ttofari2-6/+13
Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD. Fixes: 672365477ae8 ("x86/fpu: Update XFD state where required") Signed-off-by: Adamos Ttofari <attofari@amazon.de> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240322230439.456571-1-chang.seok.bae@intel.com Closes: https://lore.kernel.org/lkml/20230511152818.13839-1-attofari@amazon.de
2024-03-24Documentation/x86: Document that resctrl bandwidth control units are MiBTony Luck1-4/+4
The memory bandwidth software controller uses 2^20 units rather than 10^6. See mbm_bw_count() which computes bandwidth using the "SZ_1M" Linux define for 0x00100000. Update the documentation to use MiB when describing this feature. It's too late to fix the mount option "mba_MBps" as that is now an established user interface. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20240322182016.196544-1-tony.luck@intel.com