On Thu, Jan 21, 2021 at 03:50:55PM +0100, Jan Beulich wrote: > On 21.01.2021 15:34, Roger Pau Monné wrote: > > On Thu, Jan 21, 2021 at 03:20:12PM +0100, Marek Marczykowski-Górecki wrote: > >> On Thu, Jan 21, 2021 at 02:10:48PM +0000, Xen.org security team wrote: > >>> Xen Security Advisory XSA-360 > >>> > >>> IRQ vector leak on x86 > >>> > >>> ISSUE DESCRIPTION > >>> ================= > >>> > >>> A x86 HVM guest with PCI pass through devices can force the allocation > >>> of all IDT vectors on the system by rebooting itself with MSI or MSI-X > >>> capabilities enabled and entries setup. > >> > >> (...) > >> > >>> MITIGATION > >>> ========== > >>> > >>> Not running HVM guests with PCI pass through devices will avoid the > >>> vulnerability. Note that even non-malicious guests can trigger this > >>> vulnerability as part of normal operation. > >> > >> Does the 'on_reboot="destroy"' mitigate the issue too? Or on_soft_reset? > > > > Kind of. Note you will still leak the in use vectors when the guest is > > destroyed, but that would prevent the guest from entering a reboot > > loop and exhausting all vectors on the system unless the admin starts > > it again. > > > > In that case I think the premise of a guest 'rebooting itself' doesn't > > apply anymore, since the guest won't be able to perform such > > operation. > > And how exactly would an admin tell a guest from rebooting for > fair reasons from one rebooting for malicious reasons? To me, > setting 'on_reboot="destroy"' would imply there's then some > other mechanism to restart the guest (possibly with some delay), > or else a reboot attempt by this guest would effectively be a > DoS to its users.
Well, I would expect there are deployments or configurations that simply don't expect (some) domains to reboot themselves. Ie: for example you won't expect driver domains to restart themselves I think, and hence you could safely use on_reboot="destroy" in that case to mitigate a compromised driver domain from exploiting this vulnerability. Roger.
