summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-07-14lib/crypto: sparc/sha1: Migrate optimized code into libraryEric Biggers
Instead of exposing the sparc-optimized SHA-1 code via sparc-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be sparc-optimized, and it fixes the longstanding issue where the sparc-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. Note: to see the diff from arch/sparc/crypto/sha1_glue.c to lib/crypto/sparc/sha1.h, view this commit with 'git show -M10'. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-13-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: s390/sha1: Migrate optimized code into libraryEric Biggers
Instead of exposing the s390-optimized SHA-1 code via s390-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be s390-optimized, and it fixes the longstanding issue where the s390-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-12-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: powerpc/sha1: Migrate optimized code into libraryEric Biggers
Instead of exposing the powerpc-optimized SHA-1 code via powerpc-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be powerpc-optimized, and it fixes the longstanding issue where the powerpc-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. Note: to see the diff from arch/powerpc/crypto/sha1-spe-glue.c to lib/crypto/powerpc/sha1.h, view this commit with 'git show -M10'. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-11-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: mips/sha1: Migrate optimized code into libraryEric Biggers
Instead of exposing the mips-optimized SHA-1 code via mips-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be mips-optimized, and it fixes the longstanding issue where the mips-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. Note: to see the diff from arch/mips/cavium-octeon/crypto/octeon-sha1.c to lib/crypto/mips/sha1.h, view this commit with 'git show -M10'. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-10-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: arm64/sha1: Migrate optimized code into libraryEric Biggers
Instead of exposing the arm64-optimized SHA-1 code via arm64-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be arm64-optimized, and it fixes the longstanding issue where the arm64-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. Remove support for SHA-1 finalization from assembly code, since the library does not yet support architecture-specific overrides of the finalization. (Support for that has been omitted for now, for simplicity and because usually it isn't performance-critical.) To match sha1_blocks(), change the type of the nblocks parameter and the return value of __sha1_ce_transform() from int to size_t. Update the assembly code accordingly. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-9-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14lib/crypto: arm/sha1: Migrate optimized code into libraryEric Biggers
Instead of exposing the arm-optimized SHA-1 code via arm-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be arm-optimized, and it fixes the longstanding issue where the arm-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. To match sha1_blocks(), change the type of the nblocks parameter of the assembly functions from int to size_t. The assembly functions actually already treated it as size_t. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-8-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14crypto: x86/sha1 - Rename conflicting symbolEric Biggers
Rename x86's sha1_update() to sha1_update_x86(), since it conflicts with the upcoming sha1_update() library function. Note: the affected code will be superseded by later commits that migrate the arch-optimized SHA-1 code into the library. This commit simply keeps the kernel building for the initial introduction of the library. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250712232329.818226-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-14Merge branch 'tip/sched/urgent'Peter Zijlstra
Avoid merge conflicts Signed-off-by: Peter Zijlstra <peterz@infradead.org>
2025-07-14x86/tools: insn_sanity.c: Emit standard build success messagesIngo Molnar
The standard 'success' output of insn_decoder_test spams build logs with: arch/x86/tools/insn_sanity: Success: decoded and checked 1000000 random instructions with 0 errors (seed:0x2e263877) Prefix the message with the standard ' ' (two spaces) used by kbuild to denote regular build messages, making it easier for tools to filter out warnings and errors. Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jürgen Groß <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20250515132719.31868-6-mingo@kernel.org
2025-07-14x86/tools: insn_decoder_test.c: Emit standard build success messagesIngo Molnar
The standard 'success' output of insn_decoder_test spams build logs with: arch/x86/tools/insn_decoder_test: success: Decoded and checked 8258521 instructions Prefix the message with the standard ' ' (two spaces) used by kbuild to denote regular build messages, making it easier for tools to filter out warnings and errors. Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jürgen Groß <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20250515132719.31868-5-mingo@kernel.org
2025-07-14x86/kconfig/32: Refresh defconfigIngo Molnar
Refresh the x86-32 defconfig to pick up changes in the general Kconfig environment: removed options, different defaults, renames, etc. No changes to the actual result of 'make ARCH=i386 defconfig'. [ bp: Fold in a fix as reported by Andy: https://lore.kernel.org/r/20250626150118.318836-1-andriy.shevchenko@linux.intel.com ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jürgen Groß <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20250515132719.31868-2-mingo@kernel.org
2025-07-14ARM: rockchip: fix kernel hang during smp initializationAlexander Kochetkov
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4 Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Link: https://lore.kernel.org/r/20250703140453.1273027-1-al.kochet@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-07-14ASoC: codec: Convert to GPIO descriptors forMark Brown
Merge series from Peng Fan <peng.fan@nxp.com>: This patchset is a pick up of patch 1,2 from [1]. And I also collect Linus's R-b for patch 2. After this patchset, there is only one user of of_gpio.h left in sound driver(pxa2xx-ac97). of_gpio.h is deprecated, update the driver to use GPIO descriptors. Patch 1 is to drop legacy platform data which in-tree no users are using it Patch 2 is to convert to GPIO descriptors Checking the DTS that use the device, all are using GPIOD_ACTIVE_LOW polarity for reset-gpios, so all should work as expected with this patch. [1] https://lore.kernel.org/all/20250408-asoc-gpio-v1-0-c0db9d3fd6e9@nxp.com/
2025-07-14x86/smpboot: avoid SMT domain attach/destroy if SMT is not enabledLi Chen
Currently, the SMT domain is added into sched_domain_topology by default. If cpu_attach_domain() finds that the CPU SMT domain’s cpumask_weight is just 1, it will destroy it. On a large machine, such as one with 512 cores, this results in 512 redundant domain attach/destroy operations. Avoid these unnecessary operations by simply checking cpu_smt_num_threads and skip SMT domain if the SMT domain is not enabled. Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-5-me@linux.beauty
2025-07-14x86/smpboot: moves x86_topology to static initialize and truncateLi Chen
The #ifdeffery and the initializers in build_sched_topology() are just disgusting. Statically initialize the domain levels in the topology array and let build_sched_topology() invalidate the package domain level when NUMA in package is available. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-4-me@linux.beauty
2025-07-14x86/smpboot: remove redundant CONFIG_SCHED_SMTLi Chen
On x86 CONFIG_SCHED_SMT is default y if SMP is enabled, so let's simply drop CONFIG_SCHED_SMT. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-3-me@linux.beauty
2025-07-14smpboot: introduce SDTL_INIT() helper to tidy sched topology setupLi Chen
Define a small SDTL_INIT(maskfn, flagsfn, name) macro and use it to build the sched_domain_topology_level array. Purely a cleanup; behaviour is unchanged. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-2-me@linux.beauty
2025-07-13um: Stop tracking stub's PID via userspace_pid[]Tiwei Bie
The PID of the stub process can be obtained from current_mm_id(). There is no need to track it via userspace_pid[]. Stop doing that to simplify the code. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250711065021.2535362-4-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-13um: Remove the pid parameter of handle_trap()Tiwei Bie
It's no longer used. Remove it. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250711065021.2535362-3-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-13um: Use err consistently in userspace()Tiwei Bie
Avoid declaring a new variable 'ret' inside the 'if (using_seccomp)' block, as the existing 'err' variable declared at the top of the function already serves the same purpose. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250711065021.2535362-2-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-13Merge tag 'x86_urgent_for_v6.16_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Update Kirill's email address - Allow hugetlb PMD sharing only on 64-bit as it doesn't make a whole lotta sense on 32-bit - Add fixes for a misconfigured AMD Zen2 client which wasn't even supposed to run Linux * tag 'x86_urgent_for_v6.16_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: MAINTAINERS: Update Kirill Shutemov's email address for TDX x86/mm: Disable hugetlb page table sharing on 32-bit x86/CPU/AMD: Disable INVLPGB on Zen2 x86/rdrand: Disable RDSEED on AMD Cyan Skillfish
2025-07-13arm64: dts: imx8q: add camera ov5640 support for imx8qm-mek and imx8qxp-mekFrank Li
Add ov5640 overlay file for imx8qm-mek and imx8qxp-mek board. Camera can connect different CSI port. So use dts overlay file to handle these difference connect options. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-07-12arm64: dts: altera: socfpga_stratix10: update internal oscillatorsMatthew Gerlach
Add the clock-frequency property to the cb_intosc_ls_clk and cb_intosc_hs_div2_clk device tree nodes. The f2s_free_clk is implemented by custom logic in the FPGA; so it should be disabled in the dtsi by default and enabled by a dts for a specific FPGA design on a specific board. Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: swvp: remove phy-addr in the GMAC nodeDinh Nguyen
This addresses this warning: socfpga_stratix10_swvp.dtb: ethernet@ff800000 (altr,socfpga-stmmac-a10-s10): 'phy-addr' does not match any of the regexes: '^pinctrl-[0-9]+$' Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: swvp: remove cpu1-start-addrDinh Nguyen
The cpu1-start-addr property is only applicable to 32-bit SoCFPGA platforms. Removing this property will take care of warnings like this: socfpga_stratix10_swvp.dtb: sysmgr@ffd12000: cpu1-start-addr: False schema does not allow 4291846704 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: swvp: remove altr,modrst-offsetDinh Nguyen
'altr,modrst-offset' property is not applicable for arm64 SoCFPGA platforms. This will fix this dtbs_check warning: socfpga_stratix10_swvp.dtb: rstmgr@ffd11000: altr,modrst-offset: False schema does not allow 32 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: stratix10: fix dtbs_check for rstmgrDinh Nguyen
Add the default "altr,rst-mgr" to the rstmgr node on Stratix10. This fixes this warning: arch/arm64/boot/dts/altera:33:10 rstmgr@ffd11000 (altr,stratix10-rst-mgr): compatible: 'oneOf' conditional failed, one must be fixed: Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: socfpga: agilex: fix dtbs_check warning for f2s-free-clkDinh Nguyen
The f2s-free-clk requires a clock-frequency value. We put in an arbitrary value of 100 MHz for a constant. The true clock frequency would get generated in an FPGA design and the bootloader will populated in actual hardware designs. This fixes warning like this: arch/arm64/boot/dts/intel:34:8 4 f2s-free-clk (fixed-clock): 'clock-frequency' is a required property Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-07-12arm64: dts: allwinner: A523: Add SID controller nodeMikhail Kalashnikov
The SID controller should be compatible with A64 and others SoC with 0x200 offset. Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://patch.msgid.link/20250703151132.2642378-8-iuncuim@gmail.com [wens@csie.org: Fixed position of SID device node] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-12arm64: dts: allwinner: a133-liontron-h-a133l: Add Ethernet supportPaul Kocialkowski
The Liontron H-A133L board features an Ethernet controller with a JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. Note that the reset pin must be handled as a bus-wide reset GPIO in order to let the MDIO core properly reset it before trying to read its identification registers. There's no other device on the MDIO bus. The datasheet of the PHY mentions that the reset signal must be held for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to be on the safe side without wasting too much time during boot. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250707165155.581579-5-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-12arm64: dts: allwinner: a100: Add EMAC supportPaul Kocialkowski
The Allwinner A100/A133 Ethernet MAC (EMAC) is compatible with the A64 one and needs access to the syscon register for control of the top-level integration of the unit. Note that there are two such controllers on the sun50iw10 die, which are the same unit with a different top-level syscon register offset. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250707165155.581579-4-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-12arm64: dts: allwinner: a100: Add pin definitions for RGMII/RMIIPaul Kocialkowski
The Allwinner A100/A133 supports both RGMII and RMII for its Ethernet MAC (EMAC) controller. Add corresponding pin definitions. Note that the sun50iw10 die actually includes two ethernet controllers, the second of which is rarely exposed to pins. Call the first controller "emac0" to distinguish it from the second that may be added later. Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250707165155.581579-3-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-07-11x86/bugs: Print enabled attack vectorsDavid Kaplan
Print the status of enabled attack vectors and SMT mitigation status in the boot log for easier reporting and debugging. This information will also be available through sysfs. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-21-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for TSADavid Kaplan
Use attack vector controls to determine which TSA mitigation to use. [ bp: Simplify the condition in the select function for better readability. ] Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250709155844.3279471-1-david.kaplan@amd.com
2025-07-11x86/pti: Add attack vector controls for PTIDavid Kaplan
Disable PTI mitigation if user->kernel attack vector mitigations are disabled. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-20-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for ITSDavid Kaplan
Use attack vector controls to determine if ITS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-19-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for SRSODavid Kaplan
Use attack vector controls to determine if SRSO mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-18-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for L1TFDavid Kaplan
Use attack vector controls to determine if L1TF mitigation is required. Disable SMT if cross-thread protection is desired. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-17-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for spectre_v2David Kaplan
Use attack vector controls to determine if spectre_v2 mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-16-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for BHIDavid Kaplan
Use attack vector controls to determine if BHI mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-15-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for spectre_v2_userDavid Kaplan
Use attack vector controls to determine if spectre_v2_user mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-14-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for retbleedDavid Kaplan
Use attack vector controls to determine if retbleed mitigation is required. Disable SMT if cross-thread protection is desired and STIBP is not available. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-13-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for spectre_v1David Kaplan
Use attack vector controls to determine if spectre_v1 mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-12-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for GDSDavid Kaplan
Use attack vector controls to determine if GDS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-11-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for SRBDSDavid Kaplan
Use attack vector controls to determine if SRBDS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-10-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for RFDSDavid Kaplan
Use attack vector controls to determine if RFDS mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-9-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for MMIODavid Kaplan
Use attack vectors controls to determine if MMIO mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-8-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for TAADavid Kaplan
Use attack vector controls to determine if TAA mitigation is required. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-7-david.kaplan@amd.com
2025-07-11x86/bugs: Add attack vector controls for MDSDavid Kaplan
Use attack vector controls to determine if MDS mitigation is required. The global mitigations=off command now simply disables all attack vectors so explicit checking of mitigations=off is no longer needed. If cross-thread attack mitigations are required, disable SMT. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-6-david.kaplan@amd.com
2025-07-11x86/bugs: Define attack vectors relevant for each bugDavid Kaplan
Add a function which defines which vulnerabilities should be mitigated based on the selected attack vector controls. The selections here are based on the individual characteristics of each vulnerability. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250707183316.1349127-5-david.kaplan@amd.com