XSA-273 - Impact on Qubes?

117 views
Skip to first unread message

Rob Fisher

unread,
Aug 25, 2018, 4:46:40 PM8/25/18
to qubes...@googlegroups.com
I'm wondering when we can expect information on the impact of XSA-273
(1) on Qubes R4? I can't help but notice it's absence from the Qubes
XSA-tracker page (2).

Some OS Vendors have implemented kernel patches in an attempt to
mitigate these vulnerabilities, but as of yet I haven't seen any such
patches to the qubes-kernel-vm or the Hypervisor.

In the common case that microcode updates aren't possible via a BIOS
update (HW vendor not made them available), and disabling
hyper-threadding is not possible in the BIOS - what are the best options
for a Qubes user right now?

Thanks,
Rob.

Links:
(1) - https://xenbits.xen.org/xsa/advisory-273.html
(2) - https://www.qubes-os.org/security/xsa/



Rusty Bird

unread,
Aug 25, 2018, 5:51:06 PM8/25/18
to Rob Fisher, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rob Fisher:
> I'm wondering when we can expect information on the impact of XSA-273 (1) on
> Qubes R4?

I'd guess early next month:
https://groups.google.com/d/msg/qubes-users/Isn_hko7tQs/PcqIuUleEQAJ

> what are the best options for a Qubes user right now?

- - Add smt=off as a Xen boot parameter (which disables hyperthreading)
to make the attack harder?
- - If you're worried that some VM might want to steal data from another,
try not to run both at the same time
- - Hole up, have a nice cup of offline and wait for all this to blow over

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

iQJ8BAEBCgBmBQJbgc8qXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfr38P/1KtCRK5qEvTcCTVLVbwYZHj
k63iIhA6n7wzRaV8oaOq7YrRzFryNoikeU2eqYe+T6Rwuw3hBE842pN+rABTJ7BS
Lb9UdUaC14y481Ad0uMxR4MvE+zKx6Ok4XuHTEwpZXDPw5URqNLNwp0+3ll1MXj2
lkRFqb9/IuwdR491YpQQAfjkD/EfHkMvd+TJAGowkUOBFno9605x8fLYRCMw0ZTL
U0c0amlRSeM57bhqPR0fMtc3rfFT/w+wZS1QHoq881qXfx9E29HjjOnTI3E1EN0I
MRbh222HsjScvl2O7OPbDUzIQW6uC/rZPYKrekMNYfK0c+sfUCehLE/RUNp3qdUf
8dEpVL5uBFIL4wBSN4g9GIFa2wmHvnrJ90v7U7pJ61iWoA1vaKEARlECZU7u3+EH
rOXSdb0+o7RtOItY/Lb8e/qfZxfScvvCb2n7dz1fqFFB2dXd7pIixMT7cERPbvsR
AGiqs6hkmHKKuw38xeKhhl5yVQQhIa77WgAVVHQ0mXu0sqGOWPLA30kwp4Tioqvh
HgKl9OtEUlVfYDj9HOuRdKM7Ns8rxLyDuYd6ENDgkMIC8QCEmE6blmnkJybR2mBo
knEQ0vgRQ++R8eG0b+3u7a97Up94D6FhDGA5b042a0wOGgBEG7e9/sefwCOskXGL
pnSyzaTOZPeHlStNxxhf
=bImI
-----END PGP SIGNATURE-----

awokd

unread,
Aug 25, 2018, 6:01:18 PM8/25/18
to Rob Fisher, qubes...@googlegroups.com
On Sat, August 25, 2018 9:50 pm, Rusty Bird wrote:
> Rob Fisher:

>> what are the best options for a Qubes user right now?
>
> - - Add smt=off as a Xen boot parameter (which disables hyperthreading)
> to make the attack harder? - - If you're worried that some VM might want to
> steal data from another, try not to run both at the same time - - Hole up,
> have a nice cup of offline and wait for all this to blow over

Get Qubes running on non-x86 architectures less prone to vulnerabilities!


Rusty Bird

unread,
Aug 25, 2018, 6:30:27 PM8/25/18
to aw...@danwin1210.me, Rob Fisher, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

'awokd' via qubes-users:
> > Rob Fisher:
> >> what are the best options for a Qubes user right now?
^^^^^^^^^
> Get Qubes running on non-x86 architectures less prone to
> vulnerabilities!

Don't hold your breath ;)

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

iQJ8BAEBCgBmBQJbgdhiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfHXsP/Avjd7ZuwBIx1wDg90aoq6xE
lNHxEMhly2z8KXfNzLOg/H+3yF7gg+DeKo9wU0gAKm2O1grxt9TWgvju3Wje1Wdu
gvEIo6Ew/oK/UFl5oQLFR/5F+zCjMaB7SAqf1hKZsJhLm82PrF8kXtwm1+y/CZTE
IB7ci8x0lB+2p0571uMuu1HMgTTHn+e/UfKbANbHrgBClYgsBgasZD6wy99gOKOY
f4pcSfd3wQ3lmg5D8U44Pg5NMnGHFnhsu1prqbrsYFSwzLxkhWD6mODvYZ2G8BbM
+F/49iIafiGrhOrLGF+M/jnH/rIYT48IZEM90IFoS55WbeFZdvjID7inqFBDUbc2
EyyxuPUXku80NTuVlJP9t4/tinH7K+IfK5VV9F3jjU4tMO8kgdKJ+LMDkLGaKUoW
Qy22Lm2EWDNXBFMopxwcHeIp19RbIYKEcjMrknI6XT2LPt4Dfg/Ibd8F5k95/SC4
LFAxA4BJJXyJQdaIdit2t//38h0N7irmP6bDpihNjW0zVgAZwUNd/u1gwtLYS5z4
RHwfIdHnHv1ZG9mV3noMiVJLDgml0RTkuyCz+dEmYe6X5MhChdsmDqcLm2/xC5cW
lOwULl6dFbYVudOfi0yJnrXHSSDGINLYweSBJEuMC4nSfmab5vKr4Qvk3arJIw1i
ebXtbANVEiih6ZkBuW2a
=H494
-----END PGP SIGNATURE-----

Ivan Mitev

unread,
Aug 26, 2018, 4:14:57 AM8/26/18
to qubes...@googlegroups.com


On 08/26/2018 12:50 AM, Rusty Bird wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Rob Fisher:
>> I'm wondering when we can expect information on the impact of XSA-273 (1) on
>> Qubes R4?
>
> I'd guess early next month:
> https://groups.google.com/d/msg/qubes-users/Isn_hko7tQs/PcqIuUleEQAJ
>
>> what are the best options for a Qubes user right now?
>
> - - Add smt=off as a Xen boot parameter (which disables hyperthreading)

FWIW I was wondering how to turn off HT last week on a thinkpad 450s
(i7, 2 cores) which doesn't have a "disable HT" bios option. I had
overlooked the smt= boot option and tried maxcpus=2 but this left me
with 1 core/2 threads instead of 2 cores / no HT.

smt=off doesn't seem to work though:

$ xl dmesg | grep smt
(XEN) Command line: [...] smt=off

$ xl info | grep thread
threads_per_core : 2

$ xenpm get-cpu-topology
shows CPU0, CPU1, CPU2, CPU3

$ xl vcpu-list
shows that CPUs # 0-3 are randomly assigned to VCPUs # 0-3


Does smt=off work for you ?


One possible workaround would be to pin CPUs to VMs. Another one would
be to remove CPU1 and CPU3 from the cpu pool, like so:

$ xl cpupool-cpu-remove Pool-0 1
$ xl cpupool-cpu-remove Pool-0 3

but:
- I have no idea if this is identical to disabling HT
- 'xl vcpu-list' shows that only CPU0 and CPU2 are used, but VMs still
use 4 VCPUs - even VMs started after removing the CPUs - which doesn't
seem optimal wrt context switching overhead.

Rusty Bird

unread,
Aug 26, 2018, 8:35:37 AM8/26/18
to Ivan Mitev, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ivan Mitev:
> On 08/26/2018 12:50 AM, Rusty Bird wrote:
> > Rob Fisher:
> >> what are the best options for a Qubes user right now?
> >
> > - - Add smt=off as a Xen boot parameter (which disables hyperthreading)
>
> smt=off doesn't seem to work though:
>
> $ xl dmesg | grep smt
> (XEN) Command line: [...] smt=off
>
> $ xl info | grep thread
> threads_per_core : 2

Shit, you're right! Xen commit f049cd67a99bcf773aa4fceeedd5d1de17b2a8eb
("x86: command line option to avoid use of secondary hyper-threads")
was added to the 4.8 branches a few days _after_ the 4.8.4 release.
I should have checked better...

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

iQJ8BAEBCgBmBQJbgpwfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfgqsP/1xUuJNoRlbB1w9TAOL08Ei4
3Md4lfJ+uxbgPorrEw1Z9dyq1VX9o/u/zapZjziEYBCSSSp7PSr8iECJ66TJlZXV
+tS30QAI4u/t6sf6wX7KPXVEaWE2FmlU7o/ID/mCaXPTUtTxDZewe3Q35kcKrNcp
+pnGxOEM/DV3EQ6noYvK30sOWUxLwBG9XH/DzUCLVTUn0gjPAiEMgna39US4e9Cu
YB5EK+cvSwnCBc3xawcLRHfMV3XnjVw2R3zN8VjHrm0xmbqUT9kXBjxBUX9xnd1v
zrnlHsO8frZ1mx4F8GomdoYSK2qrnJjkYuvuwJGZexqBGu/N3G5FkWqSbRj0a1mj
DN/i5PeQNQ+qnh42tpKjAbZBr2Zyb0kZGhZl30XTZJNfdlxdoShFUoIRExE6EwiT
7JCAcfxoF32YylsTLeklRNK/OODB6ihPkVeds/DNencM/ALINdJOYnSnHv1EsSl1
JcLAZ2vHHAhAn39kimHIQchPTMU+sBB/g3LSlHHZovXmduRhQw8TsW2BD0rF38G8
84iLAeJ8AIHQUFl5cWxDYFJGbizczfSzymPF9bVaWFVreJXqdFAYkP4sIku05OYE
qP6P+u05dxN2eH/xaKAXgHV8LiRWtcEP+Vrj7kXphJG6MtmpqTPWcNMgtjP9sxsa
miFJi6nxt0dqqX9SFvqa
=39ak
-----END PGP SIGNATURE-----

Andrew David Wong

unread,
Sep 1, 2018, 11:41:43 PM9/1/18
to Rob Fisher, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2018-08-25 16:50, Rusty Bird wrote:
> Rob Fisher:
>> I'm wondering when we can expect information on the impact of XSA-273 (1) on
>> Qubes R4?
>
> I'd guess early next month:
> https://groups.google.com/d/msg/qubes-users/Isn_hko7tQs/PcqIuUleEQAJ
>

We have now published QSB #43: L1 Terminal Fault speculative side
channel (XSA-273).

https://www.qubes-os.org/news/2018/09/02/qsb-43/

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

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

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAluLW+AACgkQ203TvDlQ
MDCCTBAAxhupcI68/IIuEKKCV8uoYM9Q9DKUxW70b99nh+HgFuVpbqMZJ87PeH4B
d+z9rc7DQkPCoiW4hycCChOPyR6k7ZwPpPvD5FbuCXO63LboCD8lIoXSDKL4h6YV
C7DPmjFx8HQPqF7jP30erbHegc7lr13t7tSAdS8ITVXfEV06JWrCilMRFTlwT0Ov
5jlpp9JHyQcgkITxuCokdPISJJk3F5GLDQ4YofU8i1FyeT8UvEHIStZhAT6WNMm5
laGq/QdYcw1Ma9yCbXZ0ElJD9VWEysEbxn1t70ulqQHYJNQrwM0uRlO+Jxd5JdgI
w7HpEo1IPFuT28mh4x2NpQ7gTFMsN3hbgcMjlglBbYyPXZ6QwdOLOPp73f0pAAlC
WBHhmFozOh2zb9XUGkj9yziDvLHyEIFckn+Z1u9CBITTgEMW1nvfzDZvSTwb5be9
L9EouciQ80xUWerp8AFx1OwnKk5teZrk1PxPY0CSIsNeVxhlgsBHSPxOfbbtkWOb
iwxkrndspP5zqSDJmPMl2T/0pdQOh2fGx6T2hPluWb7/Xep02Jz9J+Ra+ZZ7YWRG
p+PJWmPhrIagQ34AEBRPBrJjJ0XplBjBRBv850Goioz6e3Y++hKAGqCCqPYxVGeY
T6mUTj6Ksw/Kvh8+l8roCnKj/Z7V66Ikvw6WdYNQyTMAR32YSOQ=
=LIKN
-----END PGP SIGNATURE-----

Reply all
Reply to author
Forward
0 new messages