Re: [Xen-devel] [PATCH v2] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> 06/23/17 6:49 PM >>>
>On 06/23/2017 11:00 AM, Jan Beulich wrote:
>> So far callers of the libxc interface passed in a domain ID which was
>> then ignored in the hypervisor. Instead, make the hypervisor honor it
>> (accepting DOMID_INVALID to obtain original behavior), allowing to
>> query whether a device can be assigned to a particular domain.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> v2: Alter the semantics to check whether the device can be assigned to
>>      the passed in domain.
>> TBD: It's not clear to me whether the test-assign XSM hooks are still
>>       useful this way.
>
>As long as the only user of this hypercall is the device assignment
>path, I would remove the XSM hook for test_assign and use the
>assign_device hook for both test and actual.  That way, if XSM is
>actually preventing the assignment, you will get the same AVC denials as
>if you tried without doing the test first.  The hook should just skip the
>two checks relating to (d) if it is null.
>
>If this test hypercall were to be used as part of a query (such as
>populating a list of assignable devices by trying all PCI devices listed
>via sysfs), then it would make sense to have either a different hook or
>a flag in the XSM hook to silence the audit messages since you aren't
>actually trying to do the assignment yet.  That change will make the
>cause of the "can't assign" error harder to diagnose, however, so unless
>it's being used like that I don't think it's a good idea.

Well, that last aspect is what I'm currently retaining with the DOMID_INVALID
behavior, hence why I've wired that case to the test-assign hook. If we were
to remove that hook, then that special case should go away altogether imo
(completely doing away with original behavior). Anyway, let's first see what
others think ...

Jan


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