Re: [PATCH v4 10/10] x86-64: Add CONFIG_UNSAFE_VSYSCALLS tofeature-removal-schedule

[Ingo Molnar]

* Andrew Lutomirski <luto@xxxxxxx> wrote:

> > And it's still a bad idea. Especially since there's a much better 
> > alternative anyways for the "security problem" which has none of 
> > these drawbacks.
> 
> What's the alternative?

Well, Andi likes to draw out such answers and likes to keep any 
answer as minimally helpful as possible (to demonstrate his 
superiority), but my guess would be that he is thinking of the 
(trivial) solution that filters the caller RIP at the generic syscall 
entry point and checks RCX against the 'expected' SYSCALL instruction 
address, which is the (per task) vdso-address + constant-offset.

That method has a big disadvantage:

 - it slows down the syscall fastpath with two or three unnecessary 
   instructions.

It has two advantages:

 - it's the simplest method of all

 - it also *only* allows the vdso address to be used for system calls,
   so if an attacker manages to find an executable SYSCALL 
   instruction somewhere in the executable space of an application,
   that entry point will not be usable.

... so this method is not completely off the table.

If everyone agrees that the generic syscall overhead is acceptable we 
could try this too.

Thoughts?

Thanks,

	Ingo
--
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/