[lkml]   [2011]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v4 0/6] Micro-optimize vclock_gettime
    On Tue, May 17, 2011 at 4:00 AM, Ingo Molnar <> wrote:
    > * Thomas Gleixner <> wrote:
    >> > 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 ?

    I dunno. I'll measure it.

    > Well, how does that differ from having the real syscall instruction there? How
    > are we going to filter real (old-)glibc calls from exploits?

    Because there are only four vsyscalls: vgettimeofday, vtime, vgetcpu,
    and venosys. None of them have side-effects, so they only allow an
    attacker to write something to user memory somewhere. The
    implementation of vgettimeofday needs a syscall instruction internally
    for its fallback, which means that an attack could jump there instead
    of to the start of the vsyscall implementation.

    > If it can be filtered in a meaningful way then we should just do that and
    > perhaps offer a (default enabled) .config COMPAT_VDSO_EMU=y switch to turn the
    > emulation off.
    > That way we keep the ABI and also have a way out for users who *really* need
    > this to work in a performant way.

    Yeah, that probably makes more sense. It'll make for an uglier
    diffstat, though -- there's a lot of ugly duplicate code around to
    make vgettimeofday and vgetcpu work.


    > Thanks,
    >        Ingo
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-05-17 13:13    [W:0.024 / U:6.808 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site