On Sat, Jul 14, 2012 at 9:15 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: > On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry <wad@xxxxxxxxxxxx> wrote: >> On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry <wad@xxxxxxxxxxxx> wrote: >>> On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: >>>> I think I'd prefer if changing to something other than whatever value is >>>> used to cancel the syscall resulted in a crash rather than just being >>>> ignored. >>> >>> I was trying to keep as much seccomp-ptrace behavior intact rather >>> than making it terminal in this special case. Is there a reason why >>> it'd make more sense to crash? >> >> Unless you meant something the tracer could catch? That may make >> sense, but they could also use singlestep or whatever else to get >> similar behavior. But maybe I'm missing the bigger picture! > > I think it would be nice to not introduce any special behavior that > things might rely on if we do this better in the future. Similarly, > for almost all purposes, a tracer could change gettimeofday to write, > but there would be a silent behavior change if gettimeofday were > entered via vsyscall. > > What's the standard way of skipping a syscall? sigreturn? (I don't > know off the top of my head what sigreturn does.) sys_ni_syscall? > I'd be all for making those continue to work but making anything that > can't be emulated correctly do something sufficiently unpleasant that > people won't do it. Is there a syscall that does nothing at all? Here's my suggestion for now: any attempt by the seccomp filter to do anything other than executing the syscall unchanged, skipping it entirely, or killing results in a trap or sigsys with the syscall number unchanged. In the RET_TRACE case, the SIGSYS restarts at the mov nr,%rax instruction. The tracer can deal with it accordingly (via checking the rip) -- if the tracer changes rax, it'll get changed right back by the emulated mov nr,%rax. If this results in an infinite loop, so be it. In the RET_TRAP case, do the same thing but via the special ptrace event instead of SIGSYS. This way, the special rip & ~0x0c00 == 0xffffffffff600000 handling becomes part of the ABI, but it looks like the mov instruction trapped, which it more or less did. If we want RET_TRAP to be able to skip the syscall, let it happen the normal way. This stuff probably barely matters. For example, ptrace currently doesn't work right when vsyscalls are being emulated. No one appears to care. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
