Re: Nonsensical XSM Flask denial
On 17.03.2022 20:02, Jason Andryuk wrote:
> On Thu, Mar 17, 2022 at 2:14 PM Andrew Cooper
> 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
Re: Nonsensical XSM Flask denial
On Thu, Mar 17, 2022 at 2:14 PM Andrew Cooper 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
After a few tries it triggered:
(XEN) Xen WARN at irq.c:2348
(XEN) [ Xen-4.14.4-xc x86_64 debug=n Not tainted ]
(XEN) CPU:4
(XEN) RIP:e008:[] unmap_domain_pirq+0x3c4/0x490
...
(XEN) Xen call trace:
(XEN)[] R unmap_domain_pirq+0x3c4/0x490
(XEN)[] S xmem_pool_free+0x22/0x2f0
(XEN)[] S free_domain_pirqs+0x51/0x70
(XEN)[] S arch_domain_destroy+0x45/0xb0
(XEN)[] S domain.c#complete_domain_destroy+0x81/0x150
(XEN)[] S rcupdate.c#rcu_process_callbacks+0x114/0x2b0
(XEN)[] S softirq.c#__do_softirq+0x5a/0xa0
(XEN)[] S vmx_asm_do_vmentry+0x2b/0x30
I found the XSM checks a little confusing.
physdevop_unmap_pirq() calls:
xsm_unmap_domain_pirq() <- checks generic resource remove
unmap_domain_pirq()
xsm_unmap_domain_irq() <- checks remove_irq for the specific irq
access_vectors lists physdevop_unmap_pirq as remove_irq, but the xsm
check in the function is xsm_unmap_domain_pirq, which doesn't use
remove_irq.
In an earlier Xen version, these RCU callbacks may have run as xen_t?
Or maybe it's just racy which context is used? commit
8ad651705cbd0ad192398c1513d12c02b3197fa1 had:
2. When a domain is destroyed with a device passthrough active, the
calls to remove_{irq,ioport,iomem} can be made by the hypervisor itself
(which results in an XSM check with the source xen_t). It does not make
sense to deny these permissions; no domain should be using xen_t, and
forbidding the hypervisor from performing cleanup is not useful.
+# Domain destruction can result in some access checks for actions performed by
+# the hypervisor. These should always be allowed.
+allow xen_t resource_type : resource { remove_irq remove_ioport remove_iomem };
Thanks,
Jason
Re: Nonsensical XSM Flask denial
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?
~Andrew
Nonsensical XSM Flask denial
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?
Thanks,
Jason
