linux-kernel - Re: [tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new u64 field

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

Date:	Mon, 7 Mar 2016 09:49:54 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Peter Anvin <hpa@...or.com>, Dave Hansen <dave@...1.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Helge Deller <deller@....de>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new
 u64 field

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sat, Mar 5, 2016 at 8:52 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Sat, Mar 05, 2016 at 02:50:06PM +0100, Ingo Molnar wrote:
> >> A more workable method would be to have a test .c file that includes all UAPI
> >> structures in existence and defines a variable out of every single one, and then
> >> generates a list of sizeof() values or so. But even that isn't perfect: a
> >> structure might shift some fields forward, into a pre-existing hole, without
> >> changing the sizeof? We'd need a list of all field offsets in all structures to be
> >> really sure, and that's nasty.
> >
> > pahole has such logic, right?
> 
> sparse could be taught to warn about unaligned u64's, but there are
> still config issues and issues across other architectures, and if some
> case gets missed it can be really quite painful.

So I think what might work is to define bitness and alignment-independent ABI 
structures, and add (tooling) infrastructure to enforce that invariance.

For example every ABI detail in include/uapi/linux/perf_event.h is supposed to be 
alignment-independent: it should be the same structure and same fields on all 
32-bit and 64-bit platforms, regardless of the natural alignment of u64.

It's as close to an 'architecture independent' ABI as we can get IMHO. (With the 
notable exception of endianness: making endianness an invariant via dynamic 
endianness flags or so would be a mistake IMHO - structures that can be 
transmitted between different machines via network or via disk should pick one 
particular endianness statically and stick with that.)

If we can build tooling that checks _that_ kind of struct/ABI invariance, it would 
be a lot easier to ensure that future changes don't break the ABI.

New structures could be annotated to be arch-invariant, via something like:

	struct foo __arch_invariant_ABI {
		...
	};

and tooling could pick it up from there.

We do have a healthy body of 'messy' ABIs, which make liberal use of longs, 
unaligned u64's and other non-invariant constructs - those would have to be 
cleaned up and in the worst case they would have to be split into several explicit 
variants.

I tried to do something like that with a particularly messy x86 header lately, see 
arch/x86/include/uapi/asm/sigcontext.h, but it's a pretty slow and painful process 
altogether...

Thanks,

	Ingo