Re: [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule
From: pageexec
Date: Mon Jun 06 2011 - 17:54:39 EST
On 7 Jun 2011 at 5:40, Linus Torvalds wrote:
> On Tue, Jun 7, 2011 at 3:46 AM, <pageexec@xxxxxxxxxxx> wrote:
> >
> >> I'm happy with perhaps moving away from the fixed-address vdso,
> >
> > it's not about the vdso that has been mmap'ed and randomized for quite some
> > time now. it's about the amd64 specific vsyscall page.
>
> Duh. What do you think that thing is? It's a special fixed-address
> vdso.
that we call the vsyscall page and not some random vdso thing, they're quite
different, that's why there's this whole patch series, duh.
> What I complain about in the patch series was (specifically) that I
> think the naming sucks and (non-specifically) that the whole series is
> annoying.
>
> The config name is misleading and pointlessly scary - the whole thing
> is not in itself "unsafe", so calling it that is just wrong.
if it's safe to have the vsyscall page at a fixed address, then you surely
wouldn't object to have its replacement at a fixed address as well, would
you? yes/no? (if it's a 'yes' then you'd better have some non-security
arguments too ;)
> We *definitely* don't want to name it in a way that makes some random
> person just turn it off because it's scary, since the random person
> *shouldn't* turn it off today. Comprende?
actually you confused yourself and got it backwards. we want everyone sane
who cares an iota about security to turn off the legacy/fixed address vsyscall
as soon as possible else it's a pointless exercise. capito?
> If we can replace the vsyscall page with a page fault or int3 or
> whatever, and it's only used for the 'time()' system call, just do it.
i agree fully, there's no real reason for a config option imho, i never
had one in PaX and noone ever complained let alone noticed it (except
perhaps for failed exploit attempts but that's by design).
--
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/