Pondering per-process vsyscall disablement

Pondering per-process vsyscall disablement

[Andy Lutomirski]

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.


--Andy

Re: Pondering per-process vsyscall disablement

[Marian Marinov]

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

Marian

> --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html Please read the FAQ at
> http://www.tux.org/lkml/
> 


- -- 
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hackman@jabber.org
ICQ: 7556201
Mobile: +359 886 660 270
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlN+tg4ACgkQ4mt9JeIbjJRGkgCgjnD2s+J9kIr5oEDeL3VKHNvX
X4cAn17zC0aPKyTCVekmqZRlVukqLWyC
=vrfk
-----END PGP SIGNATURE-----

Re: Pondering per-process vsyscall disablement

[Andy Lutomirski]

On Thu, May 22, 2014 at 7:44 PM, Marian Marinov <mm@1h.com> 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

Re: Pondering per-process vsyscall disablement

[H. Peter Anvin]

On 05/23/2014 09:40 AM, Andy Lutomirski wrote:
> 
> 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.
> 

We could mimic the NX stack stuff, but it would have a lot of false
negatives, simply because very few things would actually poke at the
vsyscall page.

The NX stuff uses a dummy program header in the ELF image.

On the other hand, you could make the argument that anything compiled
with a new toolchain simply should not use the vsyscall page, and just
unconditionally set the opt-out bit (header) in question.

It might be better to have some kind of flags field (which a number of
architectures use) than keep using dummy program headers, though.

	-hpa

Re: Pondering per-process vsyscall disablement

[Andy Lutomirski]

On Wed, May 28, 2014 at 2:45 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/23/2014 09:40 AM, Andy Lutomirski wrote:
>>
>> 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.
>>
>
> We could mimic the NX stack stuff, but it would have a lot of false
> negatives, simply because very few things would actually poke at the
> vsyscall page.
>
> The NX stuff uses a dummy program header in the ELF image.
>
> On the other hand, you could make the argument that anything compiled
> with a new toolchain simply should not use the vsyscall page, and just
> unconditionally set the opt-out bit (header) in question.
>
> It might be better to have some kind of flags field (which a number of
> architectures use) than keep using dummy program headers, though.

Do the flags go in the ELF loader or in the executable we're running?
Or both (and, if both, do we and them or or them)?

I think the interpreter makes a little more sense in general: for the
most part, use of vsyscalls is a property of the runtime environment,
not of the program being run.  But maybe this is naive.

--Andy

Re: Pondering per-process vsyscall disablement

[H. Peter Anvin]

On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
> 
> Do the flags go in the ELF loader or in the executable we're running?
> Or both (and, if both, do we and them or or them)?
> 
> I think the interpreter makes a little more sense in general: for the
> most part, use of vsyscalls is a property of the runtime environment,
> not of the program being run.  But maybe this is naive.
> 

They go into each object which becomes part of the running program, i.e.
executable, dynamic libraries, and dynamic linker.

	-hpa

Re: Pondering per-process vsyscall disablement

[Andy Lutomirski]

On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
>>
>> Do the flags go in the ELF loader or in the executable we're running?
>> Or both (and, if both, do we and them or or them)?
>>
>> I think the interpreter makes a little more sense in general: for the
>> most part, use of vsyscalls is a property of the runtime environment,
>> not of the program being run.  But maybe this is naive.
>>
>
> They go into each object which becomes part of the running program, i.e.
> executable, dynamic libraries, and dynamic linker.

Well, sure, but the kernel is not about to start reading ELF headers
in dynamic libraries.  So we need to make a decision based on the
interpreter and the executable.  The conservative approach is to
require both to have the flag set *and* to offer a prctl to twiddle
the flags.  Then userspace loaders can do whatever they want, and
distros get to rebuild the world :)

--Andy

Re: Pondering per-process vsyscall disablement

[H. Peter Anvin]

On 05/30/2014 01:11 PM, Andy Lutomirski wrote:
> On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
>>>
>>> Do the flags go in the ELF loader or in the executable we're running?
>>> Or both (and, if both, do we and them or or them)?
>>>
>>> I think the interpreter makes a little more sense in general: for the
>>> most part, use of vsyscalls is a property of the runtime environment,
>>> not of the program being run.  But maybe this is naive.
>>>
>>
>> They go into each object which becomes part of the running program, i.e.
>> executable, dynamic libraries, and dynamic linker.
> 
> Well, sure, but the kernel is not about to start reading ELF headers
> in dynamic libraries.  So we need to make a decision based on the
> interpreter and the executable.  The conservative approach is to
> require both to have the flag set *and* to offer a prctl to twiddle
> the flags.  Then userspace loaders can do whatever they want, and
> distros get to rebuild the world :)
> 

Yes, something like that.

	-hpa

Re: Pondering per-process vsyscall disablement

[Andy Lutomirski]

On Fri, May 30, 2014 at 1:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/30/2014 01:11 PM, Andy Lutomirski wrote:
>> On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
>>>>
>>>> Do the flags go in the ELF loader or in the executable we're running?
>>>> Or both (and, if both, do we and them or or them)?
>>>>
>>>> I think the interpreter makes a little more sense in general: for the
>>>> most part, use of vsyscalls is a property of the runtime environment,
>>>> not of the program being run.  But maybe this is naive.
>>>>
>>>
>>> They go into each object which becomes part of the running program, i.e.
>>> executable, dynamic libraries, and dynamic linker.
>>
>> Well, sure, but the kernel is not about to start reading ELF headers
>> in dynamic libraries.  So we need to make a decision based on the
>> interpreter and the executable.  The conservative approach is to
>> require both to have the flag set *and* to offer a prctl to twiddle
>> the flags.  Then userspace loaders can do whatever they want, and
>> distros get to rebuild the world :)
>>
>
> Yes, something like that.

I'll hack something up once the merge window closes.  Or maybe sooner
if you commit my vsyscall patches from a few days ago.  Otherwise I'm
just going to confuse my git tree too much :)

--Andy

>
>         -hpa
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Andy Lutomirski
AMA Capital Management, LLC