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: <20120119235446.GR7180@jl-vm1.vm.bytemark.co.uk>
Date:	Thu, 19 Jan 2012 23:54:46 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Lutomirski <luto@....edu>, Indan Zupancic <indan@....nu>,
	Andi Kleen <andi@...stfloor.org>,
	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!?

Linus Torvalds wrote:
> On Thu, Jan 19, 2012 at 8:01 AM, Jamie Lokier <jamie@...reable.org> wrote:
> > Andrew Lutomirski wrote:
> >> It's reasonable, obvious, and even more wrong than it appears.  On
> >> Xen, there's an extra 64-bit GDT entry, and it gets used by default.
> >> (I got bitten by this in some iteration of the vsyscall emulation
> >> patches -- see user_64bit_mode for the correct and
> >> unusable-from-user-mode way to do this.)
> >
> > Here it is:
> >
> >        static inline bool user_64bit_mode(struct pt_regs *regs)
> 
> This is pointless, even if it worked, which it clearly doesn't on Xen
> (or other random situations).
> 
> Why would you care?
> 
> The issue is *not* whether somebody is running in 32-bit mode or 64-bit mode.
> 
> The problem is the system call itself, and that can be 32-bit or
> 64-bit independently of the execution mode. So knowing the user-mode
> mode is simply not relevant.

Sorry, you're responding to a different question than the one I was
talking about.  My bad for adding to the confusion.

Mine was: strace currently checks the CS value and may have a bug on
existing/older kernels if Xen is involved when using the *normal*
syscall entry point (not int $0x80).  Can we patch strace to solve
that on those kernels in a generic way, or does the fix need to
hard-code knowledge of Xen's CS values (and any similar PV hypervisors
if there are any).

No amount of patching newer kernels will fix that, but it would be
nice if newer kernels made it unambiguous.

You've usefully pointed out that there's no reliable way to tell if
the tracee is executing in long mode.  If we're adding pseudo-flags to
say what kind of syscall it is, it would be no bad thing to have a
pseudo-flag to say if userspace is in long mode -- made available to
breakpoints and single-stepping as well.

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