linux-kernel - Re: RFD: x32 ABI system call numbers

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: <4E62638E.40308@zytor.com>
Date:	Sat, 03 Sep 2011 10:27:42 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Valdis.Kletnieks@...edu
CC:	Arnd Bergmann <arnd@...db.de>, "H.J. Lu" <hjl.tools@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Kuo <rkuo@...eaurora.org>,
	Mark Salter <msalter@...hat.com>,
	Jonas Bonn <jonas@...thpole.se>,
	Tobias Klauser <tklauser@...tanz.ch>
Subject: Re: RFD: x32 ABI system call numbers

On 09/03/2011 10:16 AM, Valdis.Kletnieks@...edu wrote:
>>
>> The complexity of changing that would be enormous.
>
> Oh, I know changing the x86-32 ABI is impossible - I meant changing the
> decision to emulate that ABI (as opposed to emulating the x86-64 ABI, or a
> variant thereof, or something else).  Or are we already commited to that
> route, even if we're still trying to figure out what syscalls to include?
>

About ioctl in particular, the ABI has dependencies into almost every 
single driver in the Linux kernel.  It is hard-coded in the kernel that 
there are two paths -- native and compat.  Since pointers are going to 
be 4 bytes, it means we have to use the compat path.

We may be able to cheat a little bit since we encode the argument sizes 
in the ioctl numbers; this solves the case of PPGETTIME/PPSETTIME for 
example (in fact, this ioctl looks currently broken in compat mode!) 
However, at some point the sheer number of data types that can be 
consumed by ioctl is a real concern, so changing the ones we really care 
about -- like timespec/timeval -- while leaving the rest intact so we 
can use the compat path as a general rule would be highly useful.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/