Hyperthreading is turned off by Qubes

[trueriver]

Running a new install of Qubes r4.0.1 on an ultrabook based on the m5-6Y54 processor / SOC. Xentop shows it as having only 2 cores.

When the same machine boots into Debian on bare metal, with no BIOS changes, top shows it as having four.

The Intel spec is 2 cores running 4 threads, so the difference is clearly about hyperthreading.

Is it possible to get Xen in Qubes to enable hyperthreading?

And if so how?

Are there any obvs pitfalls or technical issues to explain why Xen turns it off?

[Ilpo Järvinen]

On Fri, 27 Dec 2019, trueriver wrote:

> Running a new install of Qubes r4.0.1 on an ultrabook based on the
> m5-6Y54 processor / SOC. Xentop shows it as having only 2 cores.
>
> When the same machine boots into Debian on bare metal, with no BIOS
> changes, top shows it as having four.
>
> The Intel spec is 2 cores running 4 threads, so the difference is
> clearly about hyperthreading.
>
> Is it possible to get Xen in Qubes to enable hyperthreading?
>
> And if so how?

There's smt xen command-line parameter.

> Are there any obvs pitfalls or technical issues to explain why Xen turns
> it off?

Yes, HT is turned off intentionally for security purposes. Some of the
Intel CPU vulnerabilities demonstrated within the recent years depend on
the side channels within the resources shared by the threads of the same
physical core. Thus it's advisable to not enable it.


--
i.

[Sandy Harris]

'Ilpo Järvinen' via qubes-users <qubes...@googlegroups.com> wrote:

> > Is it possible to get Xen in Qubes to enable hyperthreading?

...

> > Are there any obvs pitfalls or technical issues to explain why Xen turns
> > it off?
>
> Yes, HT is turned off intentionally for security purposes. Some of the
> Intel CPU vulnerabilities demonstrated within the recent years depend on
> the side channels within the resources shared by the threads of the same
> physical core. Thus it's advisable to not enable it.

Does that mean Intel's i7-9700 series of CPUs would be a near-ideal
choice for a high-end Qubes desktop? Here's one of several available:
https://ark.intel.com/content/www/us/en/ark/products/191792/intel-core-i7-9700-processor-12m-cache-up-to-4-70-ghz.html

They're all 8 cores, no hyperthreading so 8 threads (enough?). This
one runs at 3.0 Ghz, turbo 4.7, uses 65W. I've seen reports they can
be overclocked to 5 GHz with air cooling. If I build one I'll use
water cooling & see what I can get away with.

[trueriver]

> HT is turned off intentionally for security purposes. Some of the
Intel CPU vulnerabilities demonstrated within the recent years depend on
the side channels within the resources shared by the threads of the same
physical core. Thus it's advisable to not enable it

Thanks for that explanation - yes that's sensible.

With the option set to allow HT, I'm now wondering if there is a Xen setting to force Xen to allocate both virtual cores in the same physical core together?

That would mean you'd always get an even number of virtual cores, they would always be "core buddies", and this it's only that VMs own code that can attempt those exploits. That would give almost the same level of security but allow the extra performance.

Or am I missing some nasty potential exploit?

[Ilpo Järvinen]

On Sun, 29 Dec 2019, trueriver wrote:

> > HT is turned off intentionally for security purposes. Some of the
> Intel CPU vulnerabilities demonstrated within the recent years depend on
> the side channels within the resources shared by the threads of the same
> physical core. Thus it's advisable to not enable it
>
> Thanks for that explanation - yes that's sensible.
>
> With the option set to allow HT, I'm now wondering if there is a Xen
> setting to force Xen to allocate both virtual cores in the same physical
> core together?

I don't know but I wouldn't expect one to appear in an old xen.
Given R4.0 is 4.8 so if such feature is there, most likely that's not
available until some future Qubes version.

> That would mean you'd always get an even number of virtual cores, they
> would always be "core buddies", and this it's only that VMs own code
> that can attempt those exploits. That would give almost the same level
> of security but allow the extra performance.
>
> Or am I missing some nasty potential exploit?

--
i.

[trueriver]

Thanks Ilpo. I had half guessed the same.

[trueriver]

>> I'm now wondering if there is a Xen
>> setting to force Xen to allocate both virtual cores in the same physical
>> core together?

> I don't know but I wouldn't expect one to appear in an old xen.
> Given R4.0 is 4.8 so if such feature is there, most likely that's not
available until some future Qubes version.

Turns out that's exactly so. The Xen wizards were working on it August 2019, and it's now in a testing or unstable build, so it will be a while before it gets into a stable Xen release, and then longer till Qubes adopts it.

https://patchwork.kernel.org/cover/11086677/

The parameter is sched-gran=core (or socket or cpu) with the default bring CPU.

The version of Xen currently used by Qubes 4.0.1 accepts the parameter without giving an error, but also without complying.