[tip:,x86/bugs] x86/retpoline: Make sure there are no unconverted return thunks due to KCSAN

Message ID 169756514789.3135.9006141912388432463.tip-bot2@tip-bot2
State New
Headers
Series [tip:,x86/bugs] x86/retpoline: Make sure there are no unconverted return thunks due to KCSAN |

Commit Message

tip-bot2 for Thomas Gleixner Oct. 17, 2023, 5:52 p.m. UTC
  The following commit has been merged into the x86/bugs branch of tip:

Commit-ID:     28860182b7d88e5be76f332c34377288ad08e87a
Gitweb:        https://git.kernel.org/tip/28860182b7d88e5be76f332c34377288ad08e87a
Author:        Josh Poimboeuf <jpoimboe@kernel.org>
AuthorDate:    Tue, 17 Oct 2023 09:59:46 -07:00
Committer:     Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Tue, 17 Oct 2023 19:46:04 +02:00

x86/retpoline: Make sure there are no unconverted return thunks due to KCSAN

Enabling CONFIG_KCSAN causes the undefined opcode exception diagnostic
added by

  91174087dcc7 ("x86/retpoline: Ensure default return thunk isn't used at runtime")

which is supposed to catch unconverted, default return thunks, to fire.
The resulting panic is triggered by the UD2 instruction which gets
patched into __x86_return_thunk() when alternatives are applied.  After
that point, the default return thunk should no longer be used.

As David Kaplan describes in his debugging of the issue, it is caused by
a couple of KCSAN-generated constructors which aren't processed by
objtool:

  "When KCSAN is enabled, GCC generates lots of constructor functions
  named _sub_I_00099_0 which call __tsan_init and then return.  The
  returns in these are generally annotated normally by objtool and fixed
  up at runtime.  But objtool runs on vmlinux.o and vmlinux.o does not
  include a couple of object files that are in vmlinux, like
  init/version-timestamp.o and .vmlinux.export.o, both of which contain
  _sub_I_00099_0 functions.  As a result, the returns in these functions
  are not annotated, and the panic occurs when we call one of them in
  do_ctors and it uses the default return thunk.

  This difference can be seen by counting the number of these functions in the object files:
  $ objdump -d vmlinux.o|grep -c "<_sub_I_00099_0>:"
  2601
  $ objdump -d vmlinux|grep -c "<_sub_I_00099_0>:"
  2603

  If these functions are only run during kernel boot, there is no
  speculation concern."

Fix it by disabling KCSAN on version-timestamp.o and .vmlinux.export.o
so the extra functions don't get generated.  KASAN and GCOV are already
disabled for those files.

  [ bp: Massage commit message. ]

Fixes: 91174087dcc7 ("x86/retpoline: Ensure default return thunk isn't used at runtime")
Closes: https://lore.kernel.org/lkml/20231016214810.GA3942238@dev-arch.thelio-3990X/
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Marco Elver <elver@google.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20231017165946.v4i2d4exyqwqq3bx@treble
---
 init/Makefile            | 1 +
 scripts/Makefile.vmlinux | 1 +
 2 files changed, 2 insertions(+)
  

Patch

diff --git a/init/Makefile b/init/Makefile
index ec557ad..cbac576 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -60,4 +60,5 @@  include/generated/utsversion.h: FORCE
 $(obj)/version-timestamp.o: include/generated/utsversion.h
 CFLAGS_version-timestamp.o := -include include/generated/utsversion.h
 KASAN_SANITIZE_version-timestamp.o := n
+KCSAN_SANITIZE_version-timestamp.o := n
 GCOV_PROFILE_version-timestamp.o := n
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index 3cd6ca1..c9f3e03 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -19,6 +19,7 @@  quiet_cmd_cc_o_c = CC      $@
 
 ifdef CONFIG_MODULES
 KASAN_SANITIZE_.vmlinux.export.o := n
+KCSAN_SANITIZE_.vmlinux.export.o := n
 GCOV_PROFILE_.vmlinux.export.o := n
 targets += .vmlinux.export.o
 vmlinux: .vmlinux.export.o