Re: [Xen-devel] [PATCH 5 of 6] Rework stale p2m auditing

[Tim Deegan <tim@xxxxxxx>]

At 08:21 -0800 on 24 Nov (1322122868), Andres Lagar-Cavilla wrote:
> I don't think we'll ever be able to move out of global p2m locks if we
> allow these inline audits. In a fine-grained p2m lock case, the code will
> acquire exclusive rights on a range of the p2m. But then, in order to
> audit the whole p2m, it will need to promote its exclusive access to the
> whole p2m, and that's a deadlock trap.

Hmmm.  Fair enough, I guess.  As you said, this audit code wan't being
any use so your patch is an improvement. :)

I'd still like to see the interface changed, in particular so a domain
can't audit itself.

Tim.

> Ultimately, I can submit a patch that fixes the bit rotting and leaves the
> inlines in place. And if and when the p2m locking becomes fine-grained, we
> can ifdef into global locking if P2M_AUDIT is nonzero.
> 
> It's kinda yucky. And somewhat crippling of the intended debugging
> purposes of an audit (with fine-grained locks). But it will work and will
> not put the fine-grained cart before the locking horse.
> 
> Thanks
> Andres
> 
> > At 16:48 -0500 on 14 Nov (1321289326), Andres Lagar-Cavilla wrote:
> >> The p2m audit code doesn't even compile, let alone work. It also
> >> partially supports ept. Make it:
> >>
> >> - compile
> >> - lay groundwork for eventual ept support
> >> - move out of the way of all calls and turn it into a domctl. It's
> >>   obviously not being used by anybody presently.
> >> - enable it via said domctl
> >
> > Thanks for looking at this code (which, as you say, had considerably
> > rotted).
> >
> > I'm not sure I'm a big fan of provoking audits from user-space rather
> > than having them run on every operation; in previous incarnations there
> > have been serial debug-keys that triggered auditing code (which would
> > then be run before and after every operation) - I found that much more
> > helpful in the case of failure, as it pointed to which operation had
> > caused the problem rather than saying 'something bad happened at somne
> > point'.
> >
> > If you really want to keep the hypercall, I think it could probably be
> > part of the existing paging/shadow control domctl rather than having
> > its own.  That would have the advantage of preventing an untrusted
> > domain from calling it on itself (which has in the past turned slightly
> > bitrotted audit code into a denial-of-service vector!).
> >
> > Cheers,
> >
> > Tim.
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel