linux-hardening - Re: [PATCH v1 12/13] tools headers: Sync compiler.h headers

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]

Date: Mon, 11 Mar 2024 12:24:24 -0700
From: Ian Rogers <irogers@...gle.com>
To: James Clark <james.clark@....com>
Cc: Arnd Bergmann <arnd@...db.de>, Andrii Nakryiko <andrii@...nel.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.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>, 
	Adrian Hunter <adrian.hunter@...el.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	Shuah Khan <shuah@...nel.org>, Kees Cook <keescook@...omium.org>, 
	"Gustavo A. R. Silva" <gustavoars@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Liam Howlett <liam.howlett@...cle.com>, Miguel Ojeda <ojeda@...nel.org>, 
	Will Deacon <will@...nel.org>, Mark Brown <broonie@...nel.org>, 
	David Laight <David.Laight@...lab.com>, "Michael S. Tsirkin" <mst@...hat.com>, Shunsuke Mie <mie@...l.co.jp>, 
	Yafang Shao <laoar.shao@...il.com>, Kui-Feng Lee <kuifeng@...a.com>, 
	Nick Forrington <nick.forrington@....com>, Leo Yan <leo.yan@...ux.dev>, 
	German Gomez <german.gomez@....com>, Rob Herring <robh@...nel.org>, 
	John Garry <john.g.garry@...cle.com>, Sean Christopherson <seanjc@...gle.com>, 
	Anup Patel <anup@...infault.org>, Fuad Tabba <tabba@...gle.com>, 
	Andrew Jones <ajones@...tanamicro.com>, Chao Peng <chao.p.peng@...ux.intel.com>, 
	Haibo Xu <haibo1.xu@...el.com>, Peter Xu <peterx@...hat.com>, 
	Vishal Annapurve <vannapurve@...gle.com>, linux-kernel@...r.kernel.org, 
	linux-arch@...r.kernel.org, bpf@...r.kernel.org, 
	linux-perf-users@...r.kernel.org, kvm@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-hardening@...r.kernel.org, 
	llvm@...ts.linux.dev
Subject: Re: [PATCH v1 12/13] tools headers: Sync compiler.h headers

On Mon, Mar 11, 2024 at 9:34 AM James Clark <james.clark@....com> wrote:
>
>
>
> On 10/03/2024 02:05, Ian Rogers wrote:
> > compiler.h - synced from include/linux/compiler.h, guards were
> >  added to definitions to avoid redefinition of macros
> >  in libc. ftrace, CONFIG_OBJTOOL and kentry logic was removed as
> >  redundant.
> >
>
> Hi Ian,
>
> This commit breaks the Arm build (and cross compilation for Arm on x86):
>
>   $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
>
> Something like this, but I won't paste the whole output because it's huge:
>
> tools/include/linux/ring_buffer.h: In function ‘ring_buffer_read_head’:
>
> tools/include/asm/../../arch/arm64/include/asm/barrier.h:72:35: error:
> ‘__u8_alias_t’ undeclared (first use in this function)
>    72 |                         : "=r" (*(__u8_alias_t *)__u.__c)
>        \
>       |                                   ^~~~~~~~~~~~
> tools/include/linux/ring_buffer.h:59:16: note: in expansion of macro
> ‘smp_load_acquire’
>    59 |         return smp_load_acquire(&base->data_head);
>       |                ^~~~~~~~~~~~~~~~

Sorry for this James, I was rushing. I'll address the issues in v2 but
the one you highlight above doesn't look like a fun/simple issue to
resolve :-( Tbh, I'm not sure how much value tools/include has in its
current set up. It is weird the include order in perf prefers
tools/include/linux over tools/include/uapi. Current tools/include
seems to be trying to do a few different things:

1) provide headers like list.h so programs in tools can have linux
style lists, etc.
2) stuff that (1) drags in .. do we really want the asm barrier code
from arm? A sane user space program would be better using stdatomic.h,
plus that'd give the user space program an ability to get compiled on
to weirder targets like wasm. Plus we end up with weird type conflicts
like bool coming from linux/types.h rather than stdbool.h.
3) copies of kernel uapi headers that may be more up-to-date that
those in your system, thereby exposing constants that things like
libbpf depend upon.
4) headers with the same name as and that resemble kernel headers but
are really a reimplementation, like tools/include/linux/string.h
5) headers we have just so we can use shell scripts to scrape
constants for beautifying things in perf trace

For (1) and (2) it seems a separate library would be cleaner than
having the code in tools/include.
(3) feels like a legit use-case, so we should hold onto
tools/include/uapi, but do we want the asm directories?
(4) sounds like it should be in a library, perhaps with (1) and (2).
(5) feels like the headers should be alongside the shell scripts to
avoid polluting tools/include.
Not that I propose fixing any of this here.

Thanks,
Ian

> Thanks
> James