[lkml]   [2012]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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,
> > >
> >
> > 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

 \ /
  Last update: 2012-02-10 03:55    [W:0.237 / U:4.060 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site