Re: [qubes-users] SWAPGS Side Channel Attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [Now with Inline-PGP such that google group doesn't break the signature] sergei.puti...@gmail.com: > Is Qubes affected by the SWAPGS attack? - From the Bitdefender "white paper" [1] (They reported this vuln.): "A quick analysis of the Hyper-V kernel and of the Xen hypervisor kernel revealed that the SWAPGS instruction is not used, so exploitation is impossible." [1]: https://businessresources.bitdefender.com/hubfs/noindex/Bitdefender-WhitePaper-SWAPGS.pdf > I haven’t found a statement or Security Advisory from Xen. But it > seems Xen still hasn’t even fixed the original Spectre v1 yet: > https://xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ > At the time of original Spectre, v1 was deemed very hard to exploit on > Xen, but new variants of v1 like v1.1 and SWAPGS may invalidate that > hypothesis. For Spectre variant 1 my understanding is that they are not aware of a exploitable code path in Xen. But they are working on hardening. For example grep the commit log for array_index_nospec or see [2] for an arbitrary example where they discuss this during review. In the long run I hope there will be some compiler assisted technique instead of manual review, which likely misses cases. But something like this is not in place currently. See [3] for a description of the non-public gcc plugin from grsecurity which implements this approach. [2]: https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00982.html [3]: https://grsecurity.net/respectre_announce.php Simon -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAl12ZYgACgkQkO9xfO/x ly8fVhAAytcPEKgHfchZFSx8b4q0yGijnM2PVS5z7zbYchQtZ3xkgf+6ZxGwauay buD22CE2B+ZMWhgnS3VW5fB28dHQAQeU2BO51zcP8EatlvkVVC8lRa1jzuPKsON5 q2YGarwUott3/tcjL8iOsU9FPfmHbV2mu/hFzt2ZpgqWBGghmtvjpeNzXb+XM1LV ohQoMIS+bRr4IjXpOUlsWCyLF1grpKEB6EfMSCC/o14A8iZqvSMo23nhF0adQwcp 5qZn7Lg572YcSJI7YxjT5D+6f4tIRS3V4yjYbIw2catOz6CozGQfYnX766jPKFFp CnESPKs5EMk7+ayDaOjAvx79/jNjR3aBlajbyg5gkXc5qTj8Zm7MeTy8qnJ4zv4I FrnBcFu1l1/wPWzYvk53ES90XnuRixE2MMHQf/NW5HId6Gn4pWUBkmL5pivoEG5L 1tWT/bAHpnQ50m3UsmP+SJ0K3+mqqoCJgsRh/zcwhtlgABCJl7sst8uCRNsgU9rX YGMVR1kjS2EI8BWwGwGK0wEkKVkmUmNGwRJUTgwA7dgpBEE/tZ6letKM0mF8F40b U3SGdYPrM/OAHlMJijq5MpKXMiKOFemRg4RVDEV3fK8FEEhzN10K3l2TP6PjxaW+ pA/Du6CKFOvXG2pyPrzUwjhdrp4RuQKwdvtHdkdi0UHQEs1mekY= =7n0V -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e4c345f9-7645-2853-5e12-2b70d8f823f9%40invisiblethingslab.com.
Re: [qubes-users] SWAPGS Side Channel Attack
sergei.puti...@gmail.com: > Is Qubes affected by the SWAPGS attack? >From the Bitdefender "white paper" [1] (They reported this vuln.): "A quick analysis of the Hyper-V kernel and of the Xen hypervisor kernel revealed that the SWAPGS instruction is not used, so exploitation is impossible." [1]: https://businessresources.bitdefender.com/hubfs/noindex/Bitdefender-WhitePaper-SWAPGS.pdf > I haven’t found a statement or Security Advisory from Xen. But it > seems Xen still hasn’t even fixed the original Spectre v1 yet: > https://xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ > At the time of original Spectre, v1 was deemed very hard to exploit on > Xen, but new variants of v1 like v1.1 and SWAPGS may invalidate that > hypothesis. For Spectre variant 1 my understanding is that they are not aware of a exploitable code path in Xen. But they are working on hardening. For example grep the commit log for array_index_nospec or see [2] for an arbitrary example where they discuss this during review. In the long run I hope there will be some compiler assisted technique instead of manual review, which likely misses cases. But something like this is not in place currently. See [3] for a description of the non-public gcc plugin from grsecurity which implements this approach. [2]: https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00982.html [3]: https://grsecurity.net/respectre_announce.php Simon -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/06688f5c-e93d-3089-bbd5-33f9f8d7c336%40invisiblethingslab.com. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] PCI passthrough working in Qubes R4.0?
Marek Marczykowski-Górecki: [...] > I don't see anything else related to this device. So until Simon gets > permissive mode sorted out, it look like you have to use that usb > ethernet. FYI: https://github.com/QubesOS/qubes-core-admin/pull/184 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ec1f044a-7910-1966-0e2a-d3b9b20503d3%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] PCI passthrough working in Qubes R4.0?
Marek Marczykowski-Górecki:> On Thu, Jan 18, 2018 at 03:06:00PM +0000, Simon Gaiser wrote: >> awokd: >>> On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote: >>> >>>> >>>> According to logs provided by mossy-nw permissive mode is correctly >>>> enabled in xen-pciback in dom0 for this device. The question here is what >>>> else is needed for HVM (using qemu in stubdomain). >>> >>> My dom0 log shows that too, but the guest-dm/debug log showed the PCI >>> device always getting added with permissive=false. Maybe that's what you >>> are saying, qemu isn't passing the value along? > >> Yes that's the problem. The guide sets permissive mode in pciback and >> not via libxl. So the stubdomain never learns about it. Will take a look >> today. > > If that's the case, it looks we need another option for PCI device, like > this: > > qvm-pci attach sys-net dom0:xx_yy.zz -o permissive=True Yes, exactly. And if I didn't miss something we first need to teach libvirt about the permissive option. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a4a1f49c-4568-405c-ba05-6755da75abf2%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] PCI passthrough working in Qubes R4.0?
awokd: > On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote: > >> >> According to logs provided by mossy-nw permissive mode is correctly >> enabled in xen-pciback in dom0 for this device. The question here is what >> else is needed for HVM (using qemu in stubdomain). > > My dom0 log shows that too, but the guest-dm/debug log showed the PCI > device always getting added with permissive=false. Maybe that's what you > are saying, qemu isn't passing the value along? Yes that's the problem. The guide sets permissive mode in pciback and not via libxl. So the stubdomain never learns about it. Will take a look today. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b33c3a7f-4857-4507-c8a2-961a0bbdbd8b%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
