Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch

[Andrea Arcangeli]

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 libsyscall.so 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
think).

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/