On 6/19/23 7:03 AM, Florent Revest wrote:
On Fri, Jun 16, 2023 at 6:57 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
On Thu, Jun 15, 2023 at 7:56 AM Florent Revest <revest@xxxxxxxxxxxx> wrote:
When building a kernel with LLVM=1, LLVM_IAS=0 and CONFIG_KASAN=y, LLVM
leaves DWARF tags for the "asan.module_ctor" & co symbols. In turn,
pahole creates BTF_KIND_FUNC entries for these and this makes the BTF
metadata validation fail because they contain a dot.
In a dramatic turn of event, this BTF verification failure can cause
the netfilter_bpf initialization to fail, causing netfilter_core to
free the netfilter_helper hashmap and netfilter_ftp to trigger a
use-after-free. The risk of u-a-f in netfilter will be addressed
separately but the existence of "asan.module_ctor" debug info under some
build conditions sounds like a good enough reason to accept functions
that contain dots in BTF.
I don't see much harm in allowing dots. There are also all those .isra
and other modifications to functions that we currently don't have in
BTF, but with the discussions about recording function addrs we might
eventually have those as well. So:
Acked-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
Thanks Andrii! :)
Cc: stable@xxxxxxxxxxxxxxx
Fixes: 1dc92851849c ("bpf: kernel side support for BTF Var and DataSec")
So do you think these trailers should be kept ? I suppose we can
either see this as a "new feature" to accommodate .isra that should go
through bpf-next or as a bug fix that goes through bpf and gets
backported to stable (without this, BTF wouldn't work on old kernels
built under a new clang and with LLVM_IAS=0 and CONFIG_KASAN=y so this
sounds like a legitimate bug fix to me, I just wanted to double check)
How many people really build the kernel with
LLVM=1 LLVM_IAS=0
which uses clang compiler ans gcc 'as'.
I think distro most likely won't do this if they intend to
build the kernel with clang.
Note that
LLVM=1
implies to use both clang compiler and clang assembler.
Using clang17 and 'LLVM=1 LLVM_IAS=0', with latest bpf-next,
I actually hit some build errors like:
/tmp/video-bios-59fa52.s: Assembler messages:
/tmp/video-bios-59fa52.s:4: Error: junk at end of line, first
unrecognized character is `"'
/tmp/video-bios-59fa52.s:4: Error: file number less than one
/tmp/video-bios-59fa52.s:5: Error: junk at end of line, first
unrecognized character is `"'
/tmp/video-bios-59fa52.s:6: Error: junk at end of line, first
unrecognized character is `"'
/tmp/video-bios-59fa52.s:7: Error: junk at end of line, first
unrecognized character is `"'
/tmp/video-bios-59fa52.s:8: Error: junk at end of line, first
unrecognized character is `"'
/tmp/video-bios-59fa52.s:9: Error: junk at end of line, first
unrecognized character is `"'
/tmp/video-bios-59fa52.s:10: Error: junk at end of line, first
unrecognized character is `"'
/tmp/video-bios-59fa52.s:68: Error: junk at end of line, first
unrecognized character is `"'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
make[4]: *** [/home/yhs/work/bpf-next/scripts/Makefile.build:252:
arch/x86/realmode/rm/video-bios.o] Error 1
make[4]: *** Waiting for unfinished jobs....
/tmp/wakemain-88777c.s: Assembler messages:
/tmp/wakemain-88777c.s:4: Error: junk at end of line, first unrecognized
character is `"'
/tmp/wakemain-88777c.s:4: Error: file number less than one
/tmp/wakemain-88777c.s:5: Error: junk at end of line, first unrecognized
character is `"'
/tmp/wakemain-88777c.s:6: Error: junk at end of line, first unrecognized
character is `"'
/tmp/wakemain-88777c.s:7: Error: junk at end of line, first unrecognized
character is `"'
/tmp/wakemain-88777c.s:8: Error: junk at end of line, first unrecognized
character is `"'
/tmp/wakemain-88777c.s:81: Error: junk at end of line, first
unrecognized character is `"'
/tmp/wakemain-88777c.s:312: Error: junk at end of line, first
unrecognized character is `"'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
Potentially because of my local gnu assembler 2.30-120.el8 won't work
with some syntax generated by clang. Mixing clang compiler and arbitrary
gnu assembler are not a good idea (see the above example). It might
work with close-to-latest gnu assembler.
To support function name like '<fname>.isra', some llvm work will be
needed, and it may take some time.
So in my opinion, this patch is NOT a bug fix. It won't affect distro.
Whether we should backport to the old kernel, I am not sure whether it
is absolutely necessary as casual build can always remove LLVM_IAS=0 or
hack the kernel source itself.
