Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 23 Oct 2002 01:37:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 23 Oct 2002 01:37:52 -0400 Received: from mail.eskimo.com ([204.122.16.4]:11532 "EHLO mail.eskimo.com") by vger.kernel.org with ESMTP id ; Wed, 23 Oct 2002 01:37:51 -0400 Date: Tue, 22 Oct 2002 22:43:44 -0700 To: Andrea Arcangeli Cc: Elladan , Jeff Dike , Andi Kleen , john stultz , lkml , george anzinger , Stephen Hemminger , Bill Davidsen Subject: Re: [PATCH] linux-2.5.43_vsyscall_A0 Message-ID: <20021023054344.GA2002@eskimo.com> References: <20021020023321.GS23930@dualathlon.random> <200210220507.AAA06089@ccure.karaya.com> <20021022052717.GO19337@dualathlon.random> <20021022072438.GA4853@eskimo.com> <20021022074006.GS19337@dualathlon.random> <20021023051208.GA1350@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021023051208.GA1350@eskimo.com> User-Agent: Mutt/1.4i From: Elladan Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2069 Lines: 47 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 - 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/