I'm confused. I was under the impression that Qubes OS (after the QSB-043 patches) automatically disables hyper-threading for you such that you don't have to know anything, do anything, or read any past QSBs.
As QSB-043 explains, you would have had to follow special instructions to re-enable hyper-threading in Qubes 3.2, and no such instructions were provided for re-enabling it in Qubes 4.0 (since, as the QSB explains, it's never safe in that release), so I don't even know how'd you do it in that release.
But perhaps I'm mistaken or misunderstanding the question.
Ah, a thought just occurred to me. As QSB-043 states, "A CPU
microcode update is required to take advantage of [these patches]." Perhaps the problem is that certain CPUs never received the required microcode updates, which explains why some users seem to have CPUs with hyper-threading enabled even though it's been years since QSB-043. Could that be it?
Of course, it's generally also possible to disable hyper-threading in one's BIOS/EFI settings, regardless of whether it's disabled in Xen, and this does seem like a prudent measure given the risks associated with having it enabled and given the fact that Xen-level disablement appears to be hit-or-miss. So, perhaps your suggestion about detecting and warning about active hyper-threading might be a good idea after all. Please feel free to open an enhancement request.
There are (at least) two ways to disable hyper-threading:
1. In system BIOS (if there is such option)
2. In software - by disabling every second thread of each core.
The QSB-043 uses the second method. It has is drawbacks, as the logic to
bring up and down CPUs is quite complex. And yes, there are known
issues[1] affecting suspend. Disabling hyper-threading in BIOS, prevents
Xen from starting those secondary threads at all, and so it doesn't need
to bring them down.
>>>> But shouldn't hyperthreading have already been disabled ever since
>>>> QSB-043?
>>>>
>>>> QSB #43: L1 Terminal Fault speculative side channel (XSA-273) | Qubes OS
>>>>
>>> I admit that I missed that one as well. Shame on me. Is there some way
>>> to detect active hyperthreading on boot && print out a big red
warning ?
>>>
>>> That seems a reasonable measure, especially for new-comers how cannot
>>> reasonably be asked to read all old QSB's first
>>>
> [ Markek ]
> There are (at least) two ways to disable hyper-threading:
> 1. In system BIOS (if there is such option)
> 2. In software - by disabling every second thread of each core.
>
> The QSB-043 uses the second method. It has is drawbacks, as the logic to
> bring up and down CPUs is quite complex. And yes, there are known
> issues[1] affecting suspend. Disabling hyper-threading in BIOS, prevents
> Xen from starting those secondary threads at all, and so it doesn't need
> to bring them down.
>
> [1]
Thank you Marek. I only now disabled it in BIOS (my fault), and my
question was that software could point a warning to the user in case of
software disabling. I would have done it much faster then
>>> Marek Marczykowski-Górecki 31.08.2021, 02:52 >>>
> >
> > > > Kind of answering my own question, but disabling hyperthreading
> > > > happened to
> > > > be a workaround for the resume from suspend issue.
> > >
> > > But shouldn't hyperthreading have already been disabled ever since
> > > QSB-043?
> > >
> > > QSB #43: L1 Terminal Fault speculative side channel (XSA-273) | Qubes OS
> > >
> > I admit that I missed that one as well. Shame on me. Is there some way
> > to detect active hyperthreading on boot && print out a big red warning ?
> >
> > That seems a reasonable measure, especially for new-comers how cannot
> > reasonably be asked to read all old QSB's first
> >
>
> I'm confused. I was under the impression that Qubes OS (after the QSB-043
> patches) automatically disables hyper-threading for you such that you don't
> have to know anything, do anything, or read any past QSBs.
>
> As QSB-043 explains, you would have had to follow special instructions to
> re-enable hyper-threading in Qubes 3.2, and no such instructions were
> provided for re-enabling it in Qubes 4.0 (since, as the QSB explains, it's
> never safe in that release), so I don't even know how'd you do it in that
> release.
>
> But perhaps I'm mistaken or misunderstanding the question.
There are (at least) two ways to disable hyper-threading:
1. In system BIOS (if there is such option)
2. In software - by disabling every second thread of each core.
The QSB-043 uses the second method. It has is drawbacks, as the logic to
bring up and down CPUs is quite complex. And yes, there are known
issues[1] affecting suspend. Disabling hyper-threading in BIOS, prevents
Xen from starting those secondary threads at all, and so it doesn't need
to bring them down.
Can't it be disabled via kernel (grub) command line, too?
This is exactly "the second method" above.
Also rumours say you can even disable it at runtime (and the threads will be
migrated to other threads before).
Occasionally some tools seem to have problems with HT being disabled (like
"expecting 8 CPUS, but only found 4").
This is kind of similar issue as the one discussed here. That's why it's
better to disable HT in BIOS - to not show those 8 CPUs at all. But from
the OS level, we don't have other choice, and we prefer a secure
default - that's why we disable HT at Xen level, to provide safer option
regardless of what user has set in the BIOS.
PS Please don't top-post. And keep the mailing list in CC.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
Couldn't xen/qubes set a boot warning to users that rely only on (2) to
encourage more strongly to disable by BIOS (1)? That seems a logic
measure to me. best, Bernhard
