RE: [Xen-users] Tracking DomU memory

[Security Initiative Team <passrete@xxxxxxxxx>]

Here's essentially what I want to do.

Lets say I start a user-level process in a guest domain.
The guest domain will set-up page tables for the process and 
register those page tables with Xen.
Xen will mark those tables as read-only.

Now, say I want to protect the "text" section of this
process from malicious updates.
I note the page table entries which contain the mapping
of the "text" segment, and pass these to the hypervisor
to monitor.

Now if someone with sufficient privileges wants to
maliciously update the "text" section, he has to update 
the page table entries to change the mapping of the read-only
"text" section to writable.
This update of the page tables will go through Xen.
Now Xen will notice that pages it was monitoring are
trying to be updated and it will raise an alert.

"Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote:

I'm a bit surprised about the interest in "tracing/tracking writes to
memory" cropping up again and again on this mailing list. I know why I'm
working on such thing (checking specific writes to specific
memory-mapped IO areas), but I'm concerned about the belief that a
general option for tracing/tracking memory writes to generic memory
would be particularly useful and even achievable - bearing in mind that
under normal circumstances the processor may perform multiple writes per
clock-cycle in any number of different regions (stack, data section and
"bss" section, shared memory sections, etc, etc) - a single page-fault
will take several dozen clock-cycles just to get to the page-fault
handler and out of it again, followed by many dozens of cycles needed to
sort out what caused the page-fault and "fixing it up", so we're talking
about something that would potentially slow the processor down by a
factor of around 100. If you are prepared to take that sort of
slow-down, then I'd suggest a simulator that has memory tracing/tracking
capabilities - as it's probably going to be 2-5x faster than the "trap
and fix" way to solve the problem.

--
Mats
>
>
>
> "Petersson, Mats" wrote:
>
> > -----Original Message-----
> > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > Diwaker Gupta
> > Sent: 15 December 2006 22:56
> > To: Security Initiative Team
> > Cc: Petersson, Mats; xen-users@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-users] Tracking DomU memory
> >
> > I actually want do to something similar, but simpler. I'm only
> > interested in keeping track of pages that a guest
> domain is accessing
> > (both reads and writes). I'm _not_ looking for the
> *exact* memory
> > address -- just the physical page being accessed. Can
> log dirty be
> > modified to keep track of read accesses as well?
>
> This isn't far from what I'm doing (except I need to
> look at one or a
> few pages, which makes life somewhat easier).
>
> You'd have to change the page-table writes so that they
> are written with
> "not present", and then update your statistics based on
> the page-fault.
> You'll have to "fix" the fault and then reset the
> page-table, which is
> probably easiest done by using the x86_emulate_memop() function
> [alternatively, set the trace-bit in the flags on stack
> before exiting
> the PF-handler, take the trace-interrupt, reset the
> page-table and
> continue].
>
> However, if you're doing this for every memory access
> of the guest,
> you'll not get much work done... :-(
>
> --
> mats
> >
> > Thanks,
> > Diwaker
> >
> > On 10/9/06, Security Initiative Team wrote:
> > > My main purpose is to know when a user-level
> application in DomU
> > > is updating its memory.
> > > (Tracking changes to the stack segment might be too hard
> > due to frequent
> > > memory updates, so maybe only the "text" segment).
> > >
> > > I want to be able to track this from either Dom0 or the
> > hypervisor layer,
> > > whichever is easier.
> > >
> > > When is ptwr_emulated_update() used and when is
> do_mmu_update()
> > > used?
> > >
> > > Thanks,
> > > -Criag
> > >
> > >
> > > "Petersson, Mats" wrote:
> > >
> > > What do you ACTUALLY want to do?
> > >
> > > log-dirty doesn't log to a file - it keeps track of "dirty"
> > pages in a list
> > > in memory, but doesn't actually store it in a file
> [ever, at all].
> > >
> > > do_mmu_update is possibly a good place to hook into, but it
> > depends on what
> > > you want to do... [And it's non-trivial code, so beware of
> > complications
> > > from changing it].
> > >
> > > You may want to look at ptwr_emulated_update, as that's
> > used when the
> > > do_mmu_update() hypercall isn't used to update a
> page-table-entry.
> > >
> > > --
> > > Mats
> > >
> > >
> > > ________________________________
> > --
> > Web/Blog/Gallery: http://floatingsun.net/blog
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-users
> >
> >
> >
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

---

Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users