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

[Andrea Arcangeli]

On Wed, Feb 04, 2004 at 03:27:16AM +0100, Andi Kleen wrote:
> Jamie Lokier <jamie@xxxxxxxxxxxxx> writes:
> 
> > Andrea Arcangeli wrote:
> > > vsyscalls will never execute anything like execve. They can at most
> > > modify userspace memory a fixed address, so if the userspace isn't
> > > fixed, then nothing can be done with a vsyscall.
> > 
> > Are we talking about the same x86_64?
> > 
> > I see this in arch/x86_64/vsyscall.S:
> > 
> > __kernel_vsyscall:
> > .LSTART_vsyscall:
> > 	push	%ebp
> > .Lpush_ebp:
> > 	movl	%ecx, %ebp
> > 	syscall
> > 
> > Is that page not mapped into userspace?
> 
> It is. It is needed for the vsyscall fallback for UML (UML cannot
> support fixed address vsyscalls) and when we have to disable user
> space vgettimeofday for other reasons (e.g. to use alternative time
> sources that cannot be mapped to user space or doing time workarounds
> that require real locks)

the fallback in gettimeofday which may be needed in some system would
require a syscall instruction at fixed address too indeed (however in
most systems that is not necessary so the uml fallback seems to be the
one inserting the syscall instruction in common hardware).

> But any security advantages of not having it are at best illusionary.
> If you don't believe me just grep any random executable for 
> 0xf 0x05 (= syscall) or 0xcd 0x80 (= int $0x80). Even if it wasn't 
> in the vsyscall page you just have to find these two bytes somewhere
> (doesn't have to be an own instruction, they occur commonly as part
> of other instructions or data) and jump to them. Executables are
> at fixed addresses.

agreed.

And if they really want to relocate the vsyscall page, it's possible to
implement with a new syscall without having to slowdown or change the
API. We simply need to change the pte during context switch, but it will
force some invlpg at every context switch. I agree it doesn't worth as
far as the executable is the same on all systems.
-
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/