From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Date: Wed, 10 Sep 2014 11:59:30 +0200 Message-ID: References: <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> <20140902132434.GA24202@deinos.phlegethon.org> <20140909201435.GB82414@deinos.phlegethon.org> <54101A48.8030401@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4546289671913335038==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XRegX-0000sm-DB for xen-devel@lists.xenproject.org; Wed, 10 Sep 2014 09:59:33 +0000 Received: by mail-qa0-f45.google.com with SMTP id s7so1607698qap.4 for ; Wed, 10 Sep 2014 02:59:30 -0700 (PDT) In-Reply-To: <54101A48.8030401@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: "Tian, Kevin" , Ian Campbell , Stefano Stabellini , Andrew Cooper , George Dunlap , Tim Deegan , Jan Beulich , "Dong, Eddie" , Jun Nakajima , xen-devel , Ian Jackson List-Id: xen-devel@lists.xenproject.org --===============4546289671913335038== Content-Type: multipart/alternative; boundary=001a11c2be64b1b8c60502b31bd7 --001a11c2be64b1b8c60502b31bd7 Content-Type: text/plain; charset=ISO-8859-1 > >> But ultimately, as Tim said, you're basically just *hoping* that it > >> won't take too long to happen to be at the hypervisor when the proper > >> condition happens. If the process in question isn't getting many > >> interrupts, or is spending the vast majority of its time in the > >> kernel, you may end up waiting an unbounded amount of time to be able > >> to "catch" it in user mode. It seems like it would be better to find > >> a reliable way to trap on the return into user mode, in which case you > >> wouldn't need to have a special "wait for this complicated event to > >> happen" call at all, would you? > > > > Yeah; I was thinking about page-protecting the process's stack as an > > approach to this. Breakpointing the return address might work too but > > would probably cause more false alarms -- you'd at least need to walk > > up past the libc/win32 wrappers to avoid trapping every thread. > > > > Ideally there'd be something vcpu-specific we could tinker with > > (e.g. arranging MSRs so that SYSRET will fault) once we see the right > > CR3 (assuming intercepting CR3 is cheap enough in this case). > > All valid suggestions, however they would seem to have a greater impact > on guest responsiveness. There would be quite a lot of CR3 loads and > SYSRETs. > Another approach which may be a bit less complicated then breakpointing the return address is to walk your target process' pagetables when it is scheduled and simply make all pages that don't have the supervisor bit set but are executable to NX in the EPT. That way the kernel code can happily finish and you get a mem-event of user-mode code execution right away without having any false alarms (with the added benefit of this being guest OS agnostic as well). Only downside is if you have multiple vCPUs, then you need to make sure the event was by the target vCPU and do some more housekeeping to step the non-target faulting vCPU over the trap. Tamas --001a11c2be64b1b8c60502b31bd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
>> But ultimately, as Tim said, you're basically just *hoping* th= at it
>> won't take too long to happen to be at the hypervisor when the= proper
>> condition happens.=A0 If the process in question isn't getting= many
>> interrupts, or is spending the vast majority of its time in the >> kernel, you may end up waiting an unbounded amount of time to be a= ble
>> to "catch" it in user mode.=A0 It seems like it would be= better to find
>> a reliable way to trap on the return into user mode, in which case= you
>> wouldn't need to have a special "wait for this complicate= d event to
>> happen" call at all, would you?
>
> Yeah; I was thinking about page-protecting the process's stack as = an
> approach to this.=A0 Breakpointing the return address might work too b= ut
> would probably cause more false alarms -- you'd at least need to w= alk
> up past the libc/win32 wrappers to avoid trapping every thread.
>
> Ideally there'd be something vcpu-specific we could tinker with > (e.g. arranging MSRs so that SYSRET will fault) once we see the right<= br> > CR3 (assuming intercepting CR3 is cheap enough in this case).

All valid suggestions, however they would seem to have a greater imp= act
on guest responsiveness. There would be quite a lot of CR3 loads and
SYSRETs.

Another approach which may be = a bit less complicated then breakpointing the return address is to walk you= r target process' pagetables when it is scheduled and simply make all p= ages that don't have the supervisor bit set but are executable to NX in= the EPT. That way the kernel code can happily finish and you get a mem-eve= nt of user-mode code execution right away without having any false alarms (= with the added benefit of this being guest OS agnostic as well). Only downs= ide is if you have multiple vCPUs, then you need to make sure the event was= by the target vCPU and do some more housekeeping to step the non-target fa= ulting vCPU over the trap.

Tamas

--001a11c2be64b1b8c60502b31bd7-- --===============4546289671913335038== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4546289671913335038==--