[lkml]   [2004]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch
    On Tue, Feb 03, 2004 at 08:52:24AM +0000, Jamie Lokier wrote:
    > Ulrich Drepper wrote:
    > > You got to be kidding. Some object fixed in the address space which can
    > > perform system calls. Nothing is more welcome to somebody trying to
    > > exploit some bugs.
    > Two approaches to randomising the vdso address:
    > 1. Selecting a random address at boot time. All tasks have the same
    > vdso for that run of the kernel. Advantages: no MSR write at
    > each context switch; could patch at boot time with
    > address if we were fanatical about optimisation (i.e. other
    > libcs, not Glibc :) Disadvantages: the attacker may eventually
    > learn the address.
    > 2. Select a random address for every new task. Advantages: harder
    > to guess from studying a machine for a long time. Disadvantages:
    > slower context switches; the gain from randomising each task is
    > nothing if all the tasks are very long lived anyway.

    could you please explain what's the point of this randomising thing what
    this attacker is trying to do?

    nothing can be randomized, as far as the vsyscall can be executed it
    means its address in the address space is known and not random. If the
    address is random you can't execute it. The whole vsyscall space is
    readonly, the attacker can do nothing on it, no way to touch it with
    put_user either.

    on x86-64 whatever is executable is readable too (readable non
    executable is possible but that's another issue)

    whatever the API you'll always be able to find the vsyscall address or
    it means you can't execute it in the first place.

    so in short, either we have vsyscalls non-randomized, or we don't have
    them at all, period.

    especially having a fixed address per-kernel makes no sense at all since
    it's trivial to find out by all other tasks anyways.

    the current API was presented around two years ago at UKUUG, and it was
    developed in the open in the x86-64 mailing list (archives should be
    online), so if there's really a fundamental problem it would been much
    better if you would send your complains to those lists at that time,
    instead of coming out of the blue years later when the code runs in
    production just fine for years (and it's in glibc for a long time too I

    Still I'm struggling to understand what's your point about
    randomization, your request makes no sense at all to me and I cannot
    imagine any remote security issue related to the current API of the
    vsyscalls, furthmore I cannot remotely imagine any difference in terms
    of security by using a vsyscall table, the only difference to the end
    user would be that its userspace would be running slower, while right
    now it's running as fast as the hardware can.

    I would appreciate a more detailed explanation rather than "address must
    randomized and the api must be changed".
    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: 2005-03-22 14:00    [W:0.022 / U:2.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site