[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Tim,

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.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.