Re: [PATCH v4 0/6] Micro-optimize vclock_gettime

[Andrew Lutomirski <luto@mit.edu>]

On Mon, May 16, 2011 at 4:22 PM, Andi Kleen <andi@firstfloor.org> wrote:
> Andrew Lutomirski <luto@mit.edu> writes:
>
>> On Mon, May 16, 2011 at 12:49 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>>> And unless you or someone else changes the primitive state of the
>>>> kernel, framepointers are going to stay simply because removing them
>>>> breaks profiling backtraces when the hit is inside vread().
>>>
>>> This doesn't work anyways because the glibc stub code calling vgettimeofday
>>> normally doesn't set up a frame pointer frame.
>>>
>>> The only way to unwind there is dwarf2.
>>
>> For code in the vsyscall page, I think using CFI data is a lost cause.
>>  How is any user code supposed to find the CFI data?
>
> It only works for the vDSO. vsyscall is legacy.

Except that vread_tsc (i.e. the code in question) is in the vsyscall
page.  (That's on my list of less low-hanging fruit to attack if I
decide to go for another 3 ns or so for 2.6.41.)

>
>> For the vDSO, we could be nice to userspace and install the debugging
>> symbols somewhere sensible.  Currently we generate a buildid but we
>> don't install the symbols anywhere by default.
>
> Actually we include the dwarf2 tables and signal unwinding works
> (for the vDSO)

That particular comment was more about debugging than stack traces.
Things like perf annotate would like the full symbols.

>
>> Longer term, it would be nice to mark the vsyscall page NX.  That
>> involves a few things:
>
> Why NX? What would make sense is to call the VDSO from it.
> The problem is that the vDSO is randomized and there's no good memory
> location to store the pointer to it.
>
> The real reason for all this dance is to have some less non randomized
> code around. What I implemented back then was instead code to patch out
> the SYSCALL in there if not needed to lower the attack surface (not sure
> if that still works though, but that was the idea). For most cases
> (TSC/HPET read) it's not needed.

Nothing sensible calls the vsyscall page.  (I'm defining code that
statically links against current glibc as insensible.  But that could
be fixed.  I think it's mainly an artifact of some odd glibc
internals.)  So if we make the vsyscall page NX then we have no
non-randomized code at all.

How do we tell that a program really wants to call the vsyscall page
and isn't being exploited to call the vsyscall page?

There are excactly four entry-points into the vsyscall page that are
part of the ABI.  One of them is venosys (maybe it used to do
something) and the other three are archaic duplicates of vDSO
functions.  It seems less complicated to emulate them than to patch
them in.

--Andy