Messages in this thread | | | From | Arne Georg Gleditsch <> | Subject | Re: arch/x86/kernel/vsyscall_64.c: overeager NOP of syscalls | Date | Fri, 22 Feb 2008 11:38:03 +0100 |
| |
Andi Kleen <ak@muc.de> writes: > On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote: >> Hi, >> >> I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP >> out the actual system call instructions of the vsyscall page when >> vsyscall64 is enabled. This seems to interact badly with the fallback >> code in do_vgettimeofday which tries to call gettimeofday if the >> configured clock source does not support vread. (In effect, >> gettimeofday() becomes a nop and time() always returns 0. Not very >> useful.) >> >> Is there a good reason to keep this? Aren't the instructions in >> question avoided (or invoked) according to the vsyscall64 flag by the >> surrounding logic anyway? > > Yes they are. But a system call sequence at a known fixed address > is potentially useful to exploits. That is why it is nop'ed out when > it is not needed.
Reasonable enough, as long as it can be determined to be not needed. Still, isn't the __vsyscall_gtod_data structure part of the same page? Wouldn't that give you access to any 2-byte opcode you want every 64k seconds? You'd need to time your attack, of course, but that could be done prior to actually launching the exploit...
-- Arne.
| |