Re: [Xen-devel] [PATCH v2 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.03.17 at 20:39, <sstabellini@xxxxxxxxxx> wrote:
> CC'ing Andrew, Jan and George to get more feedback on the security
> impact of this patch.
> 
> I'll make a quick summary for you: we need to allocate a 56 bytes struct
> (called pending_irq) for each potential interrupt injected to guests
> (dom0 and domUs). With the new ARM interrupt controller there could be
> thousands.
> 
> We could do the allocation upfront, which requires more memory, or we
> could do the allocation dynamically at run time when each interrupt is
> enabled, and deallocate the struct when an interrupt is disabled.
> 
> However, there is a concern that doing xmalloc/xfree in response to an
> unprivileged DomU request could end up becoming a potential vector of
> denial of service attacks. The guest could enable a thousand interrupts,
> then disable a thousand interrupts and so on, monopolizing the usage of
> one physical cpu. It only takes the write of 1 bit in memory for a guest
> to enable/disable an interrupt.

Well, I think doing the allocations at device assign time would be
the least problematic approach: The tool stack could account for
the needed memory (ballooning Dom0 if necessary). (We still
have the open work item of introducing accounting of guest-
associated, but guest-inaccessible memory in the hypervisor.)

What I don't really understand the background of is the pCPU
monopolization concern. Is there anything here that's long-running
inside the hypervisor? Otherwise, the scheduler should be taking
care of everything.

Jan


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