Re: [Xen-devel] [PATCH 16/18] arch/x86: use XSM hooks for get_pg_owner access checks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.08.12 at 15:44, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 08/07/2012 02:55 AM, Jan Beulich wrote:
>>>>> On 06.08.12 at 18:29, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>>> On 08/06/2012 11:26 AM, Jan Beulich wrote:
>>>>>>> On 06.08.12 at 16:32, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>>>>> +static XSM_DEFAULT(int, mmuext_op) (struct domain *d, struct domain *f)
>>>>> +{
>>>>> +    if ( d != f && !IS_PRIV_FOR(d, f) )
>>>>> +        return -EPERM;
>>>>
>>>> ... Dom0 is neither privileged for DOM_IO nor for DOM_XEN.
>>>
>>> Actually, it is. IS_PRIV_FOR returns true for any domain when called from an
>>> IS_PRIV domain.
>> 
>> That's a side effect of the current way of handling this, not
>> something that is either logical or designed to be that way (it
>> certainly is bogus even now for DOM_XEN, and with
>> disaggregation - afaiu your plans - it'll also become bogus for
>> DOM_IO, where right now one could consider it half-way
>> correct).
> 
> In that case, I think it would make sense to modify these XSM hooks
> when IS_PRIV_FOR is changed to not short-circuit on DOM_IO/DOM_XEN.
> If you're suggesting changing the condition to something like
>   ( d != f && !(IS_PRIV_FOR(d, f) || IS_PRIV(d)) )
> I could do that, but I think that type of change would be best done
> in another patch actually making IS_PRIV_FOR(dom0, DOM_XEN) == false.

>From a standpoint of wanting to keep logically distinct things
separate I agree. I'm merely afraid that this will be overlooked
later, and causing otherwise unnecessary loss of hair until the
now hidden construct is found and adjusted.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel