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: <CAMe9rOrANCdgbhoY1F-hMc7Rbov_2O34A+MHTeYF3eieTP2EGw@mail.gmail.com>
Date:	Sun, 4 Sep 2011 14:25:53 -0700
From:	"H.J. Lu" <hjl.tools@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
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 Sun, Sep 4, 2011 at 2:13 PM, Arnd Bergmann <arnd@...db.de> wrote:
> 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.

This is one way to deal with itoctl.  I will leave it to Peter.

>> >> #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.
>

time_t isn't a problem since time_t/timeval/timespec are identical for
x32 and x86-64.  As for u64, I added NATIVE_LONG_TYPE, which is
defined as long long for x32,  and use it instead of long in types for
64bit system calls.


-- 
H.J.
--
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/