From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cutter 409 Subject: Re: (no subject) Date: Mon, 22 Apr 2013 17:56:04 -0400 Message-ID: References: <20121115120836.GA75988@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1043097376038968894==" Return-path: In-Reply-To: <20121115120836.GA75988@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Aravindh Puthiyaparambil , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============1043097376038968894== Content-Type: multipart/alternative; boundary=14dae947303ba7824a04dafa2295 --14dae947303ba7824a04dafa2295 Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm finally to a point where I can start looking at this more closely. I'm trying to wrap my head around the shadow code to figure out the right course of action. I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want things to work via p2m somehow. I think I understand this part. * HVMOP_set_mem_access is used to change the p2m_access_t for the target page(s). This should already be implemented I think? * During propagation, I'll check the p2m map to see if I should mask off any permission bits. * On a shadow paging fault, I'll check if the fault was caused by p2m permissions, somehow integrating that with the code for read-only guest page tables safely. Questions: * Just for background, am I correct in my understanding that the log_dirty code is used to track which gfns have been written to by the guest, in order to speed up migration? * Are multiple shadow tables maintained per domain? Is there one per VCPU? One shadow table per guest page table? Is it blown away every time the guest changes CR3? I'm having some trouble tracking this down. * How should I clear/update existing shadow entries after changing the p2m_access_t? Can I clear the shadow tables somehow and force everything to be repopulated? Is that insane? Thanks! On Thu, Nov 15, 2012 at 7:08 AM, Tim Deegan wrote: > Bcc: Tim Deegan > Subject: Re: [Xen-devel] Guest memory access hooking > Reply-To: > In-Reply-To: < > CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com> > > Hi, > > At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote: > > I'm trying to do some research with malware, and I'm trying to get > > notifications on arbitrary guest page accesses (similar to what Ether > > does.) I've noticed the mem-event API and it seems like it might be close > > to what I need, but I can't find much documentation about how it works or > > how to use it. > > Yes, the mem-event api, and in particular the HVMOP_set_mem_access > hypercall, looks like what you want. As you say, there isn't much > documentation for it, except the xen-access.c client and the mailing > list archive. > > CC'ing Aravindh, who has worked on this code most recently and might be > able to help with specific questions. > > > I know that that mem-event API works only with EPT, but is the code to > > change permissions modifying the guest page tables, or does it work via > > EPT? (Can the guest detect it?) > > It works by EPT. The guest can't detect it by looking at its pagetables > or page fault patterns, though it might be able to detect it by looking > at timings. > > > I'm also interested monitoring arbitrary page access via the shadow page > > tables. I've been reading through the code, but if anyone has any insight > > or some kind of push in the right direction, I'd really appreciate it. > > Your best bet is to modify _sh_propagate. Look at how it handles > shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the > shadow PTE is made read-only until the guest is actually doing a write, > then mark_dirty can be called. You should be able to do the same thing > for other kinds of access. > > Cheers, > > Tim. > --14dae947303ba7824a04dafa2295 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I'm finally to a point= where I can start looking at this more closely. I'm trying to wrap my = head around the shadow code to figure out the right course of action.
I'd want HVMOP_set_mem_access to work with both shadow and EPT, s= o I'd want things to work via p2m somehow. I think I understand this pa= rt.

* HVMOP_set_mem_access is used to change = the p2m_access_t for the target page(s). This should already be implemented= I think?
* During propagation, I'll check the p2m map to see if I sho= uld mask off any permission bits.
* On a shadow paging fault,= I'll check if the fault was caused by p2m permissions, somehow integra= ting that with the code for read-only guest page tables safely.

Questions:

* Just for background, am I cor= rect in my understanding that the log_dirty code is used to=20 track which gfns have been written to by the guest, in order to=20 speed up migration?
* Are multiple shadow tables maintained per d= omain? Is there one per VCPU? One shadow table per guest page table? Is it = blown away every time the guest changes CR3? I'm having some trouble tr= acking this down.
* How should I clear/update existing shadow entries after changing the p2m_= access_t? Can I clear the shadow tables somehow and force everything to be = repopulated? Is that insane?

Thanks!



On Thu,= Nov 15, 2012 at 7:08 AM, Tim Deegan <tim@xen.org> wrote:
Bcc: Tim Deegan <tjd-xen@phleg= ethon.org>
Subject: Re: [Xen-devel] Guest memory access hooking
Reply-To:
In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8= k+MuqHrQ@mail.gmail.com>

Hi,

At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> I'm trying to do some research with malware, and I'm trying to= get
> notifications on arbitrary guest page accesses (similar to what Ether<= br> > does.) I've noticed the mem-event API and it seems like it might b= e close
> to what I need, but I can't find much documentation about how it w= orks or
> how to use it.

Yes, the mem-event api, and in particular the HVMOP_set_mem_access
hypercall, looks like what you want. =A0As you say, there isn't much documentation for it, except the xen-access.c client and the mailing
list archive.

CC'ing Aravindh, who has worked on this code most recently and might be=
able to help with specific questions.

> I know that that mem-event API works only with EPT, but is the code to=
> change permissions modifying the guest page tables, or does it work vi= a
> EPT? (Can the guest detect it?)

It works by EPT. =A0The guest can't detect it by looking at its pagetab= les
or page fault patterns, though it might be able to detect it by looking
at timings.

> I'm also interested monitoring arbitrary page access via the shado= w page
> tables. I've been reading through the code, but if anyone has any = insight
> or some kind of push in the right direction, I'd really appreciate= it.

Your best bet is to modify _sh_propagate. =A0Look at how it handles
shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the shadow PTE is made read-only until the guest is actually doing a write,
then mark_dirty can be called. =A0You should be able to do the same thing for other kinds of access.

Cheers,

Tim.

--14dae947303ba7824a04dafa2295-- --===============1043097376038968894== 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 --===============1043097376038968894==--