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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aIDe3IR2SR6S0WM9@krava>
Date: Wed, 23 Jul 2025 15:08:44 +0200
From: Jiri Olsa <olsajiri@...il.com>
To: aef2617b-ce03-4830-96a7-39df0c93aaad@...nel.org
Cc: qmo@...nel.org, ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
	yonghong.song@...ux.dev, 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 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

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
> 
>