Re: [PATCH 3/3] perf x86: Add .note.gnu.property to assembly linked into perf

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Adding .note.gnu.property asserts IBT support without providing ENDBR64 instructions, causing a #CP crash in perf memory benchmarks.
- [Medium] The .note.gnu.property section hardcodes 8-byte alignment, violating the 32-bit x86 ELF specification.
--

--- Patch [3]: [PATCH 3/3] perf x86: Add .note.gnu.property to assembly linked into perf ---
commit b48d7edb7fb18bc3dace2af272de108eb561d69b
Author: Trevor Allison <tallison@redhat.com>

perf x86: Add .note.gnu.property to assembly linked into perf

This commit adds `.note.gnu.property` to x86 assembly files linked into
perf to indicate CET properties support. This is intended to prevent static
linking from dropping CET from the final binary.

> diff --git a/tools/perf/arch/x86/tests/regs_load.S b/tools/perf/arch/x86/tests/regs_load.S
> index 80f14f52e3f60..1947f95cceda5 100644
> --- a/tools/perf/arch/x86/tests/regs_load.S
> +++ b/tools/perf/arch/x86/tests/regs_load.S
[ ... ]
> @@ -97,3 +97,27 @@ SYM_FUNC_END(perf_regs_load)
>   * the ELF stack should not be restricted at all and set it RWX.
>   */
>  .section .note.GNU-stack,"",@progbits
> +
> +/*
> + * We need to provide .note.gnu.property section with IBT and SHSTK,
> + * saying that this object supports the same CET properties as C code
> + * built with -fcf-protection. Otherwise static linking drops CET from
> + * the final perf binary when other objects are CET-enabled.
> + */
> +	.pushsection .note.gnu.property, "a"
> +	.p2align 3

[Severity: Medium]
Does this unconditionally hardcode 8-byte alignment for 32-bit x86 builds?

The assembly file `regs_load.S` can be compiled for 32-bit x86, which requires
4-byte alignment (`.p2align 2`) for ELF notes. When the linker merges these,
the forced 8-byte alignment can create zero-byte padding gaps between notes,
corrupting the contiguous ELF note structure.

Could this cause the dynamic loader or tools like `readelf` to fail to parse
the ELF notes properly?

[ ... ]
> diff --git a/tools/perf/bench/mem-memcpy-x86-64-asm.S b/tools/perf/bench/mem-memcpy-x86-64-asm.S
> index 1b9fef7efcdcc..e7b84aa43ab44 100644
> --- a/tools/perf/bench/mem-memcpy-x86-64-asm.S
> +++ b/tools/perf/bench/mem-memcpy-x86-64-asm.S
[ ... ]
> @@ -18,3 +18,27 @@
>   * the ELF stack should not be restricted at all and set it RWX.
>   */
>  .section .note.GNU-stack,"",@progbits
> +
> +/*
> + * We need to provide .note.gnu.property section with IBT and SHSTK,
> + * saying that this object supports the same CET properties as C code
> + * built with -fcf-protection. Otherwise static linking drops CET from
> + * the final perf binary when other objects are CET-enabled.
> + */
> +	.pushsection .note.gnu.property, "a"
> +	.p2align 3

[Severity: Medium]
Will this cause a Control Protection Exception (#CP) crash on IBT-capable
hardware when running `perf bench mem memcpy`?

Adding this section artificially claims IBT support and forces the linker to
enable CET on the final `perf` binary. However, `perf`'s local linkage headers
do not automatically emit `endbr64` instructions for `SYM_FUNC_START`.

When `do_memcpy()` in `tools/perf/bench/mem-functions.c` indirectly calls
these assembly entry points like `memcpy_orig`:

	fn(dst, src, size);

the hardware may detect the missing `endbr64` on the indirect branch target
and throw a #CP fault.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708045606.43649-1-tallison@redhat.com?part=3