-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Marek Marczykowski-Górecki: > 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).
Yes that's also my understanding. Although users might want to enable it globally on AMD hardware since there's no option for guests to control it. > 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. I think it also should mention the global option even if we think keeping it off by default is fine. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlsIIZkACgkQkO9xfO/x ly+EgRAAylcmodt9wwOSaiW15623Mi5aOwPhjKLhibzilU6zPwb/PPm6lHwBm/JH p/05XLlTUVUOLhYmDzcJESiVJtrlEGAR/wFJoT2hvgsl4aYmE92tyh5W2RoydEze 8dCRi+99XK2qRupfFqAPanJHXu3zr3RA7QLSQhtgTsTL6jwT6nGH0fqmOzt5eKtK NDpnvtK8+0MNTQ4hkNOMZd6Yhd4TZHyFf3Ns+resAz/y5fA9KVht/w98GKhbA1V/ SddJ7dUH3pj4ZqGcB7vL7R4bwfgtbyoxbc8SppLGxAfWJFPktsUi9L3Rv1dpVhI6 XRTpH8AbENEUfkH4Tm2kGkX7SXnHYLc9KkKAss/KIB8M37V81DyMrYo/UxDuHrKI reeWryq/MsBwMYnUqS9SYfC+4ewOsUt1SM3ppTqDvJXACiBKraIaoPY8CRuMW7zu J4Gqdv7Kk7sWgPMcp1fPOwEnqKImNNbdIQg9NcRaCyofJ5socQ8e2vUbh/jphxyI ujnKAAg7nw72HaLj5gHRNWSSVi9rdPIx1QkqYpoFxVbThv55DxOUIt8lMXP+VwYi N5L7PmaBrkisS/36Mhwhd8bL+CYhn/p4up04SI86bZWsr9PMeuu20ixlrtauqpRJ L+Hjt0lK6GvB2B3eHsM0aDb4uoDj8bYq9k2Ntm/SSGFP141582A= =h878 -----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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/518dee7e-800b-5bc7-f103-f9ed03ff6b36%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
