Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

[Andrew Lutomirski]

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