Date:	Thu, 26 Jan 2012 00:59:01 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Indan Zupancic <indan@....nu>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Lutomirski <luto@....edu>,
	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!?

Denys Vlasenko wrote:
> On Wednesday 25 January 2012 20:36, Oleg Nesterov wrote:
> > On 01/18, Linus Torvalds wrote:
> > >
> > > Using the high bits of 'eflags' might work.
> > 
> > I thought about changing eflags too, this looks very natural to me.
> > 
> > But I do not understand the result of this discussion, are you going
> > to apply this change?
> > 
> > If not...
> > 
> > Not sure this is really better, but there is another idea. Currently we
> > have PTRACE_O_TRACESYSGOOD to avoid the confusion with the real SIGTRAP.
> > Perhaps we can add PTRACE_O_TRACESYS_VERY_GOOD (or we can look at
> > PT_SEIZED instead) and report TS_COMPAT via ptrace_report_syscall ?
> > 
> > IOW. Currently ptrace_report_syscall() does
> > 
> > 	ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
> > 
> > We can add the new events,
> > 
> > 	PTRACE_EVENT_SYSCALL_ENTRY
> > 	PTRACE_EVENT_SYSCALL_COMPAT_ENTRY
> > 	PTRACE_EVENT_SYSCALL_EXIT
> > 	PTRACE_EVENT_SYSCALL_COMPAT_EXIT
> 
> We can get away with just the first one.
> (1) It's unlikely people would want to get native sysentry events but not compat ones,
> thus first two options can be combined into one;

Tracers mainly want to know if it's a 32-bit or 64-bit syscall, not
whether it's compat as such.

I'm thinking it might be a little kinder like this:

#define PTRACE_EVENT_SYSCALL_ENTRY_ABI32 (...)
#define PTRACE_EVENT_SYSCALL_ENTRY_ABI64 (...)

#ifdef CONFIG_64BIT
# define PTRACE_EVENT_SYSCALL_ENTRY         PTRACE_EVENT_SYSCALL_ENTRY_ABI64
# define PTRACE_EVENT_SYSCALL_ENTRY_COMPAT  PTRACE_EVENT_SYSCALL_ENTRY_ABI32
#else
# define PTRACE_EVENT_SYSCALL_ENTRY         PTRACE_EVENT_SYSCALL_ENTRY_ABI32
#endif

So the ABI is represented directly, with the _ENTRY referring to the
tracer's own.  (Other ABI numbers can exist, e.g. OABI and EABI for
ARM, see below.)

This has the two specific advantages:

  1. It can match on specific ABI or regular/compat, as suits the tracer's code.
  2. When a 32-bit *tracer* is running a 64-bit *tracee* as least it knows ;-)

With your idea, what happens in situation 2?  I'm not sure a 32-bit
tracee can do anything useful, because it can't get the 64-bit
registers, but at least it can see when it's got the wrong registers :-)

> (2) syscall exit compat-ness is known from entry type - no need to indicate it; and
> (3) if we would flag syscall entry with an event value in wait status, then syscall
> exit will be already distinquisable.
>
> Thus, minimally we need one new option, PTRACE_O_TRACE_SYSENTRY -
> "on syscall entry ptrace stop, set a nonzero event value in wait status"
> , and two event values: PTRACE_EVENT_SYSCALL_ENTRY (for native entry),
> PTRACE_EVENT_SYSCALL_ENTRY1 for compat one.

PTRACE_EVENT_SYSCALL_EXIT would cleanly indicate that the new option
is actually working without the tracer needing to do a fork+test, if
PTRACE_ATTACH is used and for some reason the tracer sees a syscall
exit first.  I'm not sure if this can happen but I've heard rumour of
it on some archs or kernel versions.

> To future-proof this scheme we may reserve a few more event values
> PTRACE_EVENT_SYSCALL_ENTRY2, PTRACE_EVENT_SYSCALL_ENTRY3, etc,
> if we'll ever have arches with more than one non-native syscall
> entry.

> I'm no expert, but looking at strace code, ARM may already have
> more than one additional convention how to pass syscall args.

I was just looking at ARM and see exactly the same thing.  The
difference between EABI and OABI calls is significant on ARM, even
though syscall numbers are the same; and the ABI is selected by the
syscall instruction used, not process personality.  The __NR_name
values differ for each ABI, but (if I read arm/kernel/entry-common.S
properly) strace sees the same _NR_name values for both ABIs.

MIPS also has two different 32-bit ABIs, as well as 64-bit, but on
MIPS the syscall numbers are distinct, and should be seen by ptrace.
(Again if I read mips/kernel/ correctly.)

PA-RISC also has two different ABIs, the Linux one and the HPUX one.
The syscall numbers are different but overlap.  I don't know if they
are distinct to ptrace, in which case using the HPUX entry point might
be used to subvert a ptracer unless the ABI number is exposed.

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

Powered by blists - more mailing lists