Messages in this thread | | | Subject | Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch | From | Andi Kleen <> | Date | 04 Feb 2004 03:27:16 +0100 |
| |
Jamie Lokier <jamie@shareable.org> 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)
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.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |