Re: [discuss] Re: [PATCH] linux-2.5.43_vsyscall_A0

[Elladan <elladan@eskimo.com>]

On Sun, Oct 20, 2002 at 11:27:30AM +0200, Andi Kleen wrote:
> On Sat, Oct 19, 2002 at 11:44:33PM -0700, Elladan wrote:
> > The problem with modifying the executable code/pages in the vsyscall
> > area is that it's going to be very tricky to implement, if I understand
> > this discussion properly.
> 
> Modifying the pages or variables in the pages from the kernel is no
> problem.  It just would affect all processes on the system
> 
> What's tricky is to give it per process state (which would 
> be needed to make a vsyscall/novsyscall flag process local) 

Not really any more tricky than turning it off globally with a flag.
It's just more expensive, because you have to propagate the flag into
vsyscall space on the context switch.  In the per-process case,
self-modifying code would be a less non-viable approach than it is
globally.

> > There may be any number of user processes idling in these pages on the
> > runqueue (or off it if say one received a SIGSTOP), and if you just go
> > change the instruction code on them, unless you're incredibly careful
> > and come up with some subtly safe machine code sequence, they're going
> > crash when you call this sysctl().
> 
> Nobody proposed to use self modifying code, it would just be a global
> variable located in the vsyscall area that is tested by the vsyscall
> code.

Well, self modifying code certainly looked like what Andrea was talking
about, to avoid the branch overhead on the userspace gettimeofday()
call.

I suspect that outside of a few database apps, it's pretty unlikely that
there will be any vsyscalls in your average time slice, so putting the
overhead into the vsyscall itself seems like a better idea than paying
the price during every context switch.


Of course, if you're really strictly worried about being able to fully
virtualize the vsyscalls, a global flag isn't really enough.  A user app
running under the virtual machine will still be able to manually access
the data on the vsyscall pages, and if it wants, jump into the middle of
a function or something like that.  So eg. a UML instance being used as
a sandbox would still expose the host time and such to its hostile
userspace, which could then execute subsets of vsyscall code at will.

It seems that to fix this with proper data-hiding, it would really need
to be possible to set the vsyscall pages as invalid for the UML process
(so it could manually emulate the vsyscall), which would then either
require expensive contex-switching costs to make it a per-process flag,
or we're back to global self-modifying-code fixups.

Better to just ignore that particular issue.

-J