Re: Pondering per-process vsyscall disablement

[Andy Lutomirski]

On Thu, May 22, 2014 at 7:44 PM, Marian Marinov <mm@xxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/23/2014 02:04 AM, Andy Lutomirski wrote:
>> It would be nice to have a way for new programs to declare that they don't need vsyscalls.  What's the right way to
>> do this?  An ELF header entry in the loader?  An ELF header entry in the program?  A new arch_prctl?
>>
>> As background, there's an old part of the x86_64 ABI that allows programs to do gettimeofday, clock_gettime, and
>> getcpu by calling to fixed addresses of the form 0xffffffffff600n00 where n indicates which of those three syscalls
>> is being invoked.  This is a security issue.
>>
>> Since Linux 3.1, vsyscalls are emulated using NX and page faults.  As a result, vsyscalls no longer offer any
>> performance advantage over normal syscalls; in fact, they're much slower.  As far as I know, nothing newer than
>> 2012 will attempt to use vsyscalls if a vdso is present.  (Sadly, a lot of things will still fall back to the
>> vsyscall page if there is no vdso, but that shouldn't matter, since there is always a vdso.)
>>
>> Despite the emulation, they could still be used as a weird form of ROP gadget that lives at a fixed address.  I'd
>> like to offer a way for new runtimes to indicate that they don't use vsyscalls so that the kernel can selectively
>> disable emulation and remove the fixed-address executable code issue.
>>
>>
> Wouldn't it be more useful if the check is against a bitmask added as extended attribute for that executable?
> This way the administrators and will have the flexibility to simply add the new attribute to the executable.

I don't think this should be something configured by the
administrator, unless the administrator is the builder of a kiosky
thing like Chromium OS.  In that case, the administrator can use
vsyscall=none.

I think this should be handled by either libc or the toolchain, hence
the suggestions of a syscall or an ELF header.

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