Re: [PATCH v19 3/5] perf inject/aslr: Implement sample address remapping

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] `PERF_SAMPLE_CPU` payload is blindly copied with `COPY_U64()`, failing to unpack and repack the 32-bit `cpu` and `res` fields, leading to data corruption on cross-endian hosts.
--

commit e3128f8fdbd9617d2687dd070d7cac54eeaa5333
Author: Ian Rogers <irogers@google.com>

perf inject/aslr: Implement sample address remapping

This commit adds sample address remapping logic to the ASLR tool. It handles
parsing sample events, remapping IPs, ADDRs, callchains, and branch stacks.
It also aims to preserve cross-endian compatibility by properly unpacking and
repacking the sequential 32-bit layouts into host endianness.

> diff --git a/tools/perf/util/aslr.c b/tools/perf/util/aslr.c
> --- a/tools/perf/util/aslr.c
> +++ b/tools/perf/util/aslr.c
[ ... ]
> @@ -616,13 +671,415 @@ static int aslr_tool__process_sample(const struct perf_tool *tool,
[ ... ]
> +	if (sample_type & PERF_SAMPLE_TID) {
> +		union {
> +			u64 val64;
> +			u32 val32[2];
> +		} u;
> +
> +		if (CHECK_BOUNDS(1, 1)) {
> +			ret = -EFAULT;
> +			goto out_put;
> +		}
> +		u.val32[0] = sample->pid;
> +		u.val32[1] = sample->tid;
> +		out_array[j++] = u.val64;
> +		i++;
> +	}
> +	if (sample_type & PERF_SAMPLE_TIME)
> +		COPY_U64(); /* time */
> +	if (sample_type & PERF_SAMPLE_ADDR)
> +		REMAP_U64(sample->addr);
> +	if (sample_type & PERF_SAMPLE_ID)
> +		COPY_U64(); /* id */
> +	if (sample_type & PERF_SAMPLE_STREAM_ID)
> +		COPY_U64(); /* stream_id */
> +	if (sample_type & PERF_SAMPLE_CPU)
> +		COPY_U64(); /* cpu, res */

[Severity: High]
Will this corrupt the CPU ID on cross-endian hosts?

When the perf core reads the input file, it byte-swaps all 64-bit payload
fields into host endianness. For PERF_SAMPLE_CPU, which consists of two
32-bit fields (cpu and res), this 64-bit byte-swap incorrectly reverses the
two fields.

The code correctly unpacks and repacks PERF_SAMPLE_TID using a union to
safely recover its two 32-bit fields, but uses a blind COPY_U64() here for
PERF_SAMPLE_CPU in aslr_tool__process_sample().

When the injected output file is written natively in host endianness, this
incorrectly-swapped 64-bit value is permanently saved. Later, when the new
profile is parsed, it will read the originally empty res field into data->cpu,
corrupting the CPU ID.

Should PERF_SAMPLE_CPU be unpacked and repacked similarly to PERF_SAMPLE_TID?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608054841.3856224-1-irogers@google.com?part=3