[permalink] [raw]

Subject: [PATCH v6 10/13] x86/bugs: Rename RETHUNK to MITIGATION_RETHUNK

CPU mitigations config entries are inconsistent, and names are hard to
related. There are concrete benefits for both users and developers of
having all the mitigation config options living in the same config
namespace.

The mitigation options should have consistency and start with
MITIGATION.

Rename the Kconfig entry from RETHUNK to MITIGATION_RETHUNK.

Suggested-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Breno Leitao <[email protected]>
---
arch/x86/Kconfig | 8 ++++----
arch/x86/Makefile | 2 +-
arch/x86/configs/i386_defconfig | 2 +-
arch/x86/include/asm/disabled-features.h | 2 +-
arch/x86/include/asm/linkage.h | 4 ++--
arch/x86/include/asm/nospec-branch.h | 4 ++--
arch/x86/include/asm/static_call.h | 2 +-
arch/x86/kernel/alternative.c | 4 ++--
arch/x86/kernel/static_call.c | 2 +-
arch/x86/lib/retpoline.S | 4 ++--
scripts/Makefile.lib | 2 +-
tools/arch/x86/include/asm/disabled-features.h | 2 +-
12 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 30c2f880caf9..ee939de1bb05 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2465,7 +2465,7 @@ config FINEIBT

config HAVE_CALL_THUNKS
def_bool y
- depends on CC_HAS_ENTRY_PADDING && RETHUNK && OBJTOOL
+ depends on CC_HAS_ENTRY_PADDING && MITIGATION_RETHUNK && OBJTOOL

config CALL_THUNKS
def_bool n
@@ -2508,7 +2508,7 @@ config MITIGATION_RETPOLINE
branches. Requires a compiler with -mindirect-branch=thunk-extern
support for full protection. The kernel may run slower.

-config RETHUNK
+config MITIGATION_RETHUNK
bool "Enable return-thunks"
depends on MITIGATION_RETPOLINE && CC_HAS_RETURN_THUNK
select OBJTOOL if HAVE_OBJTOOL
@@ -2521,7 +2521,7 @@ config RETHUNK

config MITIGATION_UNRET_ENTRY
bool "Enable UNRET on kernel entry"
- depends on CPU_SUP_AMD && RETHUNK && X86_64
+ depends on CPU_SUP_AMD && MITIGATION_RETHUNK && X86_64
default y
help
Compile the kernel with support for the retbleed=unret mitigation.
@@ -2575,7 +2575,7 @@ config MITIGATION_IBRS_ENTRY

config MITIGATION_SRSO
bool "Mitigate speculative RAS overflow on AMD"
- depends on CPU_SUP_AMD && X86_64 && RETHUNK
+ depends on CPU_SUP_AMD && X86_64 && MITIGATION_RETHUNK
default y
help
Enable the SRSO mitigation needed on AMD Zen1-4 machines.
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5ce8c30e7701..ba046afb850e 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -22,7 +22,7 @@ RETPOLINE_VDSO_CFLAGS := -mretpoline
endif
RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch-cs-prefix)

-ifdef CONFIG_RETHUNK
+ifdef CONFIG_MITIGATION_RETHUNK
RETHUNK_CFLAGS := -mfunction-return=thunk-extern
RETPOLINE_CFLAGS += $(RETHUNK_CFLAGS)
endif
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 73abbbdd26f8..91801138b10b 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -42,7 +42,7 @@ CONFIG_EFI_STUB=y
CONFIG_HZ_1000=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
-# CONFIG_RETHUNK is not set
+# CONFIG_MITIGATION_RETHUNK is not set
CONFIG_HIBERNATION=y
CONFIG_PM_DEBUG=y
CONFIG_PM_TRACE_RTC=y
diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h
index 151f0d50e7e0..36d0c1e05e60 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -57,7 +57,7 @@
(1 << (X86_FEATURE_RETPOLINE_LFENCE & 31)))
#endif

-#ifdef CONFIG_RETHUNK
+#ifdef CONFIG_MITIGATION_RETHUNK
# define DISABLE_RETHUNK 0
#else
# define DISABLE_RETHUNK (1 << (X86_FEATURE_RETHUNK & 31))
diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 09e2d026df33..dc31b13b87a0 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -40,7 +40,7 @@

#ifdef __ASSEMBLY__

-#if defined(CONFIG_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
+#if defined(CONFIG_MITIGATION_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
#define RET jmp __x86_return_thunk
#else /* CONFIG_MITIGATION_RETPOLINE */
#ifdef CONFIG_MITIGATION_SLS
@@ -52,7 +52,7 @@

#else /* __ASSEMBLY__ */

-#if defined(CONFIG_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
+#if defined(CONFIG_MITIGATION_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
#define ASM_RET "jmp __x86_return_thunk\n\t"
#else /* CONFIG_MITIGATION_RETPOLINE */
#ifdef CONFIG_MITIGATION_SLS
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 9ea93a298a43..33f76848c838 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -289,7 +289,7 @@
* where we have a stack but before any RET instruction.
*/
.macro __UNTRAIN_RET ibpb_feature, call_depth_insns
-#if defined(CONFIG_RETHUNK) || defined(CONFIG_MITIGATION_IBPB_ENTRY)
+#if defined(CONFIG_MITIGATION_RETHUNK) || defined(CONFIG_MITIGATION_IBPB_ENTRY)
VALIDATE_UNRET_END
ALTERNATIVE_3 "", \
CALL_UNTRAIN_RET, X86_FEATURE_UNRET, \
@@ -328,7 +328,7 @@ extern retpoline_thunk_t __x86_indirect_thunk_array[];
extern retpoline_thunk_t __x86_indirect_call_thunk_array[];
extern retpoline_thunk_t __x86_indirect_jump_thunk_array[];

-#ifdef CONFIG_RETHUNK
+#ifdef CONFIG_MITIGATION_RETHUNK
extern void __x86_return_thunk(void);
#else
static inline void __x86_return_thunk(void) {}
diff --git a/arch/x86/include/asm/static_call.h b/arch/x86/include/asm/static_call.h
index 343b722ccaf2..125c407e2abe 100644
--- a/arch/x86/include/asm/static_call.h
+++ b/arch/x86/include/asm/static_call.h
@@ -46,7 +46,7 @@
#define ARCH_DEFINE_STATIC_CALL_TRAMP(name, func) \
__ARCH_DEFINE_STATIC_CALL_TRAMP(name, ".byte 0xe9; .long " #func " - (. + 4)")

-#ifdef CONFIG_RETHUNK
+#ifdef CONFIG_MITIGATION_RETHUNK
#define ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name) \
__ARCH_DEFINE_STATIC_CALL_TRAMP(name, "jmp __x86_return_thunk")
#else
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index b01d49862497..f7c11bef19bb 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -698,7 +698,7 @@ void __init_or_module noinline apply_retpolines(s32 *start, s32 *end)
}
}

-#ifdef CONFIG_RETHUNK
+#ifdef CONFIG_MITIGATION_RETHUNK

/*
* Rewrite the compiler generated return thunk tail-calls.
@@ -771,7 +771,7 @@ void __init_or_module noinline apply_returns(s32 *start, s32 *end)
}
#else
void __init_or_module noinline apply_returns(s32 *start, s32 *end) { }
-#endif /* CONFIG_RETHUNK */
+#endif /* CONFIG_MITIGATION_RETHUNK */

#else /* !CONFIG_MITIGATION_RETPOLINE || !CONFIG_OBJTOOL */

diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
index 77a9316da435..4eefaac64c6c 100644
--- a/arch/x86/kernel/static_call.c
+++ b/arch/x86/kernel/static_call.c
@@ -172,7 +172,7 @@ void arch_static_call_transform(void *site, void *tramp, void *func, bool tail)
}
EXPORT_SYMBOL_GPL(arch_static_call_transform);

-#ifdef CONFIG_RETHUNK
+#ifdef CONFIG_MITIGATION_RETHUNK
/*
* This is called by apply_returns() to fix up static call trampolines,
* specifically ARCH_DEFINE_STATIC_CALL_NULL_TRAMP which is recorded as
diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S
index 67b52cbec648..0045153ba222 100644
--- a/arch/x86/lib/retpoline.S
+++ b/arch/x86/lib/retpoline.S
@@ -127,7 +127,7 @@ SYM_CODE_END(__x86_indirect_jump_thunk_array)
#undef GEN
#endif

-#ifdef CONFIG_RETHUNK
+#ifdef CONFIG_MITIGATION_RETHUNK

/*
* Be careful here: that label cannot really be removed because in
@@ -386,4 +386,4 @@ SYM_CODE_START(__x86_return_thunk)
SYM_CODE_END(__x86_return_thunk)
EXPORT_SYMBOL(__x86_return_thunk)

-#endif /* CONFIG_RETHUNK */
+#endif /* CONFIG_MITIGATION_RETHUNK */
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0d5461276179..48a4a81edac1 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -263,7 +263,7 @@ objtool-args-$(CONFIG_HAVE_OBJTOOL_NOP_MCOUNT) += --mnop
endif
objtool-args-$(CONFIG_UNWINDER_ORC) += --orc
objtool-args-$(CONFIG_MITIGATION_RETPOLINE) += --retpoline
-objtool-args-$(CONFIG_RETHUNK) += --rethunk
+objtool-args-$(CONFIG_MITIGATION_RETHUNK) += --rethunk
objtool-args-$(CONFIG_MITIGATION_SLS) += --sls
objtool-args-$(CONFIG_STACK_VALIDATION) += --stackval
objtool-args-$(CONFIG_HAVE_STATIC_CALL_INLINE) += --static-call
diff --git a/tools/arch/x86/include/asm/disabled-features.h b/tools/arch/x86/include/asm/disabled-features.h
index 4b816f55c634..bd7071f34f6b 100644
--- a/tools/arch/x86/include/asm/disabled-features.h
+++ b/tools/arch/x86/include/asm/disabled-features.h
@@ -57,7 +57,7 @@
(1 << (X86_FEATURE_RETPOLINE_LFENCE & 31)))
#endif

-#ifdef CONFIG_RETHUNK
+#ifdef CONFIG_MITIGATION_RETHUNK
# define DISABLE_RETHUNK 0
#else
# define DISABLE_RETHUNK (1 << (X86_FEATURE_RETHUNK & 31))
--
2.34.1

2023-11-21 17:13:47

by Breno Leitao

[permalink] [raw]

On Wed, Jan 10, 2024 at 10:56:46AM +0100, Ingo Molnar wrote:
>
> * Breno Leitao <[email protected]> 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

2024-01-10 18:08:18

by Ingo Molnar

[permalink] [raw]

Subject: Re: [PATCH v6 00/13] x86/bugs: Add a separate config for each mitigation

* Breno Leitao <[email protected]> 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