linux-kernel - Re: [PATCH v3] bpftool: Add CET-aware symbol matching for x86

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: <9f233a20-6649-4796-9ef4-a499382b0006@linux.dev>
Date: Mon, 21 Jul 2025 07:53:56 -0700
From: Yonghong Song <yonghong.song@...ux.dev>
To: chenyuan <chenyuan_fl@....com>
Cc: ast@...nel.org, qmo@...n.net, bpf@...r.kernel.org,
 linux-kernel@...r.kernel.org, Yuan Chen <chenyuan@...inos.cn>
Subject: Re: [PATCH v3] bpftool: Add CET-aware symbol matching for x86_64
 architectures



On 7/21/25 5:51 AM, chenyuan wrote:
> Apologies for any inaccuracies in my previous explanation. Below, I'll provide a brief clarification based
> on verification across both ARM64 and x86 platforms:
> arm64:
> Without kprobe/kprobe_multi Hook:
> (gdb) disassemble vfs_read
> Dump of assembler code for function vfs_read:
>     0xffffc000803ca308 <+0>:	bti	c   // ARM64 BTI security instruction
>     0xffffc000803ca30c <+4>:	nop
>     0xffffc000803ca310 <+8>:	nop
>     0xffffc000803ca314 <+12>:	paciasp
>     0xffffc000803ca318 <+16>:	sub	sp, sp, #0xa0
>
> With kprobe/kprobe_multi Hook:
> (gdb) disassemble vfs_read
> Dump of assembler code for function vfs_read:
>     0xffffc000803ca308 <+0>:	brk	#0x4  // BTI replaced by breakpoint
>     0xffffc000803ca30c <+4>:	mov	x9, x30
>     0xffffc000803ca310 <+8>:	nop
>     0xffffc000803ca314 <+12>:	paciasp
>     0xffffc000803ca318 <+16>:	sub	sp, sp, #0xa0

Thanks for checking. If this is the case, then I don't think we
need to checking
    if (dd.sym_mapping[i].address == data[j].addr - 4) for arm64. In you v3 
patch, the comment also only mentions x86_64.

>
> kprobe directly overwrites the first instruction (bti c → brk #0x4). Hook address (0xffffc000803ca308) matches
> the symbol address exactly.
>
> x86_64:
> Without kprobe/kprobe_multi Hook:
> (gdb) disassemble vfs_read
> Dump of assembler code for function vfs_read:
>     0xffffffff82112b40 <+0>:     endbr64  // x86 CET security instruction
>     0xffffffff82112b44 <+4>:     nopl   0x0(%rax,%rax,1)
>     0xffffffff82112b49 <+9>:     push   %r15
>     0xffffffff82112b4b <+11>:    mov    %rsi,%r15
>     0xffffffff82112b4e <+14>:    push   %r14
>     0xffffffff82112b50 <+16>:    push   %r13
>
> With kprobe/kprobe_multi Hook:
> (gdb) disassemble vfs_read
> Dump of assembler code for function vfs_read:
>     0xffffffff82112b40 <+0>:     endbr64   // Preserved security instruction
>     0xffffffff82112b44 <+4>:     call   0xffffffffa1830000  // Hook replaces nopl
>     0xffffffff82112b49 <+9>:     push   %r15
>     0xffffffff82112b4b <+11>:    mov    %rsi,%r15
>     0xffffffff82112b4e <+14>:    push   %r14
>     0xffffffff82112b50 <+16>:    push   %r13
>
> kprobe preserves endbr64 and overwrites the subsequent instruction (nopl → call). Hook address (0xffffffff82112b44)
> requires -4 offset (0xffffffff82112b40) to match the symbol address.
>
> ARM64 hooks replace the very first instruction (including security features like BTI), while x86_64 hooks target the instruction
> immediately after endbr64, creating a 4-byte offset that must be compensated for when resolving symbol addresses.

[...]