Re: [PATCH] linux-2.5.43_vsyscall_A0

[Elladan <elladan@eskimo.com>]

On Tue, Oct 22, 2002 at 10:12:08PM -0700, Elladan wrote:
> 
> Try 2:
> 
> Create a second mapping of the vsyscall page in some special location
> above the normal page.  Make a new sysctl, which globally invalidates
> the page that the standard mapping is on.  Basically, this disables
> vsyscalls for everyone when turned on.
> 
> Now, obviously this won't work without some trick.  What we do now is,
> we make the page fault handler path for vsyscalls (to be added anyway)
> work like so:
> 
> If the pc is within the allocated vsyscall page(s), then:
> 
> If the pc is on the entrypoint to a vsyscall function, check whether the
> process is being traced.  If so, turn this into a somewhat normal
> looking syscall so it can be virtualized (or do something else, if you
> want - have userspace jump somewhere, etc).
> 
> If not traced, or if the pc is not at the entrypoint, reset the pc to be
> on the second vsyscall copy, with the same offset, and return to
> userspace.
> 
> This lets us do a global vsyscall disable, but (I hope) fixes up the
> problem of userspace going to sleep inside a vsyscall.  The process
> wakes up, faults, and gets shunted off to identical code in another
> location, which should have the same behavior.
> 
> Downside: vgettimeofday takes a performance penalty for everyone in the
> special case where UML is running with full time virtualization, because
> of the page fault.  This is the very unusual case, so who cares?
> 
> Downside 2: Would this actually work?  It's a bit scary sounding...

One caveat to this, I suppose, is that the vsyscall itself would need to
be position-independant code (which might not be overhead, if done very
carefully), or else the code would have to be modified inside the
sysctl() at invalidation time.  Both of which make the implementation
ugly.

-J