Re: [RFC][PATCH] linux-2.6.2_vsyscall-gtod_B2.patch

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Feb 06, 2004 at 01:28:04AM -0800, Ulrich Drepper wrote:
> Andrea Arcangeli wrote:
> 
> > with regards to Ulrich's security related comments, this won't make any
> > difference compared to the fixed address version either, since the
> > vsyscall page is still at a fixed address in the fixmap area,
> 
> Gee, you don't want to understand it.
> 
> Even if the official kernel's handling of the vdso puts it at the same
> address all the time this does not mean this can be engraved in stone.

i386 in 2.6.2 has the very same security issues. Fixed address for all
binary kernel shipped for the sysenter or int 0x80 instructions.  go
complain who wrote the i386 code.

> It must be possible to move the page.  And I expect this will be the
> case in our kernels.

what are "yours" kernels? You mean mainline or what? I'm saying it's
perfectly fine to relocate the vsyscall page on demand with an
additional syscall but this will have an overhead, like relocating the
.text executable as well will have an overhead, and before you can care
about relocating the vsyscall address, you should relocate the .text of
the executable as Andi noted.

> It is completely unacceptable to use fixed addresses or require the libc
> to be recompiled for a new address.  At the highest security level the
> vdso address should vary from program run to program run which means
> there is no way to change the libc.

This is fine, the new syscall I'm advocating will simply relocate the
vsyscall page with a new pte and a tlb flush during every context
switch, write it for i386 now since 2.6.2 has those int 0x80 and syscall
instructions at fixed address too.