linux-kernel - Re: [GIT pull] x86 vdso updates

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]

Message-ID: <BANLkTinOQ_C_-Bix4FTQxHqP3aavmTRrzg@mail.gmail.com>
Date:	Fri, 27 May 2011 07:36:12 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT pull] x86 vdso updates

On Fri, May 27, 2011 at 2:12 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Andy Lutomirski <luto@....edu> wrote:
>
>> On 05/26/2011 02:50 PM, Thomas Gleixner wrote:
>> >       x86-64: Add time to vDSO
>>
>> And here's the glibc bug:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12813
>>
>> Let the deprecation of the vsyscall page begin :)
>
> Yeah :-)
>
> On a related note, now that these bits are upstream, what are your
> rough plans for doing the int81 vsyscall emulation patch?
>
> The int81 patch would actually be (much!) more important to the
> average Linux user than getting rid of the vsyscall from static
> binaries: the vsyscall is the last predictable executable address in
> PIE daemons with a dangerous SYSENTER instruction in it ...
>
> I'd actually consider accelerating it into v2.6.40.

Working on it slowly.  In principle I'm writing my thesis right now on
things that have very little to do with software :)

My rough plans for the near-term stuff are:

1. Move vvars out of the vsyscall page.  Otherwise we have at least
one predictable syscall instruction every 1<<16 seconds because the
time is executable.  It's prettier that way, too.

2. Remove the vsyscall64 sysctl.  That will reduce the number of
vsyscalls that require the kernel's help to one.  (This is a bit
unfortunate for UML users, but I'm not sure what to do about that.
UML vgetcpu is already terminally broken.)

3. Add int 0xcc and use it from vgettimeofday.  It will SIGSEGV if
called from a user address (so it has no risk of ever becoming ABI)
and it will do gettimeofday if called from the right address.  (I like
0xcc better than 0x81 because then I don't have to wonder whether any
syscall-like instructions start with 0x81.)  I'm not convinced that
the existing syscall entries are usable, because syscall itself has a
different calling convention and int 0x80 is a compat syscall.

I might get this done in something resembling time for 2.6.40, but no
guarantees.

For later, the whole vsyscall page could become 0xcd <0xcc * 1023>,
repeated four times.

To save me a bunch of spec reading and code dissection, can you
explain the difference between zeroentry and paranoidzeroentry?

>
> Thanks,
>
>        Ingo
>
--
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/