Message ID | 20231019181158.1982205-1-leitao@debian.org (mailing list archive) |
---|---|
Headers | show |
Series | x86/bugs: Add a separate config for each mitigation | expand |
On Fri, Oct 20, 2023 at 2:12 AM 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. Hi Breno, Do you have any plans to introduce utility functions for runtime checks on whether specific mitigations are disabled? Such helpers would be quite valuable; for instance, we could utilize them to determine if Spectre v1 or Spectre v4 mitigations are disabled in BPF[1]. [1]. https://lore.kernel.org/bpf/20231005084123.1338-1-laoar.shao@gmail.com > > 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. > > Breno Leitao (12): > 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: 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 | 141 +++++++++++++++--- > 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 | 87 ++++++----- > 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 | 8 +- > 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, 326 insertions(+), 214 deletions(-) > > -- > 2.34.1 > > -- Regards Yafang
Hello Yafang, On Mon, Oct 23, 2023 at 10:59:13AM +0800, Yafang Shao wrote: > On Fri, Oct 20, 2023 at 2:12 AM 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. > > Hi Breno, > > Do you have any plans to introduce utility functions for runtime > checks on whether specific mitigations are disabled? Such helpers > would be quite valuable; for instance, we could utilize them to > determine if Spectre v1 or Spectre v4 mitigations are disabled in > BPF[1]. I am not planning to. The check if a mitigation is enabled or not is a different topic, that also might require some further refactor. This patch set focuses in the initialization of the mitigation code at build time. Initializating the mitigation code might not result in the mitigation being enabled in runtime. For instance, you can build the kernel to mitigate the GDS, but the runtime detects that you are running in a guest VM, and depend on the host to do the mitigation, so, the mitigation might be enabled or not, even if it is initialized with CONFIG_GDS_FORCE_MITIGATION=y. Detecting if the mitigation is enabled or not is an orthogonal problem than the one I am trying to solve with this patch set.