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? I wish we could just increment rip by 7 and set a flag to allow the vsyscall page instructions to be fully emulated until one of the ret instructions happens, but I don't know how to do that without monkeying with the entry assembly -- the do_page_fault path doesn't look enough like system_call to pull it off easily. In any case, can you change the docs to indicate that the special behavior only happens iff rip & ~0x0c00 == 0xffffffffff600000? That way a hypothetical future emulator could add better emulation (incrementing rip by 7, for example) and everything would still work. (There's no need to check the syscall number.) FWIW, this crap is why I'm sort of tempted to say that seccomp should just ignore vsyscalls entirely (except in mode 1). None of them actually do anything other than querying things that can be read out of the vsyscall page (for the most part) without any kernel entry. (Making *that* part of the ABI would be bad, though.) Better ideas are welcome. --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
