Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re:[RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]

[Jamie Lokier]

Indan Zupancic wrote:
> On Wed, January 18, 2012 22:13, Chris Evans wrote:
> > On Wed, Jan 18, 2012 at 4:12 AM, Indan Zupancic <indan@xxxxxx> wrote:
> >> On Wed, January 18, 2012 06:43, Chris Evans wrote:
> >>> 2) Tracee traps
> >>> 2b) Tracee could take a SIGKILL here
> >>> 3) Tracer looks at registers; bad syscall
> >>> 3b) Or tracee could take a SIGKILL here
> >>> 4) The only way to stop the bad syscall from executing is to rewrite
> >>> orig_eax (PTRACE_CONT + SIGKILL only kills the process after the
> >>> syscall has finished)
> >>
> >> Yes, we rewrite it to -1.
> >>
> >>> 5) Disaster: the tracee took a SIGKILL so any attempt to address it by
> >>> pid (such as PTRACE_SETREGS) fails.
> >>
> >> I assume that if a task can execute system calls and we get ptrace events
> >> for that, that we can do other ptrace operations too. Are you saying that
> >> the kernel has this ptrace gap between SIGKILL and task exit where ptrace
> >> doesn't work but the task continues executing system calls? That would be
> >> a huge bug, but it seems very unlikely too, as the task is stopped and
> >> shouldn't be able to disappear till it is continued by the tracer.
> >>
> >> I mean, really? That would be stupid.
> 
> Okay, I tested this scenario and you're right, we're screwed.

Ha!

Perhaps this could be fixed generically in
tracehook_report_syscall_entry(), for those architectures which bother
to call it and bother to disable the syscall if it says to.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/