lkml.org 
[lkml]   [2012]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]
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@nul.nu> 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


\
 
 \ /
  Last update: 2012-01-19 16:43    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog