Messages in this thread |  | | Date | Thu, 19 Jan 2012 15:40:14 +0000 | | From | Jamie Lokier <> | | Subject | Re: 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
|  |