On 17.03.2022 20:02, Jason Andryuk wrote:
> On Thu, Mar 17, 2022 at 2:14 PM Andrew Cooper <andrew.coop...@citrix.com>
> 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
