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: <20120210025114.GA8390@jl-vm1.vm.bytemark.co.uk>
Date:	Fri, 10 Feb 2012 02:51:14 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Denys Vlasenko <vda.linux@...glemail.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!?

Oleg Nesterov wrote:
> On 01/26, Denys Vlasenko wrote:
> >
> > On Wednesday 25 January 2012 20:36, Oleg Nesterov wrote:
> > >
> > > 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;
> 
> Confused... Sure, we need the single option, or we could even report
> this unconditionally if PT_SEIZED.
> 
> I meant the different PTRACE_EVENT_* codes only.
> 
> > (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.
> 
> Well, if we add _ENTRY then it looks more consistent to report _EXIT
> as well even if it is not that useful.
> 
> Doesn't matter. Nobody seem to like this, and afaics Linus has the
> good arguments against the arch-independent "consolidation".

Regarding distinction between ENTRY/EXIT:

  I agree only a buggy kernel should get out of sync, but are we sure
  the kernel is never buggy, and wouldn't this be nice protection, and
  an excuse for strace to drop the heuristics it currently does for
  this condition?

  The behaviour from fork() appears to have changed.  (This is from
  reading kernel code, I'm too lazy to try out old kernels.)  If I
  read correctly, before 2.5.35, Linux returned an EXIT event first to
  a child process if CLONE_PTRACE was used, and then it didn't, and
  then from 2.5.46 the tracer's use of PTRACE_EVENT_* determines if it
  does or not.

  So it's not surprising strace has heuristics... shame they're buggy
  (sigreturn can look like anything).

  Anyway, PTRACE_EVENT_* for syscall entry/exit just look prettier!

Regarding ABI indication:

  At least with new syscalls, a tracer that doesn't know about them
  will see they're unrecognised; whereas a different ABI sometimes
  looks like an innocent syscall so can trick the tracer.

  However the argument for putting this in register state that goes
  into core dumps and checkpoint/restart state instead is pretty good.

  I don't have a strong opinion.  It's unfortunate that the current
  method not only makes it easy to subvert a ptracer, it makes
  ptracing slow and racy on archs where it has to read the syscall
  instruction.  (Weirdly that includes ARM, despite ARM using a
  register these days and having a ptrace option to set, but not read,
  the syscall number).

  That really is an argument for making sure all archs have the
  syscall number and, if necessary, the type of syscall entry point,
  somewhere in the register set.

All the best,
-- 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/