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

[Ingo Molnar]

* Andrew Lutomirski <luto@xxxxxxx> wrote:

> [Sorry, possible resend.]
> 
> On 5/31/11, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> >> [...] 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.
> >
> > Note that this solution would allow the vsyscall page to be
> > 'filtered' to the 3 allowed system calls rather efficiently, via a
> > second level check.
> >
> > This second check does not affect the fastpath, and it could be put
> > behind a CONFIG_COMPAT_VSYSCALL deprecation define once glibc does
> > not put vsyscall references anywhere - but we could even keep it
> > around forever, as this way it's defanged permanently.
> >
> 
> Are you thinking about the 32-bit vDSO? I think that 64-bit code puts
> syscalls instructions all over the place.

Yeah, it does in a few dozen places so RCX filtering would only work 
if we 'knew' about glibc's syscall range (it's available from the 
vma) and restricted syscalls to that boundary.

... which makes this solution rather fragile so i think we can 
disregard it.

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/