Hyperthreading on or off?

[jrsm...@gmail.com]

Looking for guidance on best practices for Qubes configuration: given the vulnerabilities that have been reported with Hyperthreading, it would seem to be a no-brainer that it should be disabled, but I don’t see anyone coming right out and saying so. Curious what this group thinks.

[awokd]

jrsm...@gmail.com wrote on 4/3/19 9:54 PM:

> Looking for guidance on best practices for Qubes configuration: given the vulnerabilities that have been reported with Hyperthreading, it would seem to be a no-brainer that it should be disabled, but I don’t see anyone coming right out and saying so. Curious what this group thinks.
>

Off. Qubes defaults to this now by including "smt=off" in the Xen boot
options.

[donoban]

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

If you mean that disabling it could be too drastic solution or the
risk in real-world conditions is too low, you could be right.

I read a paper about this where the attacker needed a lot of time
while other VM was running an infinite loop using a SSL key (no real
world behavior). So probably, in real conditions this is very very
hard to exploit.

On the other side, Qubes security model and sense of existence is to
guarantee that some compromised VM can not compromise other VMs or the
whole system so just disabling could be reasonable too.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlylygEACgkQFBMQ2OPt
CKV8kA/5ASGEuRBcUtCKgDiYtSgf3CwQ/VSKJkZiAd9AEbfmOhT+vIjAH3xRvZbU
fdpFr2GkDVrJX4BQAHnE20EtolNrPM4Grxp7CQrag1+z0YXdVyKE9TfuNNcVthWy
LURfN3jkoDPlV7Dfn4yVjhSVWx+BMvGQVGvusuWSD3aWhm6aC5sX4u1pyCrLgvLr
FQQk65mwjUklH+0mRwZGu4f4EUkRpmPleSmj22djV2yQ6RjuuRmQoDvrePvjrAZr
Nqf0CCccp/DXQMhlEpFvVgwgLNIHARrfX5CX21uH/obiVu/+zolPxyoMg4JCe3Np
auE31kK/8r0KUKvUGYX06VUs7cl/CGKbz1Y8VREezvebbXUIC4ORzumu2VOApNZj
GKHU4BAE9UEQW+5QO5rYbQiu9AaEUDr0BXBtQD8/HBwQV9H8YWMXBuM1cQpbdMMo
QQKzFB8CI8HQlQrCXmMIt03wDwDIH/kiPG0v5WZjk4tyfjvjbIJjX7NJ6/Q8JUet
yEQJEZWKLauoF+wRCUgcmg+HpYklswr6Qltcj4SLYc4x8v2LB/eyGwKBU3f9pJ9J
5V/dLIemzCHLEpUdY9GNuNxAXLdLk70FSCNLGWI3JJyRBkKpv/e5i+pUgsKzFx33
dFCrnh1FOmWgPIauAYA/mRAyvsnbEQjFJ+/Jb0hs5VTVFZETh9g=
=Ycgi
-----END PGP SIGNATURE-----

[brenda...@gmail.com]

On Thursday, April 4, 2019 at 5:10:39 AM UTC-4, donoban wrote:

> On 4/3/19 11:54 PM, jr...@gmail.com wrote:
> > Looking for guidance on best practices for Qubes configuration:
> > given the vulnerabilities that have been reported with
> > Hyperthreading, it would seem to be a no-brainer that it should be
> > disabled, but I don’t see anyone coming right out and saying so.
> > Curious what this group thinks.
>
> If you mean that disabling it could be too drastic solution or the
> risk in real-world conditions is too low, you could be right.
>
> I read a paper about this where the attacker needed a lot of time
> while other VM was running an infinite loop using a SSL key (no real
> world behavior). So probably, in real conditions this is very very
> hard to exploit.
>
> On the other side, Qubes security model and sense of existence is to
> guarantee that some compromised VM can not compromise other VMs or the
> whole system so just disabling could be reasonable too.

Makes sense to me: Qubes policy is to enforce safer defaults. User can modify, at their own risk.

Layperson's thought: perhaps there could be a CPU allocation strategy in Xen that allocates cores instead of logical CPUs? That may mitigate the security issue if the workload would benefit from Hyperthreading (aka SMT).

Whether this is significantly safer than the default logical CPU allocation w/ hyperthreading really depends upon the CPU cache strategies in effect, perhaps. E.g. contemporary Intel CPUs (packages?) have three or more levels of cache and some interesting cache topologies including cross-core caches...

Some support software-selectable caching strategies as well for parts of the cache.

Brendan

[Foppe de Haan]

would that work, without static allocation? I'd assume Xen regulates time slices, so that there's always a chance that the cache will still contain stuff from activity generated in/by another VM. I guess you could flush that every time, but I'm sure that generates more than a little overhead.