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

[Andrew Lutomirski]

On Mon, May 16, 2011 at 5:53 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Mon, 16 May 2011, Andi Kleen wrote:
>> Andrew Lutomirski <luto@xxxxxxx> writes:
>> > 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.
>
> For a damned good reason.
>
>> > 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.
>
> If you can address _all_ reasons why it was removed then we might
> revisit that issue, but that's going to be an interesting patch.

We're now completely offtopic for the RDTSC patches, but do you have
any moral objection to rigging the vsyscall page to generate a fault
and emulating it after a couple years of deprecation?  If not, I can
see if I can persuade Uli to take accept a glibc patch to stop calling
it in future static glibc versions.

The long-term cost to the kernel will be a special case (and, compare,
unlikely branch) in whichever fault trap gets used.  The best way
might be to use a page full of 0xCC so that an int3 fault (presumably
not a performance-critical path) is taken.

--Andy
--
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/