> Those in search of ways to accomplish this, without modification to the
> hypervisor itself can be interested on one of two things :
How about tracking (and making) memory accesses as a means to:
1) monitor domUs for intrusion detection purposes (e.g. from dom0 or another
trusted domain)
2) patch domU code at runtime
3) do performance analysis
etc, etc...
I haven't seen anybody asking how to monitor other domains *without* special
privilege (e.g. dom0, or root in the domain in question), which would
probably have the answer "We hope not!" ;-) We already have a situation
where dom0 is always trusted, and root in a domU is always trusted within
that domU, so it's more a question of how convenient it is for those entities
to do strange things to memory, rather than if it is possible.
Since this is a low level discussion topic, it might be better suited to
xen-devel where we can get to the technical meat of what we're trying to
achieve, though.
Cheers,
Mark
>
> #1 - getting credit at secunia (and divulging a method that could bring
> hosts to their knees) *or*
>
> #2 - black mailing a xen host such as unixshell or others.
>
> No other useful scenario is possible. Either outcome of either scenario
> is ugly given the adaptation of Xen by public hosting providers who
> offer root access to a guest OS for $15 and don't verify the buyer. Even
> if they did, $15 gets you 'root' and the ability to cause serious
> disruptions (and the host quite a bit of money), enough to pay someone
> to stop.
>
> While I appreciate the academic nature of this list, please do not 'play
> into' social engineering, especially if you've been able to accomplish
> bad things in the lab.
>
> This is a fishing expedition, there is no other possible explanation.
>
> Best,
> --Tim
>
> On Wed, 2007-01-10 at 14:41 +0100, Petersson, Mats wrote:
> > > -----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
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home