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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3546423.kFMPx0aPCi@wuerfel>
Date:	Sun, 04 Sep 2011 17:17:59 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Valdis.Kletnieks@...edu, "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 Saturday 03 September 2011 10:27:42 H. Peter Anvin wrote:
> 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.

The ppdev ioctls are indeed missing in user space, and they are
an example for a different problem than the one I meant.

We really have a number of different cases that we will have to
deal with in different ways:

* different layout and ioctl code due to padding on x86-32,
  x32 is compatible:
  DRM_IOCTL_RADEON_SETPARAM
  DRM_IOCTL_UPDATE_DRAW32
  EXT4_IOC32_GROUP_ADD

* different layout due to padding on x86-32, but same ioctl code:
  RAW_SETBIND
  RAW_GETBIND

* uses time_t, different ioctl code:
  PPPIOCGIDLE32
  VIDIOC_DQBUF32
  VIDIOC_QBUF32
  VIDIOC_QUERYBUF32
  VIDIOC_DQEVENT32

* uses time_t, same ioctl code:
  VIDEO_GET_EVENT
  LPSETTIMEOUT

* Different alignment, three different ioctl numbers:
  FS_IOC_RESVSP_32
  FS_IOC_RESVSP64_32

* manually checks if compat_task:
  input/evdev

* Very complex, no easy solution:
  XFS_IOC_*

* Only needed for x86-32, not for x32:
  sys_quotactl

* Data structures embed time values, not an ioctl
  sys_sendmsg (cmsg)
  sys_recvmsg (cmsg)
  sys_mq_*
  sys_semtimedop

For a lot of these cases, the best option is to change the
kernel headers to use new definitions on x32 before someone
tries to ship a distro, especially when the ioctl command code
is fixed. In case of the XFS ioctls, I think the only sane
way is define the x32 ABI to match the 64 bit ABI completely,
while for RAW_GETBIND and VIDEO_GET_EVENT it's probably enough
to make x32 match x86-32.

	Arnd
--
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/