Re: Nonsensical XSM Flask denial

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.03.2022 20:02, Jason Andryuk wrote:
> On Thu, Mar 17, 2022 at 2:14 PM Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> 
> wrote:
>>
>> On 17/03/2022 17:52, Jason Andryuk wrote:
>>> I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
>>> device assigned.  Xen logged the following Flask denial for a second
>>> PVH dom5 (uivm) without any PCI devices assigned.  This is Xen 4.14.4.
>>>
>>> (XEN) avc:  denied  { remove_irq } for domid=5 irq=17
>>> scontext=system_u:system_r:uivm_t
>>> tcontext=system_u:object_r:shared_irq_t tclass=resource
>>>
>>> Domain 5 as uivm_t and irq 17 as shared_irq_t both look correct.  But
>>> it doesn't make sense that uivm would make a hypercall for an irq.
>>>
>>> Could this be from RCU calling complete_domain_destroy() when current
>>> is dom5 (uivm)?  What would current be set to when RCU runs its
>>> callbacks?
>>
>> RCU runs in softirq context, so yes - (almost) any use of current would
>> be bogus.
>>
>> But I can't spot any overlap between the physdevop_unmap_pirq XSM check,
>> and complete_domain_destroy().
>>
>> Any chance you can reproduce this with a WARN() in the AVC denied path,
>> so we can see what's going on here?
> 
> The path I found reading is:
> complete_domain_destroy
>   arch_domain_destroy
>     free_domain_pirqs
>       unmap_domain_pirq
>         xsm_unmap_domain_irq

I wonder whether an XSM check makes sense here at all for a dying
domain.

Jan