Mailing List Archive

Intercepting memory operations of a guest
Hi all,

Sorry for any cross posting. I sent this to the xen-devel list and the
xen-se list as well.

I'm wanting to modify some xen source code for the purposes of some
research, exploration, and testing of some security concepts.

I have a few questions after looking through the source.

All of the below applies to 32-bit guests.

#1: Is there anyway possible to trap/insert some code at/hook into, any
modification of a PV guest's page table. Anything like a hypercall handler I
can plugin to, a function or series of functions that always gets called,
something I can provide a call back to, or anything else?

#2: For some research purposes, I plan on replicating portions of the page
table of a guest, only those pages of the guest's kernel. I hope to do this
by the supervisory bit being set; however, I welcome any suggestions of a
better approach to detecting when kernel pages are being modified?

In general, to explain any questions I haven't specifically asked above; I'm
looking for the appropriate place in xen to intercept any writes, reads, and
executes of a guest's memory.

Also, would such activities be easier or more difficult with hvm guests?
Since xen has to provide hvm guests an individual CR3, would such a place be
much easier to hook into because of any abstraction layers that already
exist for such things?

The only reason I picked pv guests was that the semantics of what is a
kernel page and what is not might not be as easy to determine in an hvm
guest, but perhaps this is not the case?

Thanks for any assistance.

Take care,
Sina


_______________________________________________
Xen-research mailing list
Xen-research@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-research
Re: Intercepting memory operations of a guest [ In reply to ]
On Sun, Dec 7, 2008 at 8:57 PM, Sina Bahram <sbahram@nc.rr.com> wrote:
> Hi all,
>
> Sorry for any cross posting. I sent this to the xen-devel list and the
> xen-se list as well.
>
> I'm wanting to modify some xen source code for the purposes of some
> research, exploration, and testing of some security concepts.
>
> I have a few questions after looking through the source.
>
> All of the below applies to 32-bit guests.
>
> #1: Is there anyway possible to trap/insert some code at/hook into, any
> modification of a PV guest's page table. Anything like a hypercall handler I
> can plugin to, a function or series of functions that always gets called,
> something I can provide a call back to, or anything else?
>
> #2: For some research purposes, I plan on replicating portions of the page
> table of a guest, only those pages of the guest's kernel. I hope to do this
> by the supervisory bit being set; however, I welcome any suggestions of a
> better approach to detecting when kernel pages are being modified?
>
> In general, to explain any questions I haven't specifically asked above; I'm
> looking for the appropriate place in xen to intercept any writes, reads, and
> executes of a guest's memory.
>
> Also, would such activities be easier or more difficult with hvm guests?
> Since xen has to provide hvm guests an individual CR3, would such a place be
> much easier to hook into because of any abstraction layers that already
> exist for such things?
>
> The only reason I picked pv guests was that the semantics of what is a
> kernel page and what is not might not be as easy to determine in an hvm
> guest, but perhaps this is not the case?
>

You may want to take a look at the Xen Introspection Project:
http://blog.xen.org/index.php/2008/10/27/new-xen-introspection-project-launching/
http://blog.xen.org/index.php/2008/11/12/xen-introspect-project-update/

Cheers,
Todd

--
Todd Deshane
http://todddeshane.net
http://runningxen.com

_______________________________________________
Xen-research mailing list
Xen-research@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-research
RE: Intercepting memory operations of a guest [ In reply to ]
Hi Todd,

I've subscribed to that list now, and I'll send my message there as well.

Thanks for the suggestion.

Take care,
Sina

-----Original Message-----
From: Todd Deshane [mailto:deshantm@gmail.com]
Sent: Monday, December 08, 2008 10:15 AM
To: Sina Bahram
Cc: xen-research@lists.xensource.com
Subject: Re: [Xen-research] Intercepting memory operations of a guest

On Sun, Dec 7, 2008 at 8:57 PM, Sina Bahram <sbahram@nc.rr.com> wrote:
> Hi all,
>
> Sorry for any cross posting. I sent this to the xen-devel list and the
> xen-se list as well.
>
> I'm wanting to modify some xen source code for the purposes of some
> research, exploration, and testing of some security concepts.
>
> I have a few questions after looking through the source.
>
> All of the below applies to 32-bit guests.
>
> #1: Is there anyway possible to trap/insert some code at/hook into, any
> modification of a PV guest's page table. Anything like a hypercall handler
I
> can plugin to, a function or series of functions that always gets called,
> something I can provide a call back to, or anything else?
>
> #2: For some research purposes, I plan on replicating portions of the page
> table of a guest, only those pages of the guest's kernel. I hope to do
this
> by the supervisory bit being set; however, I welcome any suggestions of a
> better approach to detecting when kernel pages are being modified?
>
> In general, to explain any questions I haven't specifically asked above;
I'm
> looking for the appropriate place in xen to intercept any writes, reads,
and
> executes of a guest's memory.
>
> Also, would such activities be easier or more difficult with hvm guests?
> Since xen has to provide hvm guests an individual CR3, would such a place
be
> much easier to hook into because of any abstraction layers that already
> exist for such things?
>
> The only reason I picked pv guests was that the semantics of what is a
> kernel page and what is not might not be as easy to determine in an hvm
> guest, but perhaps this is not the case?
>

You may want to take a look at the Xen Introspection Project:
http://blog.xen.org/index.php/2008/10/27/new-xen-introspection-project-launc
hing/
http://blog.xen.org/index.php/2008/11/12/xen-introspect-project-update/

Cheers,
Todd

--
Todd Deshane
http://todddeshane.net
http://runningxen.com


_______________________________________________
Xen-research mailing list
Xen-research@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-research