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

[Daniel Jacobowitz]

On Sat, Feb 07, 2004 at 03:19:55AM +0100, Andrea Arcangeli wrote:
> > The official kernel might have the vdso at a fixed address part no part
> > of the ABI requires this address and so anybody with some security
> > conscience can change the kernel to randomize the vdso address.  It's
> > not my or Ingo's fault that Linus doesn't like the exec-shield code
> > which would introduce the randomization.  The important aspect is that
> > we can add vdso randomization and nothing else needs changing.  The same
> > libc will run6 on a stock kernel and the one with the randomized vdso.
> > This is not the case on x86-64 where the absolute address for the
> > gettimeofday is used.
> 
> I don't know exactly what your "randomization exec-shield" code is doing
> either. the way I understand what you wrote is that you want to relocate
> the vsyscall trasparently without glibc knowledge, so in short you're
> saying that you don't care to randomize everything in the userspace
> executable address space, you only care to relocate the vgettimeofday
> bytecode, not the rest of the vsyscall pieces. So with your solution
> you'll still have "fixed" addresses in the address space that will allow
> an attacker to execute vgettimeofday, just like glibc can execute it
> without noticing the actual function was relocated. As far as glibc
> won't notice that vgettimeofday has been relocated by your
> "exec-shield", it means the attacker as well can execute it just fine.

You might want to stop and take a look at the way this works on i386
before you argue with Ulrich any more about it.

Specifically, the vsyscall DSO is constructed as a normal ELF image,
and its base address is passed to glibc as an AT_SYSINFO tag in the
application's auxv vector.  Glibc source code has absolutely no
knowledge of the base address, which in fact has changed at least three
times since it was created.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
-
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/