linux-kernel - Re: [PATCH v2 2/2] objtool: Use fPIE compatible ELF sections for C jump tables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250220212515.on6esv3rffkmdbkq@jpoimboe>
Date: Thu, 20 Feb 2025 13:25:15 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Ard Biesheuvel <ardb+git@...gle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
	Huacai Chen <chenhuacai@...nel.org>,
	Ard Biesheuvel <ardb@...nel.org>,
	Tiezhu Yang <yangtiezhu@...ngson.cn>
Subject: Re: [PATCH v2 2/2] objtool: Use fPIE compatible ELF sections for C
 jump tables

On Wed, Feb 19, 2025 at 11:55:45AM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@...nel.org>
> 
> A C jump table (such as the one used by the BPF interpreter) is a const
> global array of absolute code addresses, and this means that the actual
> values in the table may not be known until the kernel is booted (e.g.,
> when using KASLR or when the kernel VA space is sized dynamically).
> 
> When using -fPIE codegen, const global objects of this nature will
> generally be placed in .data.rel.ro rather than .rodata by the compiler,
> and forcing these C jump tables into .rodata like is done currently will
> trigger warnings from the linker about combining read-only and
> read-write input sections into the same output section.
>
> Avoid such warnings by unconditionally emitting C jump tables into
> .data.rel.ro, which will always be placed appropriately regardless of
> whether -fPIE is actually being used.

Just to clarify, currently there are no linker warnings.  The original
linker warnings (fixed by c5b1184decc8) were only with the GNU
toolchain, and only on LoongArch.  Clang/LLVM apparently didn't care.

The only problem being fixed here is that the hack in c5b1184decc8
doesn't work with Clang/LLVM, so the C jump tables get placed in
'.rodata..c_jump_table,"a",@progbits #'.  Which confuses objtool,
spitting out the following warning:

     kernel/bpf/core.o: warning: objtool: ___bpf_prog_run+0x20: sibling call from callable instruction with modified stack frame

> Note that, while possible in theory, compiler generated jump tables are
> unlikely to end up in .data.rel.ro, as the compiler will use relative
> references when using -fPIE, and these can be resolved at build time.
> 
> This supersedes commit
> 
>   c5b1184decc8 ("compiler.h: specify correct attribute for .rodata..c_jump_table")
> 
> which addressed the linker warnings by injecting section attributes into
> the __attribute__((section(""))) name string, but this turns out not to
> work reliably across toolchains, and may result in missing ORC data in
> some cases.

Missing ORC data was a side effect, it's really the warning which should
be called out in the description.

Also, since this is indeed a bug fix, that should be made clear in the
subject, something like:

  objtool: Fix C jump table annotations for Clang

> Fixes: c5b1184decc8 ("compiler.h: specify correct attribute for .rodata..c_jump_table")

Reported-by: https://lore.kernel.org/202501141306.GYbbghj5-lkp@intel.com

-- 
Josh