On 10/21/24 3:40 AM, Jiri Olsa wrote:
On Sun, Oct 20, 2024 at 09:32:38PM -0700, Yonghong Song wrote:
On 10/20/24 2:59 PM, Jiri Olsa wrote:
On Sun, Oct 20, 2024 at 12:14:31PM -0700, Yonghong Song wrote:
SNIP
+__naked __noinline __used
+static unsigned long loop_callback(void)
+{
+ asm volatile (
+ "call %[bpf_get_prandom_u32];"
+ "r1 = 42;"
+ "*(u64 *)(r10 - 512) = r1;"
+ "call cumulative_stack_depth_subprog;"
+ "r0 = 0;"
+ "exit;"
+ :
+ : __imm(bpf_get_prandom_u32)
+ : __clobber_common);
+}
+
+SEC("raw_tp")
+__description("Private stack, callback")
+__success
+__arch_x86_64
+/* for func loop_callback */
+__jited("func #1")
+__jited(" endbr64")
this should fail if CONFIG_X86_KERNEL_IBT is not enabled, right?
hm, but I can see that also in other tests, so I guess it's fine,
should we add it to config.x86_64 ?
The CI has CONFIG_X86_KERNEL_IBT as well.
I checked x86 kconfig, I see
config CC_HAS_IBT
# GCC >= 9 and binutils >= 2.29
# Retpoline check to work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654
# Clang/LLVM >= 14
# https://github.com/llvm/llvm-project/commit/e0b89df2e0f0130881bf6c39bf31d7f6aac00e0f
# https://github.com/llvm/llvm-project/commit/dfcf69770bc522b9e411c66454934a37c1f35332
def_bool ((CC_IS_GCC && $(cc-option, -fcf-protection=branch -mindirect-branch-register)) || \
(CC_IS_CLANG && CLANG_VERSION >= 140000)) && \
$(as-instr,endbr64)
config X86_KERNEL_IBT
prompt "Indirect Branch Tracking"
def_bool y
depends on X86_64 && CC_HAS_IBT && HAVE_OBJTOOL
# https://github.com/llvm/llvm-project/commit/9d7001eba9c4cb311e03cd8cdc231f9e579f2d0f
depends on !LD_IS_LLD || LLD_VERSION >= 140000
select OBJTOOL
select X86_CET
help
Build the kernel with support for Indirect Branch Tracking, a
hardware support course-grain forward-edge Control Flow Integrity
protection. It enforces that all indirect calls must land on
an ENDBR instruction, as such, the compiler will instrument the
code with them to make this happen.
In addition to building the kernel with IBT, seal all functions that
are not indirect call targets, avoiding them ever becoming one.
This requires LTO like objtool runs and will slow down the build. It
does significantly reduce the number of ENDBR instructions in the
kernel image.
So CONFIG_X86_KERNEL_IBT will be enabled if clang >= version_14 or newer gcc.
IIUC it's just dependency, no? doesn't mean it'll get enabled automatically
In my system, the gcc version is 13.1. So there is no need to explicitly add
CONFIG_X86_KERNEL_IBT to the selftests/bpf/config.x86_64 file.
I had to enable it manualy for gcc 13.3.1
IIUC, the ci config is generated based on config + config.x86_64 + config.vm
in tools/testing/selftests/bpf directory.
In my case .config is generated from config + config.x86_64 + config.vm
With my local gcc 11.5, I did
make olddefconfig
and I see CONFIG_X86_KERNEL_IBT=y is set.
Maybe your base config is a little bit different from what ci used.
My local config is based on ci config + some more e.g. enabling KASAN etc.
Could you debug a little more on why CONFIG_X86_KERNEL_IBT not enabled
by default in your case? For
config X86_KERNEL_IBT
prompt "Indirect Branch Tracking"
def_bool y
depends on X86_64 && CC_HAS_IBT && HAVE_OBJTOOL
# https://github.com/llvm/llvm-project/commit/9d7001eba9c4cb311e03cd8cdc231f9e579f2d0f
depends on !LD_IS_LLD || LLD_VERSION >= 140000
select OBJTOOL
select X86_CET
default is 'y' so if all dependencies are met, CONFIG_X86_KERNEL_IBT
is supposed to be on by default.
jirka
