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]

Date:	Sun, 04 Sep 2011 23:13:10 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"H.J. Lu" <hjl.tools@...il.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Valdis.Kletnieks@...edu,
	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 Sunday 04 September 2011 12:31:25 H.J. Lu wrote:
> On Sun, Sep 4, 2011 at 12:06 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >> #define __NR_x32_ioctl
> >
> > What do you plan to do for ioctl? Does this mean you want to
> > have a third file_operations pointer besides ioctl and compat_ioctl?
> > I would hope that you manage this by using different ioctl command
> > numbers in the few cases where the x32 version has to differ from
> > the x86-32 data structure.
> 
> This requires some kernel changes since x32 has 32bit pointers and 64bit
> time_t/timespec/timeval.   We can't use straight x86-32 nor x86-64.

I understand that it's not easy, but how do you want to get there?
There is no central implementation of ioctl, it's all in the device drivers!

My point was that the part that you do control is the ABI for x32, so
you can change the driver's header files to do things like

#ifndef __x32__
struct foo_ioctl_data {
	time_t	time;
	long		something_else;
	__u64		something_big;
};
#else
struct foo_ioctl_data {
	time_t	time;
	long long	something_else;
	__u64		something_big;
};
#endif

#define FOO_IOCTL_BAR _IOR('f', 0, struct foo_ioctl_data)

#ifdef __KERNEL__
struct compat_foo_ioctl_data {
	compat_time_t	time;
	compat_long_t	something_else;
	compat_u64		something_big;
};
#define FOO_IOCTL32_BAR _IOR('f', 0, struct compat_foo_ioctl_data)

static long foo_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
	void __user *uptr = compat_ptr(arg)

	switch (cmd) {
		case FOO_IOCTL32_BAR: /* regular compat case */
			return foo_compat_ioctl_bar(filp, uptr);
		case FOO_IOCTL_BAR: /* x32 passing native struct */
			return foo_ioctl_bar(filp, uptr);
	}
	return -ENOIOCTLCMD;
}

This way, the same compat_ioctl function can easily support both x86-32 and
x32. In fact, many compat_ioctl handlers already contain two code paths for the
compat_u64 case, where they fall back on the native handler for anything but x86.

> >> #define __NR_x32_recvfrom
> >> #define __NR_x32_sendmsg
> >> #define __NR_x32_recvmsg
> >> #define __NR_x32_recvmmsg
> >> #define __NR_x32_sendmmsg
> >
> > These today use the MSG_CMSG_COMPAT flag to distinguish native and compat
> > calls. Do you plan to have another flag here to handle cmsg time values?
> 
> I am using x86-32 calls for them.
>
> > What about things like mq_{get,set}attr, quotactl and semtimedop?
> >
> 
> I am using 64bit system calls for x32.

But isn't that broken? These all pass u64 or time_t values at some point.

	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/