Marek Marczykowski-Górecki:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Dear Qubes Community,
>
> We have just published Qubes Security Bulletin (QSB) #49: Microarchitectural
> Data Sampling speculative side channel (XSA-297).
> The text of this QSB is reproduced below.
> This QSB and its accompanying signatures will always be available in
> the Qubes Security Pack (qubes-secpack).
>
> View QSB #49 in the qubes-secpack:
>
> <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-049-2019.txt>
>
> Learn about the qubes-secpack, including how to obtain, verify, and read
> it:
>
> <https://www.qubes-os.org/security/pack/>
>
> View all past QSBs:
>
> <https://www.qubes-os.org/security/bulletins/>
>
> ```
>
>
> ---===[ Qubes Security Bulletin #49 ]===---
>
> 2019-05-15
>
>
> Microarchitectural Data Sampling speculative side channel (XSA-297)
>
> Summary
> ========
>
> On 2018-05-14, the Xen Security Team published Xen Security Advisory
> 297 (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 /
> XSA-297) [1] with the following description:
>
> | Microarchitectural Data Sampling refers to a group of speculative
> | sidechannels vulnerabilities. They consist of:
> |
> | * CVE-2018-12126 - MSBDS - Microarchitectural Store Buffer Data Sampling
> | * CVE-2018-12127 - MLPDS - Microarchitectural Load Port Data Sampling
> | * CVE-2018-12130 - MFBDS - Microarchitectural Fill Buffer Data Sampling
> | * CVE-2019-11091 - MDSUM - Microarchitectural Data Sampling Uncacheable
> Memory
> |
> | These issues pertain to the Load Ports, Store Buffers and Fill Buffers
> | in the pipeline. The Load Ports are used to service all memory reads.
> | The Store Buffers service all in-flight speculative writes (including
> | IO Port writes), while the Fill Buffers service all memory writes
> | which are post-retirement, and no longer speculative.
> |
> | Under certain circumstances, a later load which takes a fault or
> | assist (an internal condition to processor e.g. setting a pagetable
> | Access or Dirty bit) may be forwarded stale data from these buffers
> | during speculative execution, which may then be leaked via a
> | sidechannel.
> |
> | MDSUM (Uncacheable Memory) is a special case of the other three.
> | Previously, the use of uncacheable memory was believed to be safe
> | against speculative sidechannels.
> |
> | For more details, see:
> |
> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html
> |
> | An attacker, which could include a malicious untrusted user process on
> | a trusted guest, or an untrusted guest, can sample the content of
> | recently-used memory operands and IO Port writes.
> |
> | This can include data from:
> |
> | * A previously executing context (process, or guest, or
> | hypervisor/toolstack) at the same privilege level.
> | * A higher privilege context (kernel, hypervisor, SMM) which
> | interrupted the attacker's execution.
> |
> | Vulnerable data is that on the same physical core as the attacker.
> | This includes, when hyper-threading is enabled, adjacent threads.
> |
> | An attacker cannot use this vulnerability to target specific data.
> | An attack would likely require sampling over a period of time and the
> | application of statistical methods to reconstruct interesting data.
>
> This is yet another CPU hardware bug related to speculative execution.
>
> Only Intel processors are affected.
>
> Patching
> =========
>
> The Xen Project has provided patches that mitigate this issue. A CPU
> microcode update is required to take advantage of them. Note that
> microcode updates may not be available for older CPUs. (See the Intel
> advisory linked above for details.)
>
> The specific packages that resolve the problems discussed in this
> bulletin are as follows:
>
> For Qubes 4.0:
> - Xen packages, version 4.8.5-6
> - microcode_ctl 2.1-28.qubes1
> - kernel-qubes-vm package, version 4.19.43-1 (optional)
>
> 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.
>
> Credits
> ========
>
> See the original Xen Security Advisory.
>
> References
> ===========
>
> [1] https://xenbits.xen.org/xsa/advisory-297.html
>
> - --
> The Qubes Security Team
> https://www.qubes-os.org/security/
> ```
>
> - --
> 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/THMrX1ywFAlzcka8ACgkQ24/THMrX
> 1yww4AgAhFgybrG66AFS9tA0Hn2XcDXHmQthV9geWgPEmbP1pTe8bzjWlnbMvCvE
> H8R3AnIFtm01Z6NhEEpImYn2B3mVC1AeC46qvrmBiB5vK5vBxwAb2HUvBRe58U0C
> 3cCZ21m0G3n1dh1Vh4hoRfiClCzvYZv9doAhKhhjT9xvWmNPno/VD8wJ4k/65LZ6
> nSVXVypJol/0THDuNvq+BXhRYoqHg2ngjp8TWGw4MMVMe6PJ+LBxm7qHkUeBIjxI
> 0zPiseXSMmAnrwItqAY3P5xX5ZI13B2Xd4XknT/T/1oTxV1Rpmt6+/KV3OgMBMZK
> TmsdI/hLIhJvSr1q5UpqDSMrur2Znw==
> =sVvH
> -----END PGP SIGNATURE-----
>
>From XSA297:
"""
Work is ongoing on xen-devel to develop core-aware scheduling, which
will mitigate the cross-domain leak by ensuring that vcpus from
different domains are never concurrently scheduled on sibling threads.
However, this alone will not prevent cross-privilege level leakage from
within the same domain, including leakage from Xen.
"""
I'm sorry, I'm not subscribed to xen-devel and am too lazy to go through
its archives. Is anyone from the Qubes team monitoring this--or better,
participating in it?
I can imagine a few Qubes-specific mitigations that might use some Xen
scheduling features to defend against future types of side-channel info
leaks in CPUs:
1) Schedule each domain in a given security label ('color') on a
specific CPU. If there are not enough CPUs, make clear to the user
which colors might be scheduled on the same physical CPU core.
2) Most (all?) CPUs that support Qubes have at least 2 cores. Assign
the first core the 'high' security label. Assign all other cores the
'low' security label. Assign dom0, possible future AdminVM, and any
user-designated VMs the 'high' security label. Schedule high-labeled
VMs exclusively on high-labeled CPU cores, and never schedule a
low-labeled VM on a high-labeled CPU core.
Information could still leak through e.g. shared caches, and special
attention obviously must be paid there, but this might be a useful
mitigation for similar kinds of attacks discovered in the future.
It could be worthwhile to sketch out what kinds of features Qubes might
need from Xen in order to accomplish this kind of thing and work with
them while they develop this new scheduler.
--
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/499c5305-3b50-906b-badf-3cd070d123d3%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
