QSB #40: Information leaks due to processor speculative store bypass (XSA-263)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #40: Information
leaks due to processor speculative store bypass (XSA-263). 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 #40 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.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/

View XSA-263 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#263

```
---===[ 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.

Credits
========

See the original Xen Security Advisory.

References
===========

[1] https://xenbits.xen.org/xsa/advisory-263.html
[2] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt
[3] https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html

- --
The Qubes Security Team
https://www.qubes-os.org/security/
```

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/05/24/qsb-40/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlsHTIcACgkQ203TvDlQ
MDCoHw//dx+GcN8QIz0ww1tUQZufTaDwSy0eiY+Ul3PFX5CVnhzmXk6r4iRSkYVU
lxSitio+STe2WHnpS6dVQhRcR+RCBu5A07MPvzq9tv/tMw8nkRx5GnE54so9oVjB
wv26jkMdo7XreZuih3MEjacsvgL9hogpTAzuxelpU3Ve9/J3GhiNbqgscx+Dop4n
hloKnKmwKbJOgyZcxH/Px5nnDLpICR5Z5gTZDKQPvzXaPVRbQ8cS/WPLdbqxnAH8
x64lOeMLM5UtPXdnOKex2aWPKdnudCKsknsTvbVfS3NcSzths26B+HjVPoM1OOpc
xkXUH9m36ie7QMCrwKGwr+RW4nilIBScMV4pSKnx1xtjaccbUVcNsyE86Zt2ozSw
b13NjZIIsGstAVmmvXjxN/4oA6jDzYB94OCMkYMORujE1m0JbiiprYL5y+aAPL1E
8K+sxAqnDvFGliOZy4uIMNEV8L80aw5ENYtpnRCG3SNDdHu72Ujjiz/NXu/lnK8e
xR4f1OOkIWc2OgqDkGJ9fWoPBIEgzsk59c81g5t3K5uI0ZpoYOtrJ2bT7lN4lQ05
VGY7s40SZdWiEHlG1NTiEhQ2kvcI293Gmhd/M8eOA9hca502UzpT0Kcbyn6hskkw
WHmnqjaik1fghxuezHQ/nVKVeyZRNaJuT8QzlDzLB/l+ssjP/o4=
=Lwt8
-----END PGP SIGNATURE-----

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Andrew David Wong:

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.

Simon
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlsHc4AACgkQkO9xfO/x
ly9R0BAApVIjpzmMKViLmuOxVDdjegmP1bDrC0eHJldUmOKfwT4K+srjLODGQVH7
llvQvwAS+l6zoGb+oCnGdfKSAxF27rrQA8uQCeJViLkaNqaZLxKRNL2T134vN3OH
qxiYii7D4SegcR4WZZDrrIJb/l2v16PN7gUnd0uNeuqBy8vDhiYTWL637OBb3Azw
0kKcbUfAUYvqbFkAvsbGzjx+Dqdh9nhBKYteuvxw2ax85DcdL0yawO8bFiKMwQ7V
YDIvS6H89zh9po7c3ipeSH2I5k6PJUkmtxNVD7NsaXqGXJzOGEI6d2VP4JV3J+qa
mLvAj9L2diBJMlTp/NapIGwKMmy3jyQ06w3+Au3bF1im8lovw9gnEfl4qbQzhGHm
nuvIpBHpTyrQEIQzVMSGSEEGZcFiE6OBo7m8UJwkWZFmxWRM/A55Npy9uMN+Vlz5
Rejryxkt1Q/+tET8RwQOxNBjO0zZqGJzcD7tj5qIhm4YofIKsAVgE0BhAY3jOD5Q
+WL0mtWWTNZjaWmo+ZSeCM0W6r4nmDeJQnYI47y35FHHYdjCYGhTQQu4VrBe3PTp
z0iUI/Y/cxySNA9ONqwwb1r5LW7mF1gqRqu3QStpW5thwYvgihcH1VzQ91n+8WS+
Jjn0sY2lAZ4D1juLRhdEX4aR6l+jGjXMQVpXIojUlpUpMIRFx9g=
=p3tp
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

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

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

To make sure I understand:

1. On both Intel and AMD processors, the SSBD mitigation is globally
disabled by default. If the user wishes to enable it globally, the
user must do so manually with a special Xen boot option.

2. For Intel (but not AMD) processors, the SSBD mitigation can be
enabled locally by Xen guests without the user having to manually
enable it globally.

3. For AMD (but not Intel) processors, the SSBD mitigation cannot be
enabled locally by Xen guests. The user must manually enable it
globally for it to have any effect at all.

Is this correct?

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

Do you both have a security recommendation for Qubes users about
whether they should enable the global option or not? It sounds like
it's important for users with AMD processors, given point 3 above.

Will it be automatically enabled for guests on systems with Intel
processors?

My understanding is that the main reason for not globally enabling the
option is to avoid the performance penalty, but is there any _security_
reason that a Qubes user wouldn't want to enable it?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlsI6XQACgkQ203TvDlQ
MDCUvw/+O2U+91Z8jSgT8kT0D/FBYy74icAS8ELMxr2eFQYFZ6kKtMAh0ypETIa3
Uj7f2oEZTmfvljS2bAQ0ZdJClyMFLOFYj5hhmZmUYY/Ln7a6s9UxwDlV5PvTi1NL
usUJ2GQodxI1uERblqQiZclh2y+IJ0QzoTs0YybapeVUGw8DzPWQ6Qy/wIv/iWpg
r6NqphBxGQbuF7eaYAkyBS9gHdPKx4JhnCptTdqPRDR+oe31TS5EetvU/NJLJG6u
7xjpdleFuRt0p4cLTC2N3uP41arwEVtYkSVDedkaZZC2+9h7pslnXW1xUNSjB+8o
We5XXVf4DQW0TXGIkhdSvZCdF/GrfhpoVQNnZ6a4ldQponkRcY/HAOHV/Xbx4JKe
QVFgdocgbvxuPLGbiPrawjo8yryK3LU0LG84+DjAdL0puzU5Qr4LDm1GUcykZflk
sSPcRr9sitTchG2A+J9Ncq4B46MrOAhkFtWb8/yfHEh9gCiQ4ImVcSpkOtsF2Lot
9X/4A5eqshr08fmlif2uudaV+27k/U1ggo82AarOOOFlq+xfNcSHsZW7LW1Xj/Af
cEHmronxkLURp4uqQ1AaGckkIQ9EF2Skh691RAGQxGvHkqfHZlupNKQjmQHqSuuW
E71B4Ywqru8HorQi86W0aGiu5PecvtsVcRjx6FdXXgcH9JCtako=
=w81l
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Marek and Simon,

Just a friendly reminder that we should clarify these issues and, if
appropriate, update QSB #40.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlsd7mQACgkQ203TvDlQ
MDAgXBAAw8rUcxtYAhKBGAyzRONABIP2pOJTNeO9sq6leVfhMFiuDAyY0iFHT37n
j9j94FwsAh9PH01merE8jC5ilFxTP3+yQicXp4u0XjZTSkHIZVM6n3IA9kpr4PrM
gW+PpughygHRbAmS/CsOyVi/lV0r3I1cxFVXXtK/AOO7ycVa+068jq2xQEkG/4/Y
aqZV3c8SlLMGWTL1wputszz+znLphr0fc5ER4M4TJHZw8frYOfC7Rw4IJCTRipP9
IxVQb33s9Uvk1CrVu/3j7aFfF2W78C7+PIXTaqr6p88S//UV4irK4VrYtjKfdVrM
FjiGYWQWYCQ9+oTJdcEijGA+cxWGC0c4tmkWi2Wp4CxJELKOWz3giFpFUS/040jp
sqeU25dOPvVobVzC/+siaa8n8gLkrKmlq58HIcxL+dr5IAEa3OLJ4vubwi+V5CAc
36Q41RzQW3N5mtTtIshPQI3Wf1JzGqNpE/GVY4RygIaMKrGdRjekzBJk4KTW8OPN
Lmck0fEfleJomXxD0lwLtktRfuX1z4NnexWLZCPhb6LikMFxr8L2i7YBOrpKoyq4
8pi7xeW347y2rDTCJcr1f+XCo2+7i6ULH6cYfhbN7amFnIousEI+Yl8V5q3FLRwD
llwW9ZzfGR+hvxDseLXXFKxdmftaJ+iLd+LP2J7YSJkCLBueyEk=
=iqjU
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes.

> >> 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.
> >
>
> Do you both have a security recommendation for Qubes users about
> whether they should enable the global option or not? It sounds like
> it's important for users with AMD processors, given point 3 above.

As explained in the XSA, the risk for Xen itself (or inter-guest attack) is
very minimal. So, a proper compartmentalization mitigate the issue.

> Will it be automatically enabled for guests on systems with Intel
> processors?

Depending on guest kernel. Kernels currently we have in repositories do
not enable the option.

> My understanding is that the main reason for not globally enabling the
> option is to avoid the performance penalty, but is there any _security_
> reason that a Qubes user wouldn't want to enable it?

I think performance is the only reason here.

BTW I still don't see new Intel microcode update on their website, so
this option on Intel (even if kernel would support it) is useless.

Andrew, could you prepare clarification to the QSB? We'd sign it with
this month canary.

- --
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/THMrX1ywFAlsezyUACgkQ24/THMrX
1yxC9wf8DFJvP1yQxAul7MTZmiTSgVePksLjZeYrzOKdUSQE/Q480HAlf1X2bTnL
iZ4dY9sBii/+Le9a+xBXHo90eHK2VMzHCqAV7vJrUYlllxbsvo7B6LW3XObH0/Ef
ZdSb+XUBJToFZ/h9QpmByvUyWZ9vmrQU04y/8mLz3harYfjTx/58yWOAsdLyBKnM
sFAx4hgyn3qVzYxwvxMoCjRuAus+CL2tKQN73eRyui+KrF+o6Js6CYb4B+2bPMxb
PZ+L8vbJ3iEY/X6RXR/sOjryFy0VS9xjUnzDCzw/rgyuksXaUsJoqKAZ2Q2OHruH
hFRd9InzOjP533pcBRgJpIyJxaXwjQ==
=/XP6
-----END PGP SIGNATURE-----

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

The latest upstream kernel enables the mitigation by default only for
seccomp processes. So web browsers should be covered.

But (AFAIU) for Qubes this will only work on Intel CPUs since on AMD Xen
does not support virtualization of SSBD (But it seems Linux does it for
KVM guests?).

So for Intel the default seems to be good enough (When microcode updates
are finally available).

Not sure what to recommend for AMD.

>> My understanding is that the main reason for not globally enabling the
>> option is to avoid the performance penalty, but is there any _security_
>> reason that a Qubes user wouldn't want to enable it?
>
> I think performance is the only reason here.
>
> BTW I still don't see new Intel microcode update on their website, so
> this option on Intel (even if kernel would support it) is useless.

I also checked Debian, Fedora and OpenSUSE, since IIRC OpenSUSE had
early access to the Spectre microcode update. But none of them has any
updates. Some users *might* still have microcode updates through their
BIOS (Intel wrote somewhere they are "working on it" with vendors).

> Andrew, could you prepare clarification to the QSB? We'd sign it with
> this month canary.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlse7WAACgkQkO9xfO/x
ly+5kA/9EbjFJpuv2WNnuYuVvSTnvJwzkhVyKhogS2SCCYy+hXbDI+jtr/OAx3Rb
tIgI/kBwhbX791Rwr5oUDviKCbEicf0xgS3H+UbK0pJrCCqsxNgbz3qQiGWQW8p8
5iAUCf80zTfrhRzh1IQg+E6EeQ9wTFkSgUjHytVjYfsXXLn4rsyJ/2Kh+Nz+ZnC1
Y3im3hEPDxO6BJNvqqMxHttJzbtvHlQ/euOBoPifwONM5QxBNZf7p2YjAOBApHBZ
2rP5eIFpkho3qxPvgoWkhRZk2byRkZCv30wMYIgZJLHJr5htvWM4hM2zKAePrDBi
hCSQIbAKYINdWE9A+M95wg9YB003kSNL7+zjFocjVtA+Lxjn+H/MD5dgOnnRqg1i
6H/Ve2CvbjfBVAF5F6MEI4dFuebwQrhC/8qzzEgE3u05fUnN8wzt3wF6+Bep5vi8
nMlh95891xapyzXHuTge7thcv0vUOFxwAEsPmLOChYZBrbC4dYUkhWOS5gGbnXL2
RpGBuoEn8y4b0CdziUcSH4zLv0KcgTpg53vRNXxoSxZoe73yfwg4afJALJC95C2+
0FfJIkXEiL1d++WYKpDFSanBVQtFFHu1pGmJTqtjcbN/2iFHovneJ8X44nNXX1HB
fmDciUFL/1mwju9C3p3Oie1Hsub43/icKyFwxx30cRvt5/lB4Hg=
=TJuE
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Done:

https://github.com/QubesOS/qubes-secpack/pull/20

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlsfM0MACgkQ203TvDlQ
MDApoQ/+JIMzJsSNr+vfbDWhFX3HvyV9eZk1yZHbb8EijoZKWR8Ij20nnQ+PloUO
xH/7AwrRUF9Or/3LCaIiSrfA9Qqg26AmkBIx0w6Qnujs9LB2VDs3984B4lEsEvrW
wBlwCnSWwNuvKJZtezcV6WYpkUPrV6x1rNIrzi+82wc0atJy8R4vGcILmWkXHg7N
5IBXNISsI2kjDOfiBD0plR+VKESj7m+kCd/k1JT+r+o+Jblu9kfn0Ae2ASEbaYA0
/QsYsnSMhj9Z64zEtty5RFSqd7DCJ03mBVcFb8PH+Dt9IoX+1xc4qkmZ9/+fylXI
xXpZJxN1Ht2KGZz8Pzzs+sZkkMhyikF8kVN5KhfVo8WP0LF4uTJaxTyCT8LPC1TG
G+V6Y6fhnTuzePHDMBKuLdEkQ0Uu+nTSpsIJraBmEQlSol/E1sHokGMbbxGtYwAD
+B9cDpVQUZ5ZJO4xeNP5y0VmeDveLc/grZtrISXr+bySZ2uOfcrcfTx6P+L/LZOY
h6fyrrD+Dmdmmgqu+BUI6Tzwu5h1saPAEs3dce1646h5iqN1VXEa/PMZ4t8KOYO9
VzG9tXJ2zkdHpqFSoRhlVi53R3bc4ce5zjL5/pnJG+YeHCV8vH7b8xe1vLfddqfk
P81cS31YinHsjHDIuDqIfT0tDf9ruwKi0aaEgr0iyPsrRfTw+f4=
=oa0k
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dear Qubes Community,

We have updated Qubes Security Bulletin (QSB) #40: Information leaks due
to processor speculative store bypass (XSA-263). The text of the main
changes are reproduced below. For the full text, please see the complete
QSB in the qubes-secpack:

View QSB #40 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.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/

View XSA-263 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#263

```

Changelog
==========

2018-05-24: Original QSB published
2018-06-11: Updated and clarified Patching section

Patching
=========

The mitigation for this issue is called called "Speculative Store Bypass
Disable" (SSBD). For Intel processors, SSBD requires both a software
update and a CPU microcode update. For AMD processors, a software update
alone is sufficient; no microcode update is necessary. The packages
described below provide the necessary software updates for SSBD. On
2018-05-23, Intel Corporation announced that microcode updates would 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.

However, as of 2018-06-11, we are not aware of any available microcode
updates that address this issue for Intel processors. This bulletin will

be updated once the Intel microcode updates are available.

There are several important things to note about SSBD:

1. On both Intel and AMD processors, SSBD is globally disabled by
default. If the user wishes to enable SSBD globally, the user must do
so manually with the Xen boot option `spec-ctrl=ssbd=true`. However,
enabling this option carries a performance penalty.

2. We concur with the analysis in XSA-263 that this vulnerability
presents minimal risk to Xen itself and minimal risk of inter-guest
attacks. Therefore, we believe that proper compartmentalization is
sufficient for Qubes users to mitigate this issue without having to
enable SSBD globally.

3. For Intel (but not AMD) processors, SSBD can be enabled locally by

Xen guests without the user having to manually enable it globally.

4. For AMD (but not Intel) processors, SSBD cannot be enabled locally by

Xen guests. The user must manually enable it globally for it to have
any effect at all.

5. The guest kernel determines whether SSBD is automatically enabled for
guests on systems with Intel processors. As of 2018-06-11, the
kernels we currently offer in our repositories do not enable SSBD.

```

This announcement is also available on the Qubes website:

https://www.qubes-os.org/news/2018/06/13/qsb-40-update/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlsh6xoACgkQ203TvDlQ
MDCMQA/+OFS7CQv81KusHaSAehEZCIft3P39F5T4uPX2km5A1jrw+3xULDBeI00a
Ag5ZyFrvqSvMxKYd/F7wYRkLJChhKQcdgYHHV4sCWWGYCvCgcoq+vq8bcfNJFIh0
QWijyfve41zoY3+rayTgSsYUDM7p22ZnCexRJ7eT6ZJR6Dng528ZOb7G177ncD2h
aJbxF+pGgA6nSvwuiJ0D1R3Yv67zYmyHB9GauJV8iTtau/JOMaB77q+9RepWfRJ4
CsQIHEdJHFYSsm0jS7/S8BnaZLEr9r9MtXQJdWgEYG0G2yVjhS9lonvbXEG6456H
vEshUQmKeRy/hiGoUNQ2z/+GiOCSgRShYLjEdnyhsOCBDJROrk2l7FmjsCiiTLa3
JygJthlvVNFveLHvmA5BfVehO1JSkGOzuOsJFEDTZaV9b7jf0DPBUjGYr1K+Sy/c
/FROyKiSt0UFULMu0Pgh7J3xqdPV/6k8HZHrev+PaYLNSg4V/aKfw8bKBhIvjMq6
zPPjPqMwplZU/nwwKdv03O5LGyx2laTpSe0a52THQsnYh5oPKpKybwOF48LsXMiS
rhvqssll77SRBOnSH9bWQ2glFzILHXQExkUHJNJT7chDsSIsJWojbXH1nbeYv6aN
7uDZa2snmvA78iNxgiUgMgnqMrrVTDENKxVp/S5lsHlVlXnd7Mg=
=5Hfr
-----END PGP SIGNATURE-----

[Tai...@gmx.com]

I believe this should be on by default.

I want maximum security, and I have not noticed any performance
difference in for instance VM gaming on my libre firmware AMD system by
enabling full spectre protections.

If someone wants the very slight performance increase they can disable
it - max security should always be the default.