QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)

[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-----

[Chris Laprise]

On 5/15/19 6:24 PM, Marek Marczykowski-Górecki wrote:
> Only Intel processors are affected.

I think the pattern showing AMD to be more conscientious in their
processor designs is now undeniable. Even if its only a matter of
degree, the difference appears to be rather substantial.

You should consider recommending a switch to AMD processors as a
short-term mitigation against CPU vulnerabilities.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Fidel Ramos]

On Thursday, May 16, 2019 9:41 AM, Chris Laprise <tas...@posteo.net> wrote:

> On 5/15/19 6:24 PM, Marek Marczykowski-Górecki wrote:
>
> > Only Intel processors are affected.
>
> I think the pattern showing AMD to be more conscientious in their
> processor designs is now undeniable. Even if its only a matter of
> degree, the difference appears to be rather substantial.
>
> You should consider recommending a switch to AMD processors as a
> short-term mitigation against CPU vulnerabilities.

I'm considering switching to AMD CPUs for this very reason. However I have been wondering whether AMD CPUs really have better designs or if Intel CPUs have been more broadly scrutinized. Is there any indication that security researchers have dedicated a similar amount of time to AMD CPUs as they have to Intel CPUs?

Fidel Ramos
PGP 7F07 1B7C 479F EDD1

[awokd]

Fidel Ramos:

I read somewhere Intel owned copyright to a class of speculative
execution, and it's been mostly this class that is turning out to be
vulnerable. AMD had to use other means to get around it, since they
lacked copyright, and so far their approach has been working in their
favor. Not sure how one could determine the amount of time spent
unsuccessfully researching AMDs.

[Tai...@gmx.com]

I think it would be nice to have a system security checker in dom0 that
would provide the user with a way to inspect and verify the security of
their system and provide a lettered score with the A+ best meaning a
fully blob free system with the latest cpu related updates, a quality
IOMMU and no insecure remote access stuff like proprietary BMC's. For
instance the kcma-d8/kgpe-d16. The G505s would be a non-plus A since it
has a few blobs but still features open cpu/ram init via coreboot, has
no ME/PSP and has a quality IOMMU.

What I mean by quality IOMMU is that the first gen stuff from intel
didn't support interrupt remapping and a few other things leaving it
with a massive security hole and inferior performance.

This would abstract the vulns folder for users that don't know about it.

On 05/16/2019 05:41 AM, Chris Laprise wrote:
> On 5/15/19 6:24 PM, Marek Marczykowski-Górecki wrote:
>> Only Intel processors are affected.
>
> I think the pattern showing AMD to be more conscientious in their
> processor designs is now undeniable. Even if its only a matter of
> degree, the difference appears to be rather substantial.
>
> You should consider recommending a switch to AMD processors as a
> short-term mitigation against CPU vulnerabilities.
>

The new ones are just as problematic due to having the PSP (AMD's ME)
and all the problems that come with that.

The future is OpenPOWER (and RISC-V once they make a RISCV-IOMMU) and
Xen/qubes needs to be ported to that for it to have a secure future as
soon pre-PSP boards and cpus will no longer be available.

POWER has an IOMMU with graphics support.

In the meantime I suggest if you want a secure pre-PSP freedom firmware
qubes machine to get a G505S laptop (with A10 cpu) or a KCMA-D8
workstation desktop (with 4386 or a 4284 for no mcode updates req) and
install coreboot, the kcma-d8 supports blob free coreboot-libre and
OpenBMC but of course is significantly slower than the RaptorCS
OpenPOWER stuff so if one wants to do non-qubes virt computing it is
better to get OpenPOWER which is price and feature equivilant to
non-free new x86 stuff. The blackbird and talos 2 have the IBM version
of OpenBMC which is better than the less powerful facebook fork that was
ported to the D8/D16 although both are much more secure than the average
off the shelf x86 non-free BMC that never sees security updates.

Note that coreboot doesn't always mean open source firmware there are a
few companies that sell computers with an entirely blobbed Intel FSP hw
init as "coreboot open firmware" vs the D8/D16's native 100% blob free
coreboot and the g505's open cpu/ram init.