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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
