> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Security Initiative Team
> Sent: 10 January 2007 01:42
> To: Petersson, Mats; Diwaker Gupta
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] Tracking DomU memory
>
> Is it possible for the "root" user of a guest domain to
> update the "text" section of a user-level process in that
> guest domain?
Sure can do - but what purpose would that serve - there is even an API
to do this, called the "ptrace" functions in the kernel. It's intended
for debuggers and the like, but can be used for other purposes if you
wish to.
>
> The text section is mapped as read-only,
> but is the "root" user privileged enough to be able to
> update the page-table entry (which will go through Xen)
> to make it a writable mapping and then update it?
Sure, you could do that - but there are non-trivial things to consider.
You'll probably be better off trying to do this by modifying the code in
the hypervisor, but even that is definitely non-trivial.
As mentioned elsewhere, consider two processors accessing the same page
simultaneously, just as one example of "things that are difficult to
handle".
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" <Mats.Petersson@xxxxxxx> 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
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home