From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Date: Tue, 2 Sep 2014 15:24:34 +0200 Message-ID: <20140902132434.GA24202@deinos.phlegethon.org> References: <53FF36A1020000780002EAED@mail.emea.novell.com> <53FF1BD8.5010401@bitdefender.com> <53FF38A6020000780002EB2B@mail.emea.novell.com> <54002F43.4070802@bitdefender.com> <5400638A020000780002EFD6@mail.emea.novell.com> <540421E1.9020505@bitdefender.com> <540453C8020000780002F59C@mail.emea.novell.com> <54045E7C.50604@bitdefender.com> <54047D1D020000780002F73A@mail.emea.novell.com> <54058B4E.9060001@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XOo52-0005yJ-L2 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2014 13:25:04 +0000 Content-Disposition: inline In-Reply-To: <54058B4E.9060001@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Razvan Cojocaru Cc: kevin.tian@intel.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, jun.nakajima@intel.com, andrew.cooper3@citrix.com, eddie.dong@intel.com, Jan Beulich , xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org Hi, At 12:18 +0300 on 02 Sep (1409656686), Razvan Cojocaru wrote: > While we need to set the data per-domain and have whatever VCPU inject > the page fault - _but_only_if_ it's in usermode and its CR3 points to > something interesting. That's a strange and specific thing to ask the hypervisor to do for you. Given that you can already trap CR3 changes as mem-events can you trigger the fault injection in response to the contect switch? I guess that would probably catch it in kernel mode. :( It also seems like it will be hard to do reliably -- HVM guests don't trap on user<->kernel transitions so we're not guaranteed to be able to stop in the right place. I wonder if there's some trick you can play by tinkering with other memory permissions to trigger an event at the right time (e.g. find the process you want and walk its stack to find a user-space return address and then mark it read-only?) Tim.