Re: Xen Security Advisory 360 v1 - IRQ vector leak on x86
On 21.01.2021 16:05, Roger Pau Monné wrote: > 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 +, 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. Otoh a driver domain may warrant 'oncrash="restart"', to limit downtime of depending domains. Or, like Xen does by default, a driver domain may invoke its own restart when crashed. Jan
Re: Xen Security Advisory 360 v1 - IRQ vector leak on x86
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 +, 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.
Re: Xen Security Advisory 360 v1 - IRQ vector leak on x86
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 +, 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. Jan
Re: Xen Security Advisory 360 v1 - IRQ vector leak on x86
On Thu, Jan 21, 2021 at 03:20:12PM +0100, Marek Marczykowski-Górecki wrote: > On Thu, Jan 21, 2021 at 02:10:48PM +, 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. Roger.
Re: Xen Security Advisory 360 v1 - IRQ vector leak on x86
On 21.01.2021 15:20, Marek Marczykowski-Górecki wrote: > On Thu, Jan 21, 2021 at 02:10:48PM +, Xen.org security team wrote: >> 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? I don't think so, no. Jan
Re: Xen Security Advisory 360 v1 - IRQ vector leak on x86
On Thu, Jan 21, 2021 at 02:10:48PM +, 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? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature
Xen Security Advisory 360 v1 - IRQ vector leak on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. Such reboots will leak any vectors used by the MSI(-X) entries that the guest might had enabled, and hence will lead to vector exhaustion on the system, not allowing further PCI pass through devices to work properly. IMPACT == HVM guests with PCI pass through devices can mount a Denial of Service (DoS) attack affecting the pass through of PCI devices to other guests or the hardware domain. In the latter case this would affect the entire host. VULNERABLE SYSTEMS == Xen versions 4.12.3, 4.12.4, and all versions from 4.13.1 onwards are vulnerable. Xen version 4.13.0 and all versions up to 4.12.2 are not affected. Only x86 systems running HVM guests with PCI pass through devices are vulnerable. 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. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa360.patch xen-unstable xsa360-4.14.patch Xen 4.14 - 4.12 $ sha256sum xsa360* c874ad2b9edb0791ac975735306d055b1916f4acbc59e6f1550fbf33223d6106 xsa360.meta 592f3afda63777d31844e0e34d85fbe387a62d59fa7903ee19b22a98fba68894 xsa360.patch 809515011efb781a2a8742e9acfd76412d3920c2d4142bb187588cd36f77383e xsa360-4.14.patch $ CREDITS === This issue was discovered by James McCoy, debugged in combination with Samuel Verschelde of Vates, and recognised as a security issue by Roger Pau Monné of Citrix. NOTE REGARDING LACK OF EMBARGO == This was reported and debugged publicly, before the security implications were apparent. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmAJixQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZh4cH/RyA5POGYEJEj4jHUFK+UmT08Bo6igUBMyJSvAJs T81eb35E2E2I8P35L7q8OOuLIGPWnTXOGPRnwizr2YF7UhmMm/773q5ellShUBgm SHtYl+btRaAp6gXB1PhgiETN3EH3aRgn89YBAQmg3U4Zb1RUiB2P2x6pVEGjMfBw Ks3Zj/ElCtfJcBA6xerNNLuqhwamueCEukw5b8eEHnop+y7TuLordpGGMybpQctx m04lp7zuJDAeshf47wlMQps79Ysx72CaThVKe/9A09z/c2mcR3m+NbieP7PJPggr n1I6QEaSUuapszkj+lC/L05tiyHdjXkoNAHwtdPr8jKtbKo= =YdXv -END PGP SIGNATURE- xsa360.meta Description: Binary data xsa360.patch Description: Binary data xsa360-4.14.patch Description: Binary data
