linux-kernel - Re: Pondering per-process vsyscall disablement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 May 2014 09:40:44 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Marian Marinov <mm@...com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Linux API <linux-api@...r.kernel.org>
Subject: Re: Pondering per-process vsyscall disablement

On Thu, May 22, 2014 at 7:44 PM, Marian Marinov <mm@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/