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

[Andi Kleen]

Andrew Lutomirski <luto@xxxxxxx> writes:

> On Mon, May 16, 2011 at 12:49 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> 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.

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

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

Checking: someone removed the code meanwhile.

> And we won't have a
> syscall instruction sitting at a predictable address.

The easy way to fix this is to just re-add the patching.

-Andi
-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only
--
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/