-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Mads Bergdal
Sent: 21 September 2006 12:46
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: How to intercept interrupts from
guest domains
Keir Fraser wrote:
On 19/9/06 10:52, "Mads Bergdal" <mbergdal@xxxxxxxxx> wrote:
I am writing my master thesis on virtualization with
Xen. I am trying to
intercept the hypercalls coming from the guest domains. More
specific I am trying to determine where in memory a
guest domain is
writing. Does anyone have a hint on where in the code I
should try to do
this?
If you want to know where a guest is writing you need to
do more than
intercept hypercalls. You want to intercept memory
accesses to, which would
liekly mean you need to run on shadow pagetables and
manipulate access
permissions to trap on first access to a page.
-- Keir
Yes, that sounds reasonable. Do you know where in the code
this could be
achieved?
What's the intended purpose? You could perhaps look at the
log-dirty shadow
mode. This is used to track which pages have been modified
by the guest -- a
page which the guest maps writeable is not made writable in
the shadow page
tables until the time of the first write access (when that
page is added to
a 'dirty log' for further processing).
Be warned that modifying the shadow code is rather more
difficult than a
project that would simply involve adding a hook point to
every hypercall!
-- Keir
Thanks for the hints. I really appreciate it.
My main purpose of this is to try to monitor when a
guestdomain tries to
write to a specific address in it's memory. (An address that
it should
not write to) And then get the Hypervisor to notify my userspace
"surveillance" program about this.
I have spent quite some time now reading the code. I must
admit I am a
bit lost. I am not sure where in the code I should be looking to get
started.
From what you write above I take it that you think the
easiest approach
is to hook into the hypercalls? I that case which
hypercalls and where?
If not, where should I look to learn he internals of the shadow mode?
To catch a kernel writing to a specific address, you can't rely on
hypercalls - there is no hypercall to indicate that a particular address
(or any address) has been written to.
When the kernel writes to memory, the processor will read the page-table
entry according to CR3 and the relevant page-table entries after that
(depending on whether it's 32-bit, 32-bit+PAE or 64-bit and whether the
pages are "large" 2MB/4MB or "small" 4KB). If the page indicated by the
page-table is writable, then the processor will do nothing other than
write the requested data to the memory. If the page indicated by the
page-table is not writable, then the a page-fault is issued. In the case
of Xen, this is trapped by Xen directly, and handled in the
page-fault-handling routine. Depending on what the reason for page-fault
is, Xen either changes the page to writable, or issues the page-fault
back to the kernel (if Xen didn't think this page should be writable).
Xen uses non-writable pages to keep track of various things, so it's
perfectly "normal" for Xen to take a page-fault for write to a
non-writable page, and Xen "knows" whether a page SHOULD be written to
or not. A typical case is the shadow page-table handling itself.
Page-tables in the guest are write-protected, Xen takes the page-fault
and figures out what the new value for the page-table-entry should be
(remember that the Kernel doesn't actually know that memory mnay not be
organized like the kernel expects) and the ACTUAL page-table (shadow
version) used by the processor is updated accordingly, as well as
writing the new value to the kernel's "visible" page-table [but this
page-table is never used by the processor to address memory].
To make a memory address "trap" in the hypervisor, you would therefor
have to make sure the page that contains that address is always
write-protected, and when the page gets a hit, compare with your
"magical" value, and if so, indicate it back to your "supervisor"
application. Depending on the granularity, you could potentially just
write-protect the page and never have to worry about
write-enable/disable again.
[This gets even more tricky on SMP systems, I hope you're only planning
on doing this for a single processor!]
Home