| Message ID | 20231121160740.1249350-1-leitao@debian.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86/bugs: Add a separate config for each mitigation | expand |
On Tue, Nov 21, 2023 at 08:07:27AM -0800, Breno Leitao wrote: > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, > where some mitigations have entries in Kconfig, and they could be > modified, while others mitigations do not have Kconfig entries, and > could not be controlled at build time. All looks good to me, thanks! Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
* Breno Leitao <leitao@debian.org> wrote: > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, > where some mitigations have entries in Kconfig, and they could be > modified, while others mitigations do not have Kconfig entries, and > could not be controlled at build time. > > The fact of having a fine grained control can help in a few ways: > > 1) Users can choose and pick only mitigations that are important for > their workloads. > > 2) Users and developers can choose to disable mitigations that mangle > the assembly code generation, making it hard to read. > > 3) Separate configs for just source code readability, > so that we see *which* butt-ugly piece of crap code is for what > reason. > > Important to say, if a mitigation is disabled at compilation time, it > could be enabled at runtime using kernel command line arguments. > > Discussion about this approach: > https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/ > and > https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ > > In order to get the missing mitigations, some clean up was done. > > 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig > entries. > > 2) Adding the missing mitigations, so, the mitigations have entries in the > Kconfig that could be easily configure by the user. > > With this patchset applied, all configs have an individual entry under > CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION. Yeah, so: - I took this older series and updated it to current upstream, and made sure all renames were fully done: there were two new Kconfig option uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.) - I also widened the renames to comments and messages, which were not always covered. - Then I took this cover letter and combined it with a more high level description of the reasoning behind this series I wrote up, and added it to patch #1. (see it below.) - Then I removed the changelog repetition from the other patches and just referred them back to patch #1. - Then I stuck the resulting updated series into tip:x86/bugs, without the last 3 patches that modify behavior. - You might notice the somewhat weird extra whitespaces in the titles - I've done that so that it all looks tidy in the shortlog: Breno Leitao (10): x86/bugs: Rename CONFIG_GDS_FORCE_MITIGATION => CONFIG_MITIGATION_GDS_FORCE x86/bugs: Rename CONFIG_CPU_IBPB_ENTRY => CONFIG_MITIGATION_IBPB_ENTRY x86/bugs: Rename CONFIG_CALL_DEPTH_TRACKING => CONFIG_MITIGATION_CALL_DEPTH_TRACKING x86/bugs: Rename CONFIG_PAGE_TABLE_ISOLATION => CONFIG_MITIGATION_PAGE_TABLE_ISOLATION x86/bugs: Rename CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINE x86/bugs: Rename CONFIG_SLS => CONFIG_MITIGATION_SLS x86/bugs: Rename CONFIG_CPU_UNRET_ENTRY => CONFIG_MITIGATION_UNRET_ENTRY x86/bugs: Rename CONFIG_CPU_IBRS_ENTRY => CONFIG_MITIGATION_IBRS_ENTRY x86/bugs: Rename CONFIG_CPU_SRSO => CONFIG_MITIGATION_SRSO x86/bugs: Rename CONFIG_RETHUNK => CONFIG_MITIGATION_RETHUNK I think the resulting tree is all mostly good, but still I'd like to see just the 10 pure low-risk renames done in this first step, to not carry too much of this around unnecessarily - maybe even send it Linuswards in this cycle if it's problem-free - without any real regression risk to upstream. Thanks, Ingo =============================> commit be83e809ca67bca98fde97ad6b9344237963220b Author: Breno Leitao <leitao@debian.org> Date: Tue Nov 21 08:07:28 2023 -0800 x86/bugs: Rename CONFIG_GDS_FORCE_MITIGATION => CONFIG_MITIGATION_GDS_FORCE So the CPU mitigations Kconfig entries - there's 10 meanwhile - are named in a historically idiosyncratic and hence rather inconsistent fashion and have become hard to relate with each other over the years: https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ When they were introduced we never expected that we'd eventually have about a dozen of them, and that more organization would be useful, especially for Linux distributions that want to enable them in an informed fashion, and want to make sure all mitigations are configured as expected. For example, the current CONFIG_SPECULATION_MITIGATIONS namespace is only halfway populated, where some mitigations have entries in Kconfig, and they could be modified, while others mitigations do not have Kconfig entries, and can not be controlled at build time. Fine-grained control over these Kconfig entries can help in a number of ways: 1) Users can choose and pick only mitigations that are important for their workloads. 2) Users and developers can choose to disable mitigations that mangle the assembly code generation, making it hard to read. 3) Separate Kconfigs for just source code readability, so that we see *which* butt-ugly piece of crap code is for what reason... In most cases, if a mitigation is disabled at compilation time, it can still be enabled at runtime using kernel command line arguments. This is the first patch of an initial series that renames various mitigation related Kconfig options, unifying them under a single CONFIG_MITIGATION_* namespace: CONFIG_GDS_FORCE_MITIGATION => CONFIG_MITIGATION_GDS_FORCE CONFIG_CPU_IBPB_ENTRY => CONFIG_MITIGATION_IBPB_ENTRY CONFIG_CALL_DEPTH_TRACKING => CONFIG_MITIGATION_CALL_DEPTH_TRACKING CONFIG_PAGE_TABLE_ISOLATION => CONFIG_MITIGATION_PAGE_TABLE_ISOLATION CONFIG_RETPOLINE => CONFIG_MITIGATION_RETPOLINE CONFIG_SLS => CONFIG_MITIGATION_SLS CONFIG_CPU_UNRET_ENTRY => CONFIG_MITIGATION_UNRET_ENTRY CONFIG_CPU_IBRS_ENTRY => CONFIG_MITIGATION_IBRS_ENTRY CONFIG_CPU_SRSO => CONFIG_MITIGATION_SRSO CONFIG_RETHUNK => CONFIG_MITIGATION_RETHUNK Implement step 1/10 of the namespace unification of CPU mitigations related Kconfig options and rename CONFIG_GDS_FORCE_MITIGATION to CONFIG_MITIGATION_GDS_FORCE. [ mingo: Rewrote changelog for clarity. ] Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20231121160740.1249350-2-leitao@debian.org
On Wed, Jan 10, 2024 at 10:56:46AM +0100, Ingo Molnar wrote: > > * Breno Leitao <leitao@debian.org> wrote: > > > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, > > where some mitigations have entries in Kconfig, and they could be > > modified, while others mitigations do not have Kconfig entries, and > > could not be controlled at build time. > > > > The fact of having a fine grained control can help in a few ways: > > > > 1) Users can choose and pick only mitigations that are important for > > their workloads. > > > > 2) Users and developers can choose to disable mitigations that mangle > > the assembly code generation, making it hard to read. > > > > 3) Separate configs for just source code readability, > > so that we see *which* butt-ugly piece of crap code is for what > > reason. > > > > Important to say, if a mitigation is disabled at compilation time, it > > could be enabled at runtime using kernel command line arguments. > > > > Discussion about this approach: > > https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/ > > and > > https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ > > > > In order to get the missing mitigations, some clean up was done. > > > > 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig > > entries. > > > > 2) Adding the missing mitigations, so, the mitigations have entries in the > > Kconfig that could be easily configure by the user. > > > > With this patchset applied, all configs have an individual entry under > > CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION. > > Yeah, so: > > - I took this older series and updated it to current upstream, and made > sure all renames were fully done: there were two new Kconfig option > uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.) > > - I also widened the renames to comments and messages, which were not > always covered. > > - Then I took this cover letter and combined it with a more high level > description of the reasoning behind this series I wrote up, and added it > to patch #1. (see it below.) > > - Then I removed the changelog repetition from the other patches and just > referred them back to patch #1. > > - Then I stuck the resulting updated series into tip:x86/bugs, without the > last 3 patches that modify behavior. Thanks for your work. I am currently reviwing the tip branch and the merge seems go so far. Regarding the last 3 patches, what are the next steps? Thank you! Breno
* Breno Leitao <leitao@debian.org> wrote: > > Yeah, so: > > > > - I took this older series and updated it to current upstream, and made > > sure all renames were fully done: there were two new Kconfig option > > uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.) > > > > - I also widened the renames to comments and messages, which were not > > always covered. > > > > - Then I took this cover letter and combined it with a more high level > > description of the reasoning behind this series I wrote up, and added it > > to patch #1. (see it below.) > > > > - Then I removed the changelog repetition from the other patches and just > > referred them back to patch #1. > > > > - Then I stuck the resulting updated series into tip:x86/bugs, without the > > last 3 patches that modify behavior. > > Thanks for your work. I am currently reviwing the tip branch and the > merge seems go so far. > > Regarding the last 3 patches, what are the next steps? Please resubmit them in a few days (with Josh's Acked-by added and any fixes/enhancements done along the way), on top of tip:x86/bugs. Thanks, Ingo
Hello Ingo, On Wed, Jan 10, 2024 at 07:07:48PM +0100, Ingo Molnar wrote: > > * Breno Leitao <leitao@debian.org> wrote: > > > > Yeah, so: > > > > > > - I took this older series and updated it to current upstream, and made > > > sure all renames were fully done: there were two new Kconfig option > > > uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.) > > > > > > - I also widened the renames to comments and messages, which were not > > > always covered. > > > > > > - Then I took this cover letter and combined it with a more high level > > > description of the reasoning behind this series I wrote up, and added it > > > to patch #1. (see it below.) > > > > > > - Then I removed the changelog repetition from the other patches and just > > > referred them back to patch #1. > > > > > > - Then I stuck the resulting updated series into tip:x86/bugs, without the > > > last 3 patches that modify behavior. > > > > Thanks for your work. I am currently reviwing the tip branch and the > > merge seems go so far. > > > > Regarding the last 3 patches, what are the next steps? > > Please resubmit them in a few days (with Josh's Acked-by added and any > fixes/enhancements done along the way), on top of tip:x86/bugs. I've sent the commits on top of the latest mitigations. Have you had a chance to see them? https://lore.kernel.org/all/20240422165830.2142904-1-leitao@debian.org/ PS: I took the opportunity to break them down, one per mitigation, so, it could simplify the patch management. Thanks
Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated, where some mitigations have entries in Kconfig, and they could be modified, while others mitigations do not have Kconfig entries, and could not be controlled at build time. The fact of having a fine grained control can help in a few ways: 1) Users can choose and pick only mitigations that are important for their workloads. 2) Users and developers can choose to disable mitigations that mangle the assembly code generation, making it hard to read. 3) Separate configs for just source code readability, so that we see *which* butt-ugly piece of crap code is for what reason. Important to say, if a mitigation is disabled at compilation time, it could be enabled at runtime using kernel command line arguments. Discussion about this approach: https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/ and https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/ In order to get the missing mitigations, some clean up was done. 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig entries. 2) Adding the missing mitigations, so, the mitigations have entries in the Kconfig that could be easily configure by the user. With this patchset applied, all configs have an individual entry under CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION. Changelog --------- V1: * Creates a way to mitigate all (or none) hardware bugs V2: * Create KCONFIGs entries only some hardware bugs (MDS, TAA, MMIO) V3: * Expand the mitigations KCONFIGs to all hardware bugs that are Linux mitigates. V4: * Patch rebase. * Better documentation about the reasons of this decision. V5: * Create a "MITIGATION" Kconfig namespace for the entries mitigating hardware bugs. * Add GDS to the set of mitigations that are being covered. * Reduce the ifdefs in the code by leveraging conditionals with omitted operands. V6: * Reference documentation RST files from Kconfig entries * Fix some grammar mistakes and Kconfig dependencies * Now spectre v2 user depends on CONFIG_MITIGATION_SPECTRE_V2. See patch "spectre_v2_user default mode depends on Kconfig" Breno Leitao (13): x86/bugs: Rename GDS_FORCE_MITIGATION to MITIGATION_GDS_FORCE x86/bugs: Rename CPU_IBPB_ENTRY to MITIGATION_IBPB_ENTRY x86/bugs: Rename CALL_DEPTH_TRACKING to MITIGATION_CALL_DEPTH_TRACKING x86/bugs: Rename PAGE_TABLE_ISOLATION to MITIGATION_PAGE_TABLE_ISOLATION x86/bugs: Rename RETPOLINE to MITIGATION_RETPOLINE x86/bugs: Rename SLS to CONFIG_MITIGATION_SLS x86/bugs: Rename CPU_UNRET_ENTRY to MITIGATION_UNRET_ENTRY x86/bugs: Rename CPU_IBRS_ENTRY to MITIGATION_IBRS_ENTRY x86/bugs: Rename CPU_SRSO to MITIGATION_SRSO x86/bugs: Rename RETHUNK to MITIGATION_RETHUNK x86/bugs: Create a way to disable GDS mitigation x86/bugs: spectre_v2_user default mode depends on Kconfig x86/bugs: Add a separate config for missing mitigation Documentation/admin-guide/hw-vuln/spectre.rst | 8 +- .../admin-guide/kernel-parameters.txt | 4 +- Documentation/arch/x86/pti.rst | 6 +- arch/x86/Kconfig | 151 +++++++++++++++--- arch/x86/Makefile | 8 +- arch/x86/boot/compressed/ident_map_64.c | 4 +- arch/x86/configs/i386_defconfig | 2 +- arch/x86/entry/calling.h | 8 +- arch/x86/entry/entry_64.S | 2 +- arch/x86/entry/vdso/Makefile | 4 +- arch/x86/include/asm/current.h | 2 +- arch/x86/include/asm/disabled-features.h | 10 +- arch/x86/include/asm/linkage.h | 16 +- arch/x86/include/asm/nospec-branch.h | 30 ++-- arch/x86/include/asm/pgalloc.h | 2 +- arch/x86/include/asm/pgtable-3level.h | 2 +- arch/x86/include/asm/pgtable.h | 18 +-- arch/x86/include/asm/pgtable_64.h | 3 +- arch/x86/include/asm/processor-flags.h | 2 +- arch/x86/include/asm/pti.h | 2 +- arch/x86/include/asm/static_call.h | 2 +- arch/x86/kernel/alternative.c | 14 +- arch/x86/kernel/asm-offsets.c | 2 +- arch/x86/kernel/cpu/amd.c | 2 +- arch/x86/kernel/cpu/bugs.c | 98 +++++++----- arch/x86/kernel/dumpstack.c | 2 +- arch/x86/kernel/ftrace.c | 3 +- arch/x86/kernel/head_32.S | 4 +- arch/x86/kernel/head_64.S | 2 +- arch/x86/kernel/kprobes/opt.c | 2 +- arch/x86/kernel/ldt.c | 8 +- arch/x86/kernel/static_call.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 10 +- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/mmu_internal.h | 2 +- arch/x86/kvm/svm/svm.c | 2 +- arch/x86/kvm/svm/vmenter.S | 4 +- arch/x86/kvm/vmx/vmx.c | 2 +- arch/x86/lib/Makefile | 2 +- arch/x86/lib/retpoline.S | 26 +-- arch/x86/mm/Makefile | 2 +- arch/x86/mm/debug_pagetables.c | 4 +- arch/x86/mm/dump_pagetables.c | 4 +- arch/x86/mm/pgtable.c | 4 +- arch/x86/mm/tlb.c | 10 +- arch/x86/net/bpf_jit_comp.c | 4 +- arch/x86/net/bpf_jit_comp32.c | 2 +- arch/x86/purgatory/Makefile | 2 +- include/linux/compiler-gcc.h | 2 +- include/linux/indirect_call_wrapper.h | 2 +- include/linux/module.h | 2 +- include/linux/objtool.h | 2 +- include/linux/pti.h | 2 +- include/net/netfilter/nf_tables_core.h | 2 +- include/net/tc_wrapper.h | 2 +- kernel/trace/ring_buffer.c | 2 +- net/netfilter/Makefile | 2 +- net/netfilter/nf_tables_core.c | 6 +- net/netfilter/nft_ct.c | 4 +- net/netfilter/nft_lookup.c | 2 +- net/sched/sch_api.c | 2 +- scripts/Makefile.lib | 8 +- scripts/Makefile.vmlinux_o | 2 +- scripts/generate_rust_target.rs | 2 +- scripts/mod/modpost.c | 2 +- .../arch/x86/include/asm/disabled-features.h | 10 +- 66 files changed, 344 insertions(+), 219 deletions(-)