linux-kernel - Re: [PATCH v2 1/4] perf build: enable -fno-strict-aliasing

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: <20250616011353.GA58711@sol>
Date: Sun, 15 Jun 2025 18:13:53 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Liang Kan <kan.liang@...ux.intel.com>,
	Yuzhuo Jing <yuzhuo@...gle.com>
Subject: Re: [PATCH v2 1/4] perf build: enable -fno-strict-aliasing

On Sun, Jun 15, 2025 at 04:40:45PM -0700, Ian Rogers wrote:
> On Fri, Jun 13, 2025 at 9:43 PM Eric Biggers <ebiggers@...nel.org> wrote:
> >
> > From: Eric Biggers <ebiggers@...gle.com>
> >
> > perf pulls in code from kernel headers that assumes it is being built
> > with -fno-strict-aliasing, namely put_unaligned_*() from
> > <linux/unaligned.h> which write the data using packed structs that lack
> > the may_alias attribute.  Enable -fno-strict-aliasing to prevent
> > miscompilations in sha1.c which would otherwise occur due to this issue.
> 
> Wow, good catch! I wonder if -fsanitize=type could be used to capture
> when perf's code is broken like this? Perhaps we should just remove
> linux/unaligned.h in tools because of this, the alternative of using
> memcpy doesn't look particularly burdensome. Given the memcpys are of
> a known/fixed size I'd expect the compiler to be able to optimize
> things just as well. Perhaps we should rewrite unaligned.h in tools
> but perhaps the kernel too. Something like:
> 
> #define __get_unaligned_t(type, ptr) ({
>                  \
>         const struct { type x; } __packed * __get_pptr =
> (typeof(__get_pptr))(ptr);     \
>         __get_pptr->x;
>                  \
> })
> 
> becomes:
> 
> #define __get_unaligned_t(type, ptr) ({
>                  \
>         type __get_val; memcpy(&__get_val, ptr, sizeof(__get_val));     \
>         __get_val;
>              \
> })

As far as I know, the packed struct method of doing unaligned memory accesses is
obsolete these days, and memcpy() generates the desired code on all supported
architectures and compilers.

- Eric