linux-kernel - Re: Compat 32-bit syscall entry from 64-bit task!?

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: <CA+55aFwMd8MMrcfG5f0zg=qjrBzUhgY1HgJx6QFcnpMQsW1PNg@mail.gmail.com>
Date:	Wed, 18 Jan 2012 12:26:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Indan Zupancic <indan@....nu>, "H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Jamie Lokier <jamie@...reable.org>,
	Andrew Lutomirski <luto@....edu>,
	Oleg Nesterov <oleg@...hat.com>,
	Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
	keescook@...omium.org, john.johansen@...onical.com,
	serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, eparis@...hat.com, djm@...drot.org,
	segoon@...nwall.com, rostedt@...dmis.org, jmorris@...ei.org,
	scarybeasts@...il.com, avi@...hat.com, penberg@...helsinki.fi,
	viro@...iv.linux.org.uk, mingo@...e.hu, akpm@...ux-foundation.org,
	khilman@...com, borislav.petkov@....com, amwang@...hat.com,
	ak@...ux.intel.com, eric.dumazet@...il.com, gregkh@...e.de,
	dhowells@...hat.com, daniel.lezcano@...e.fr,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com,
	Roland McGrath <mcgrathr@...omium.org>
Subject: Re: Compat 32-bit syscall entry from 64-bit task!?

Added Peter to the cc, since this is now about some x86-specific
things. Ingo was already cc'd earlier.

On Wed, Jan 18, 2012 at 11:31 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Using the high bits of 'eflags' might work. Hopefully nobody tests
> that. IOW, something like the attached might work. It just sets bit#32
> in eflags if the system call is a compat call.

So that description was bogus, it was what my original patch did, but
not the one I actually sent out (Peter - you can find it on lkml,
although the description below is probably sufficient for you to
understand what it does, or the obvious nature of the attached patch
for strace).

The one I sent out *unconditionally* sets one bit in the high bits of
the returned value of the eflags register from ptrace(), very much on
purpose. That way you can unambiguously see whether it's an old kernel
(bits clear) or a new kernel that supports the feature. On a new
kernel, bit #32 of eflags will be set for a native 64-bit system call,
and bit #33 will be set for a compat system call.

And some testing says that it works. In particular, I have a patch to
strace-4.6 that is able to correctly decode my mixed-case binary that
uses both the compat system call and the native system calls from
64-bit long mode. Also, it looks like gdb ignores the high bits of
eflags, since it "knows" that eflags is just a 32-bit register even in
64-bit mode, so the fact that we set some random bits in there doesn't
end up being noisy for at least one debugger.

HOWEVER. I'm not going to guarantee that this is the right approach.
It seems to work, and it clearly gives people real information, but
whether this is the best way to do things or not is open.

The reason I picked 'eflags' was that it

 (a) was easy from an implementation standpoint, since we already have
to handle reading of eflags specially in ptrace (we have to fake out
the resume bit)

 (b) it "kind of" makes sense to make high bits be "system flags",
with low bits being "cpu flags", so it fits at least *some* kind of
conceptual model.

 (c) the other sane places to put it (high bits of CS and/or ORIG_AX)
were being used and compared as 64-bit values at least by strace.
Whether eflags works for all users, I have no idea, but generally you
would never compare eflags for one particular value - you might check
individual bits in eflags, but hopefully setting a few new bits should
not be something that any legacy user would ever really notice.

So there are reasons to think that my patch is sane, but...

Here's the strace patch, so people can look. I didn't even test it on
an old kernel, but the fallback case to the old behavior looks
trivial.

Comments?

                     Linus

View attachment "strace.diff" of type "text/x-patch" (1031 bytes)