#
b0b8a15b |
| 29-Mar-2024 |
Samuel Holland <samuel.holland@sifive.com> |
x86: implement ARCH_HAS_KERNEL_FPU_SUPPORT
x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a different header. Add a wrapper header, and export the CFLAGS adjustments as found
x86: implement ARCH_HAS_KERNEL_FPU_SUPPORT
x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a different header. Add a wrapper header, and export the CFLAGS adjustments as found in lib/Makefile.
Link: https://lkml.kernel.org/r/20240329072441.591471-11-samuel.holland@sifive.com Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: Palmer Dabbelt <palmer@rivosinc.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: WANG Xuerui <git@xen0n.name> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
14e56fb2 |
| 05-May-2024 |
Mike Rapoport (IBM) <rppt@kernel.org> |
x86/ftrace: enable dynamic ftrace without CONFIG_MODULES
Dynamic ftrace must allocate memory for code and this was impossible without CONFIG_MODULES.
With execmem separated from the modules code, e
x86/ftrace: enable dynamic ftrace without CONFIG_MODULES
Dynamic ftrace must allocate memory for code and this was impossible without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULES and make CONFIG_DYNAMIC_FTRACE select CONFIG_EXECMEM in Kconfig.
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
show more ...
|
#
7fec07fd |
| 23-Apr-2024 |
Jacob Pan <jacob.jun.pan@linux.intel.com> |
x86/irq: Add a Kconfig option for posted MSI
This option will be used to support delivering MSIs as posted interrupts. Interrupt remapping is required.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux
x86/irq: Add a Kconfig option for posted MSI
This option will be used to support delivering MSIs as posted interrupts. Interrupt remapping is required.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240423174114.526704-5-jacob.jun.pan@linux.intel.com
show more ...
|
#
25176ad0 |
| 02-Apr-2024 |
David Hildenbrand <david@redhat.com> |
mm/treewide: rename CONFIG_HAVE_FAST_GUP to CONFIG_HAVE_GUP_FAST
Nowadays, we call it "GUP-fast", the external interface includes functions like "get_user_pages_fast()", and we renamed all internal
mm/treewide: rename CONFIG_HAVE_FAST_GUP to CONFIG_HAVE_GUP_FAST
Nowadays, we call it "GUP-fast", the external interface includes functions like "get_user_pages_fast()", and we renamed all internal functions to reflect that as well.
Let's make the config option reflect that.
Link: https://lkml.kernel.org/r/20240402125516.223131-3-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
ce0abef6 |
| 20-Apr-2024 |
Sean Christopherson <seanjc@google.com> |
cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n
Explicitly disallow enabling mitigations at runtime for kernels that were built with CONFIG_CPU_MITIGATIONS=n, as some architectures m
cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n
Explicitly disallow enabling mitigations at runtime for kernels that were built with CONFIG_CPU_MITIGATIONS=n, as some architectures may omit code entirely if mitigations are disabled at compile time.
E.g. on x86, a large pile of Kconfigs are buried behind CPU_MITIGATIONS, and trying to provide sane behavior for retroactively enabling mitigations is extremely difficult, bordering on impossible. E.g. page table isolation and call depth tracking require build-time support, BHI mitigations will still be off without additional kernel parameters, etc.
[ bp: Touchups. ]
Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240420000556.2645001-3-seanjc@google.com
show more ...
|
#
fe42754b |
| 20-Apr-2024 |
Sean Christopherson <seanjc@google.com> |
cpu: Re-enable CPU mitigations by default for !X86 architectures
Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to
cpu: Re-enable CPU mitigations by default for !X86 architectures
Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific.
Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution.
Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time.
Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n") Closes: https://lkml.kernel.org/r/20240413115324.53303a68%40canb.auug.org.au Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Michael Ellerman <mpe@ellerman.id.au> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240420000556.2645001-2-seanjc@google.com
show more ...
|
#
71d99ea4 |
| 04-Feb-2024 |
Masahiro Yamada <masahiroy@kernel.org> |
x86/Kconfig: Merge the two CONFIG_X86_EXTENDED_PLATFORM entries
There are two menu entries for X86_EXTENDED_PLATFORM, one for X86_32 and the other for X86_64.
These entries are nearly identical, wi
x86/Kconfig: Merge the two CONFIG_X86_EXTENDED_PLATFORM entries
There are two menu entries for X86_EXTENDED_PLATFORM, one for X86_32 and the other for X86_64.
These entries are nearly identical, with the only difference being the platform list in the help message.
While this structure was intended by commit
8425091ff8af ("x86: improve the help text of X86_EXTENDED_PLATFORM"),
there is no need to duplicate the entire config entry. Instead, provide a little more clarification in the help message.
[ bp: Massage. ]
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240204100719.42574-1-masahiroy@kernel.org
show more ...
|
#
4f511739 |
| 11-Apr-2024 |
Josh Poimboeuf <jpoimboe@kernel.org> |
x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI
For consistency with the other CONFIG_MITIGATION_* options, replace the CONFIG_SPECTRE_BHI_{ON,OFF} options with a si
x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI
For consistency with the other CONFIG_MITIGATION_* options, replace the CONFIG_SPECTRE_BHI_{ON,OFF} options with a single CONFIG_MITIGATION_SPECTRE_BHI option.
[ mingo: Fix ]
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Sean Christopherson <seanjc@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nikolay Borisov <nik.borisov@suse.com> Link: https://lore.kernel.org/r/3833812ea63e7fdbe36bf8b932e63f70d18e2a2a.1712813475.git.jpoimboe@kernel.org
show more ...
|
#
36d4fe14 |
| 11-Apr-2024 |
Josh Poimboeuf <jpoimboe@kernel.org> |
x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto
Unlike most other mitigations' "auto" options, spectre_bhi=auto only mitigates newer systems, which is confusing and not particularly
x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto
Unlike most other mitigations' "auto" options, spectre_bhi=auto only mitigates newer systems, which is confusing and not particularly useful.
Remove it.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/412e9dc87971b622bbbaf64740ebc1f140bff343.1712813475.git.jpoimboe@kernel.org
show more ...
|
#
ec9404e4 |
| 11-Mar-2024 |
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> |
x86/bhi: Add BHI mitigation knob
Branch history clearing software sequences and hardware control BHI_DIS_S were defined to mitigate Branch History Injection (BHI).
Add cmdline spectre_bhi={on|off|a
x86/bhi: Add BHI mitigation knob
Branch history clearing software sequences and hardware control BHI_DIS_S were defined to mitigate Branch History Injection (BHI).
Add cmdline spectre_bhi={on|off|auto} to control BHI mitigation:
auto - Deploy the hardware mitigation BHI_DIS_S, if available. on - Deploy the hardware mitigation BHI_DIS_S, if available, otherwise deploy the software sequence at syscall entry and VMexit. off - Turn off BHI mitigation.
The default is auto mode which does not deploy the software sequence mitigation. This is because of the hardening done in the syscall dispatch path, which is the likely target of BHI.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org>
show more ...
|
#
7e90ffb7 |
| 25-Mar-2024 |
Adrian Hunter <adrian.hunter@intel.com> |
x86/vdso: Make delta calculation overflow safe
Kernel timekeeping is designed to keep the change in cycles (since the last timer interrupt) below max_cycles, which prevents multiplication overflow w
x86/vdso: Make delta calculation overflow safe
Kernel timekeeping is designed to keep the change in cycles (since the last timer interrupt) below max_cycles, which prevents multiplication overflow when converting cycles to nanoseconds. However, if timer interrupts stop, the calculation will eventually overflow.
Add protection against that. Select GENERIC_VDSO_OVERFLOW_PROTECT so that max_cycles is made available in the VDSO data page. Check against max_cycles, falling back to a slower higher precision calculation. Take advantage of the opportunity to move masking and negative motion check into the slow path.
The result is a calculation that has similar performance as before. Newer machines showed performance benefit, whereas older Skylake-based hardware such as Intel Kaby Lake was seen <1% worse.
Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240325064023.2997-9-adrian.hunter@intel.com
show more ...
|
#
9ebe5500 |
| 02-Apr-2024 |
Uros Bizjak <ubizjak@gmail.com> |
x86/percpu: Re-enable named address spaces with sanitizers for GCC 13.3+
Commit:
b6540de9b5c8 ("x86/percpu: Disable named address spaces for KASAN")
... disabled support for named address spaces
x86/percpu: Re-enable named address spaces with sanitizers for GCC 13.3+
Commit:
b6540de9b5c8 ("x86/percpu: Disable named address spaces for KASAN")
... disabled support for named address spaces with KCSAN due to the incompatibility issue between named AS and KCSAN.
GCC 13.3 has fixed this issue (GCC PR sanitizer/111736) so the support for named address spaces can be re-enabled with sanitizers for GCC compiler version >= 13.3.
[ Note that the patch considers GCC 14 to be fixed - if somebody is using snapshots of the GCC 14 before the fix, they should upgrade. ]
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20240402121926.78477-1-ubizjak@gmail.com
show more ...
|
#
b6540de9 |
| 25-Mar-2024 |
Uros Bizjak <ubizjak@gmail.com> |
x86/percpu: Disable named address spaces for KCSAN
-fsanitize=thread (KCSAN) is at the moment incompatible with named address spaces in a similar way as KASAN - see GCC PR sanitizer/111736:
https
x86/percpu: Disable named address spaces for KCSAN
-fsanitize=thread (KCSAN) is at the moment incompatible with named address spaces in a similar way as KASAN - see GCC PR sanitizer/111736:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
The patch disables named address spaces with KCSAN.
Reported-by: kernel test robot <oliver.sang@intel.com> Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20240325110128.615933-1-ubizjak@gmail.com
show more ...
|
#
3c41786c |
| 12-Mar-2024 |
Paul Menzel <pmenzel@molgen.mpg.de> |
x86/fred: Fix typo in Kconfig description
Fixes: 2cce95918d63 ("x86/fred: Add Kconfig option for FRED (CONFIG_X86_FRED)") Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Ingo Molna
x86/fred: Fix typo in Kconfig description
Fixes: 2cce95918d63 ("x86/fred: Add Kconfig option for FRED (CONFIG_X86_FRED)") Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com> Link: https://lore.kernel.org/r/20240312161958.102927-2-pmenzel@molgen.mpg.de
arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
show more ...
|
#
b429eafe |
| 21-Mar-2024 |
Uros Bizjak <ubizjak@gmail.com> |
x86/percpu: Enable named address spaces for GCC 9.1+
Enable named address spaces also for GCC 9, GCC 10 and GCC 11 releases. These compilers all produce kernel images that boot without problems.
GC
x86/percpu: Enable named address spaces for GCC 9.1+
Enable named address spaces also for GCC 9, GCC 10 and GCC 11 releases. These compilers all produce kernel images that boot without problems.
GCC_VERSION cutoff is arbitrary. It is primary a risk-reduction cutoff, older compilers will be tested and enabled in linux 6.10 release.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240321164647.289879-1-ubizjak@gmail.com
show more ...
|
#
f61f02d1 |
| 20-Mar-2024 |
Uros Bizjak <ubizjak@gmail.com> |
x86/percpu: Re-enable named address spaces with KASAN for GCC 13.3+
Commit:
68fb3ca0e408 ("x86/percpu: Disable named address spaces for KASAN")
... disabled support for named address spaces with
x86/percpu: Re-enable named address spaces with KASAN for GCC 13.3+
Commit:
68fb3ca0e408 ("x86/percpu: Disable named address spaces for KASAN")
... disabled support for named address spaces with KASAN due to the incompatibility issue between named AS and KASAN.
GCC 13.3 has fixed this issue (GCC PR sanitizer/111736) so the support for named address spaces can be re-enabled with KASAN for GCC compiler version >= 13.3.
Note that the patch considers GCC 14 to be fixed - if somebody is using snapshots of the GCC 14 before the fix, they should upgrade.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/20240320124603.566923-1-ubizjak@gmail.com
show more ...
|
#
8076fcde |
| 11-Mar-2024 |
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> |
x86/rfds: Mitigate Register File Data Sampling (RFDS)
RFDS is a CPU vulnerability that may allow userspace to infer kernel stale data previously used in floating point registers, vector registers an
x86/rfds: Mitigate Register File Data Sampling (RFDS)
RFDS is a CPU vulnerability that may allow userspace to infer kernel stale data previously used in floating point registers, vector registers and integer registers. RFDS only affects certain Intel Atom processors.
Intel released a microcode update that uses VERW instruction to clear the affected CPU buffers. Unlike MDS, none of the affected cores support SMT.
Add RFDS bug infrastructure and enable the VERW based mitigation by default, that clears the affected buffers just before exiting to userspace. Also add sysfs reporting and cmdline parameter "reg_file_data_sampling" to control the mitigation.
For details see: Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
show more ...
|
#
8af2d202 |
| 04-Feb-2024 |
Masahiro Yamada <masahiroy@kernel.org> |
platform: goldfish: move the separate 'default' propery for CONFIG_GOLDFISH
Currently, there are two entries for CONFIG_GOLDFISH.
In arch/x86/Kconfig:
config GOLDFISH def_bool y
platform: goldfish: move the separate 'default' propery for CONFIG_GOLDFISH
Currently, there are two entries for CONFIG_GOLDFISH.
In arch/x86/Kconfig:
config GOLDFISH def_bool y depends on X86_GOLDFISH
In drivers/platform/goldfish/Kconfig:
menuconfig GOLDFISH bool "Platform support for Goldfish virtual devices" depends on HAS_IOMEM && HAS_DMA
While Kconfig allows multiple entries, it generally leads to tricky code.
Prior to commit bd2f348db503 ("goldfish: refactor goldfish platform configs"), CONFIG_GOLDFISH was an alias of CONFIG_X86_GOLDFISH.
After the mentioned commit added the second entry with a user prompt, the former provides the 'default' property that is effective only when X86_GOLDFISH=y.
Merge them tegether to clarify how it has worked in the past 8 years.
Cc: Greg Hackmann <ghackmann@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20240204081004.33871-1-masahiroy@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
5394f1e9 |
| 26-Feb-2024 |
Arnd Bergmann <arnd@arndb.de> |
arch: define CONFIG_PAGE_SIZE_*KB on all architectures
Most architectures only support a single hardcoded page size. In order to ensure that each one of these sets the corresponding Kconfig symbols,
arch: define CONFIG_PAGE_SIZE_*KB on all architectures
Most architectures only support a single hardcoded page size. In order to ensure that each one of these sets the corresponding Kconfig symbols, change over the PAGE_SHIFT definition to the common one and allow only the hardware page size to be selected.
Acked-by: Guo Ren <guoren@kernel.org> Acked-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Stafford Horne <shorne@gmail.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
cb81deef |
| 28-Feb-2024 |
Thomas Gleixner <tglx@linutronix.de> |
x86/idle: Sanitize X86_BUG_AMD_E400 handling
amd_e400_idle(), the idle routine for AMD CPUs which are affected by erratum 400 violates the RCU constraints by invoking tick_broadcast_enter() and tick
x86/idle: Sanitize X86_BUG_AMD_E400 handling
amd_e400_idle(), the idle routine for AMD CPUs which are affected by erratum 400 violates the RCU constraints by invoking tick_broadcast_enter() and tick_broadcast_exit() after the core code has marked RCU non-idle. The functions can end up in lockdep or tracing, which rightfully triggers a RCU warning.
The core code provides now a static branch conditional invocation of the broadcast functions.
Remove amd_e400_idle(), enforce default_idle() and enable the static branch on affected CPUs to cure this.
[ bp: Fold in a fix for a IS_ENABLED() check fail missing a "CONFIG_" prefix which tglx spotted. ]
Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/877cim6sis.ffs@tglx
show more ...
|
#
85fcde40 |
| 24-Jan-2024 |
Baoquan He <bhe@redhat.com> |
kexec: split crashkernel reservation code out from crash_core.c
Patch series "Split crash out from kexec and clean up related config items", v3.
Motivation: ============= Previously, LKP reported a
kexec: split crashkernel reservation code out from crash_core.c
Patch series "Split crash out from kexec and clean up related config items", v3.
Motivation: ============= Previously, LKP reported a building error. When investigating, it can't be resolved reasonablly with the present messy kdump config items.
https://lore.kernel.org/oe-kbuild-all/202312182200.Ka7MzifQ-lkp@intel.com/
The kdump (crash dumping) related config items could causes confusions:
Firstly,
CRASH_CORE enables codes including - crashkernel reservation; - elfcorehdr updating; - vmcoreinfo exporting; - crash hotplug handling;
Now fadump of powerpc, kcore dynamic debugging and kdump all selects CRASH_CORE, while fadump - fadump needs crashkernel parsing, vmcoreinfo exporting, and accessing global variable 'elfcorehdr_addr'; - kcore only needs vmcoreinfo exporting; - kdump needs all of the current kernel/crash_core.c.
So only enabling PROC_CORE or FA_DUMP will enable CRASH_CORE, this mislead people that we enable crash dumping, actual it's not.
Secondly,
It's not reasonable to allow KEXEC_CORE select CRASH_CORE.
Because KEXEC_CORE enables codes which allocate control pages, copy kexec/kdump segments, and prepare for switching. These codes are shared by both kexec reboot and kdump. We could want kexec reboot, but disable kdump. In that case, CRASH_CORE should not be selected.
-------------------- CONFIG_CRASH_CORE=y CONFIG_KEXEC_CORE=y CONFIG_KEXEC=y CONFIG_KEXEC_FILE=y ---------------------
Thirdly,
It's not reasonable to allow CRASH_DUMP select KEXEC_CORE.
That could make KEXEC_CORE, CRASH_DUMP are enabled independently from KEXEC or KEXEC_FILE. However, w/o KEXEC or KEXEC_FILE, the KEXEC_CORE code built in doesn't make any sense because no kernel loading or switching will happen to utilize the KEXEC_CORE code. --------------------- CONFIG_CRASH_CORE=y CONFIG_KEXEC_CORE=y CONFIG_CRASH_DUMP=y ---------------------
In this case, what is worse, on arch sh and arm, KEXEC relies on MMU, while CRASH_DUMP can still be enabled when !MMU, then compiling error is seen as the lkp test robot reported in above link.
------arch/sh/Kconfig------ config ARCH_SUPPORTS_KEXEC def_bool MMU
config ARCH_SUPPORTS_CRASH_DUMP def_bool BROKEN_ON_SMP ---------------------------
Changes: =========== 1, split out crash_reserve.c from crash_core.c; 2, split out vmcore_infoc. from crash_core.c; 3, move crash related codes in kexec_core.c into crash_core.c; 4, remove dependency of FA_DUMP on CRASH_DUMP; 5, clean up kdump related config items; 6, wrap up crash codes in crash related ifdefs on all 8 arch-es which support crash dumping, except of ppc;
Achievement: =========== With above changes, I can rearrange the config item logic as below (the right item depends on or is selected by the left item):
PROC_KCORE -----------> VMCORE_INFO
|----------> VMCORE_INFO FA_DUMP----| |----------> CRASH_RESERVE
---->VMCORE_INFO / |---->CRASH_RESERVE KEXEC --| /| |--> KEXEC_CORE--> CRASH_DUMP-->/-|---->PROC_VMCORE KEXEC_FILE --| \ | \---->CRASH_HOTPLUG
KEXEC --| |--> KEXEC_CORE (for kexec reboot only) KEXEC_FILE --|
Test ======== On all 8 architectures, including x86_64, arm64, s390x, sh, arm, mips, riscv, loongarch, I did below three cases of config item setting and building all passed. Take configs on x86_64 as exampmle here:
(1) Both CONFIG_KEXEC and KEXEC_FILE is unset, then all kexec/kdump items are unset automatically: # Kexec and crash features # CONFIG_KEXEC is not set # CONFIG_KEXEC_FILE is not set # end of Kexec and crash features
(2) set CONFIG_KEXEC_FILE and 'make olddefconfig': --------------- # Kexec and crash features CONFIG_CRASH_RESERVE=y CONFIG_VMCORE_INFO=y CONFIG_KEXEC_CORE=y CONFIG_KEXEC_FILE=y CONFIG_CRASH_DUMP=y CONFIG_CRASH_HOTPLUG=y CONFIG_CRASH_MAX_MEMORY_RANGES=8192 # end of Kexec and crash features ---------------
(3) unset CONFIG_CRASH_DUMP in case 2 and execute 'make olddefconfig': ------------------------ # Kexec and crash features CONFIG_KEXEC_CORE=y CONFIG_KEXEC_FILE=y # end of Kexec and crash features ------------------------
Note: For ppc, it needs investigation to make clear how to split out crash code in arch folder. Hope Hari and Pingfan can help have a look, see if it's doable. Now, I make it either have both kexec and crash enabled, or disable both of them altogether.
This patch (of 14):
Both kdump and fa_dump of ppc rely on crashkernel reservation. Move the relevant codes into separate files: crash_reserve.c, include/linux/crash_reserve.h.
And also add config item CRASH_RESERVE to control its enabling of the codes. And update config items which has relationship with crashkernel reservation.
And also change ifdeffery from CONFIG_CRASH_CORE to CONFIG_CRASH_RESERVE when those scopes are only crashkernel reservation related.
And also rename arch/XXX/include/asm/{crash_core.h => crash_reserve.h} on arm64, x86 and risc-v because those architectures' crash_core.h is only related to crashkernel reservation.
[akpm@linux-foundation.org: s/CRASH_RESEERVE/CRASH_RESERVE/, per Klara Modin] Link: https://lkml.kernel.org/r/20240124051254.67105-1-bhe@redhat.com Link: https://lkml.kernel.org/r/20240124051254.67105-2-bhe@redhat.com Signed-off-by: Baoquan He <bhe@redhat.com> Acked-by: Hari Bathini <hbathini@linux.ibm.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pingfan Liu <piliu@redhat.com> Cc: Klara Modin <klarasmodin@gmail.com> Cc: Michael Kelley <mhklinux@outlook.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
43b1d3e6 |
| 15-Dec-2023 |
Chris Koch <chrisko@google.com> |
kexec: Allocate kernel above bzImage's pref_address
A relocatable kernel will relocate itself to pref_address if it is loaded below pref_address. This means a booted kernel may be relocating itself
kexec: Allocate kernel above bzImage's pref_address
A relocatable kernel will relocate itself to pref_address if it is loaded below pref_address. This means a booted kernel may be relocating itself to an area with reserved memory on modern systems, potentially clobbering arbitrary data that may be important to the system.
This is often the case, as the default value of PHYSICAL_START is 0x1000000 and kernels are typically loaded at 0x100000 or above by bootloaders like iPXE or kexec. GRUB behaves like the approach implemented here.
Also fixes the documentation around pref_address and PHYSICAL_START to be accurate.
[ dhansen: changelog tweak ]
Co-developed-by: Cloud Hsu <cloudhsu@google.com> Signed-off-by: Cloud Hsu <cloudhsu@google.com> Signed-off-by: Chris Koch <chrisko@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com> Link: https://lore.kernel.org/all/20231215190521.3796022-1-chrisko%40google.com
show more ...
|
#
f48212ee |
| 04-Jan-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
treewide: remove CONFIG_HAVE_KVM
It has no users anymore.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
918327e9 |
| 28-Jan-2024 |
Kees Cook <keescook@chromium.org> |
ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL
For simplicity in splitting out UBSan options into separate rules, remove CONFIG_UBSAN_SANITIZE_ALL, effectively defaulting to "y", which is how it is general
ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL
For simplicity in splitting out UBSan options into separate rules, remove CONFIG_UBSAN_SANITIZE_ALL, effectively defaulting to "y", which is how it is generally used anyway. (There are no ":= y" cases beyond where a specific file is enabled when a top-level ":= n" is in effect.)
Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Marco Elver <elver@google.com> Cc: linux-doc@vger.kernel.org Cc: linux-kbuild@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
29956748 |
| 02-Feb-2024 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/Kconfig: Remove CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
It was meant well at the time but nothing's using it so get rid of it.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Ard
x86/Kconfig: Remove CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
It was meant well at the time but nothing's using it so get rid of it.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20240202163510.GDZb0Zvj8qOndvFOiZ@fat_crate.local
show more ...
|