lkml.org 
[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 0/6] Micro-optimize vclock_gettime
On Mon, 16 May 2011, Andrew Lutomirski wrote:
> On Mon, May 16, 2011 at 5:53 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 16 May 2011, Andi Kleen wrote:
> >> Andrew Lutomirski <luto@mit.edu> 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

Moral objections are pretty irrelevant, but I have no technical
objections either. :)

> see if I can persuade Uli to take accept a glibc patch to stop calling
> it in future static glibc versions.

How wide spread is this in reality on 64bit systems ?

IOW, what's the damage if we take a trap and emulate it in the most
painful way we can come up with ?

Thanks,

tglx
\
 
 \ /
  Last update: 2011-05-17 00:43    [W:0.062 / U:53.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site