-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, May 25, 2018 at 02:23:00AM +0000, Simon Gaiser wrote: > Andrew David Wong: > > ---===[ Qubes Security Bulletin #40 ]===--- > > > > 2018-05-24 > > > > > > Information leaks due to processor speculative store bypass (XSA-263) > > > > Summary > > ======== > > > > On 2018-05-21, the Xen Security Team published Xen Security Advisory > > 263 (CVE-2018-3639 / XSA-263) [1] with the following description: > > > > | Contemporary high performance processors may use a technique commonly > > | known as Memory Disambiguation, whereby speculative execution may > > | proceed past unresolved stores. This opens a speculative sidechannel > > | in which loads from an address which have had a recent store can > > | observe and operate on the older, stale, value. > > > > Please note that this issue was neither predisclosed nor embargoed. > > Consequently, the Qubes Security Team has not had time to analyze it in > > advance of issuing this bulletin. > > > > Impact > > ======= > > > > According to XSA-263, the impact of this issue is as follows: > > > > | An attacker who can locate or create a suitable code gadget in a > > | different privilege context may be able to infer the content of > > | arbitrary memory accessible to that other privilege context. > > | | At the time of writing, there are no known vulnerable gadgets in the > > | compiled hypervisor code. Xen has no interfaces which allow JIT code > > | to be provided. Therefore we believe that the hypervisor itself is > > | not vulnerable. Additionally, we do not think there is a viable > > | information leak by one Xen guest against another non-cooperating > > | guest. > > | | However, in most configurations, within-guest information leak is > > | possible. Mitigation for this generally depends on guest changes > > | (for which you must consult your OS vendor) *and* on hypervisor > > | support, provided in this advisory. > > > > In light of this, XSA-263 appears to be less severe than the related > > Spectre and Meltdown vulnerabilities we discussed in QSB #37 [2]. > > > > Patching > > ========= > > > > The specific packages that resolve the problems discussed in this > > bulletin are as follows: > > > > For Qubes 3.2: > > - Xen packages, version 4.6.6-41 > > > > For Qubes 4.0: > > - Xen packages, version 4.8.3-8 > > > > The packages are to be installed in dom0 via the Qubes VM Manager or via > > the qubes-dom0-update command as follows: > > > > For updates from the stable repository (not immediately available): > > $ sudo qubes-dom0-update > > > > For updates from the security-testing repository: > > $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing > > > > A system restart will be required afterwards. > > > > These packages will migrate from the security-testing repository to the > > current (stable) repository over the next two weeks after being tested > > by the community. > > > > If you use Anti Evil Maid, you will need to reseal your secret > > passphrase to new PCR values, as PCR18+19 will change due to the new > > Xen binaries. > > > > In addition, Intel Corporation has announced that microcode updates > > will be available soon [3]: > > > > | Variant 3a is mitigated in the same processor microcode updates as > > | Variant 4, and Intel has released these updates in beta form to OEM > > | system manufacturers and system software vendors. They are being > > | readied for production release, and will be delivered to consumers > > | and IT Professionals in the coming weeks. > > > > This bulletin will be updated once the Intel microcode updates are > > available. No microcode update is necessary for AMD processors. > > Hmm, the "Patching" section seems a bit misleading. AFAIU: > > 1) The mitigation (called SSBD) is disabled by default (on AMD and Intel). > > 2) For Intel CPUs the (not yet public) microcode update is mandatory. I.e. > there's no mitigation without it (unlike the Spectre variant 2 > mitigations). > > So if a user follows the above instruction they are still unprotected. > > Did I miss something? Otherwise I think we need to clarify the QSB.
Since the impact on Xen itself or inter-vm data leak is minimal, I think the most useful part is about providing this control to the guest (on Intel hardware). My understanding is that guest can use it without any Xen boot option (unless explicitly disabled). But you're right about microcode update - this all makes sense only with updated microcode on Intel and indeed we should clarify it in the QSB. - -- 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? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlsIEtEACgkQ24/THMrX 1yyWfwf/TcPy5CDLOq49+9+8W+hqfGLl3Z2M0L5IvhPltrwaNzaMoUuWmKjM+8HF ZwWHctapiV7o+32RAmFAFhOljNULekRXu7TL/uta7PgB4Xcpobf+n7FEXYa/IhOC E45LyUL1ehGO9YXl22n/zDoEct8Nkge76HvvpIZVP68Sc5xTMgvI7fncT6ByBpN0 8/8TtOEYN68xg1KjbrL+YfLTl0Q8AoIwdyS2V+uchhQLXGLf6AKT1YRYzJh2SzCB X1d2D8Qx34babqNVvrqaOZfX7Jbyz14L1ecyNJllWy+s2FWI4ZVcUZ3AuXKPihI/ LtNNlcOKbyI5ykVUju9dELTHUwFQGA== =QRfL -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180525134241.GA23232%40mail-itl. For more options, visit https://groups.google.com/d/optout.
