Re: [PATCH v5] bpftool: Add CET-aware symbol matching for x86_64 architectures

[Yonghong Song <yonghong.song@linux.dev>]

On 7/23/25 6:08 AM, Jiri Olsa wrote:
> On Wed, Jul 23, 2025 at 10:20:43AM +0800, chenyuan_fl@163.com wrote:
>> From: Yuan Chen <chenyuan@kylinos.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@kylinos.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
>>
>>