linux-kernel - Re: [PATCH v5] 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] [day] [month] [year] [list]

Message-ID: <74709a08-4536-4c5a-8140-12d8b42e97c0@linux.dev>
Date: Wed, 23 Jul 2025 08:52:06 -0700
From: Yonghong Song <yonghong.song@...ux.dev>
To: Jiri Olsa <olsajiri@...il.com>,
 aef2617b-ce03-4830-96a7-39df0c93aaad@...nel.org
Cc: qmo@...nel.org, ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
 bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
 Yuan Chen <chenyuan@...inos.cn>
Subject: Re: [PATCH v5] bpftool: Add CET-aware symbol matching for x86_64
 architectures



On 7/23/25 6:08 AM, Jiri Olsa wrote:
> On Wed, Jul 23, 2025 at 10:20:43AM +0800, chenyuan_fl@....com wrote:
>> From: Yuan Chen <chenyuan@...inos.cn>
>>
>> Adjust symbol matching logic to account for Control-flow Enforcement
>> Technology (CET) on x86_64 systems. CET prefixes functions with
>> a 4-byte 'endbr' instruction, shifting the actual hook entry point to
>> symbol + 4.
>>
>> Changed in PATCH v4:
>> * Refactor repeated code into a function.
>> * Add detection for the x86 architecture.
>>
>> Changed int PATH v5:
>> * Remove detection for the x86 architecture.
>>
>> Signed-off-by: Yuan Chen <chenyuan@...inos.cn>
>> ---
>>   tools/bpf/bpftool/link.c | 26 ++++++++++++++++++++++++--
>>   1 file changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
>> index a773e05d5ade..288bf9a032a5 100644
>> --- a/tools/bpf/bpftool/link.c
>> +++ b/tools/bpf/bpftool/link.c
>> @@ -282,6 +282,28 @@ get_addr_cookie_array(__u64 *addrs, __u64 *cookies, __u32 count)
>>   	return data;
>>   }
>>   
>> +static bool
>> +symbol_matches_target(__u64 sym_addr, __u64 target_addr)
>> +{
>> +	if (sym_addr == target_addr)
>> +		return true;
>> +
>> +#if defined(__x86_64__)
>> +	/*
>> +	 * On x86_64 architectures with CET (Control-flow Enforcement Technology),
>> +	 * function entry points have a 4-byte 'endbr' instruction prefix.
>> +	 * This causes kprobe hooks to target the address *after* 'endbr'
>> +	 * (symbol address + 4), preserving the CET instruction.
>> +	 * Here we check if the symbol address matches the hook target address
>> +	 * minus 4, indicating a CET-enabled function entry point.
>> +	 */
>> +	if (sym_addr == target_addr - 4)
>> +		return true;
>> +#endif
> looks good.. perhaps it might be too much, but should we try to read
> CONFIG_X86_KERNEL_IBT value and do the check based on that? there's
> already some code reading options in probe_kernel_image_config

Sounds a good idea. Maybe we can abstract out a helper function
based on probe_kernel_image_config() so it can be used in
both probe_kernel_image_config() and for this symbol_matches_target
case. We can have a variable like 'ibt_supported = ...' outside
the loop. In the above we can do
	if (ibt_supported && sym_addr == target_addr - 4)
		return true;

>
> jirka
>
>> +
>> +	return false;
>> +}
>> +
>>   static void
>>   show_kprobe_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
>>   {
>> @@ -307,7 +329,7 @@ show_kprobe_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
>>   		goto error;
>>   
>>   	for (i = 0; i < dd.sym_count; i++) {
>> -		if (dd.sym_mapping[i].address != data[j].addr)
>> +		if (!symbol_matches_target(dd.sym_mapping[i].address, data[j].addr))
>>   			continue;
>>   		jsonw_start_object(json_wtr);
>>   		jsonw_uint_field(json_wtr, "addr", dd.sym_mapping[i].address);
>> @@ -744,7 +766,7 @@ static void show_kprobe_multi_plain(struct bpf_link_info *info)
>>   
>>   	printf("\n\t%-16s %-16s %s", "addr", "cookie", "func [module]");
>>   	for (i = 0; i < dd.sym_count; i++) {
>> -		if (dd.sym_mapping[i].address != data[j].addr)
>> +		if (!symbol_matches_target(dd.sym_mapping[i].address, data[j].addr))
>>   			continue;
>>   		printf("\n\t%016lx %-16llx %s",
>>   		       dd.sym_mapping[i].address, data[j].cookie, dd.sym_mapping[i].name);
>> -- 
>> 2.25.1
>>
>>