Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.
Disable SMT/Hyperthreading in all Intel BIOSes
71–80 of 159 posts
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#72Is not it better just to disable Javascript instead of cutting your CPU performance?
This affects more than just JS.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#73Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.
Probably in most cases. Vmware have disclaimers in the mitigation options that preclude turning off HT, meaning, use at your own risk. [1] I am still waiting on a comment from Linode [2] Openstack have some knobs you can adjust, but it really depends on your workloads and what risk you are willing to accept. [3] AWS have their own custom hypervisor and are said to have worked around the issue. [4] Amazon had info on…
AWS is able to get custom Intel Processors due to their size (c5 instances have a custom Intel processor).
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#74Earlier quoted context omitted.
Where did you get that impression?
I believe it may be because the email only mentioned Intel explicitly and had a "I won't be buying Intel in future" (paraphrased) comment. However, I personally wouldn't assume that AMDs HT implementation doesn't have similar issues.
HT is also disabled on AMD, for both CMT (FPU-shared) & SMT implementations.
https://marc.info/?l=openbsd-cvs&m=152954666609919&w=2
While no AMD issues are known at present. OpenBSD will have it disabled by default. How about other operating systems, I wonder?
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#75FTA >>> We are having to do research by reading other operating systems. Si Intel cooperates with business partners like apple/windows and not with open source. Does it mean that Apple and Windows can claim to be more secure because they have access to the information needed to fix Intel's issues ?
A lot of these bugs seems to be found by the Google teams and since they are heavy Linux users, I'm sure in many cases they have a solution for Linux before Apple or Microsoft does.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#76> SMT is fundamentally broken because it shares resources between the two cpu instances and those shared resources lack security differentiators. I thought the root of one of the Foreshadow problems was that caches are shared across cores , and therefore even with hyperthreading disabled, you still gain information about a process on another core. Am I misinterpreting it? It does seem like the paranoid thing to do is…
Foreshadow is caused by the L1 cache which is not shared across cores. It may be only a matter of time before L3 attacks are discovered but I don't know of any today.
Oh - I forgot the L1 cache isn't shared across cores. That makes sense, thanks.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#77I would love to but how in the world do I do this when I'm using Windows and Lenovo doesn't give me an option in the BIOS?
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#78For anyone (understandably) confused about the attacks and mitigations related to L1TF, I've found the linux kernel documentation on the mitigations[0] to be a great resource.
One interesting thing is that to mitigate L1TF hyperthreads only need to be disabled if you are running VMs, the userspace mitigations are effective regardless of HT status. However, there's a catch, you can leave hyperthreading enabled if you disable the Extended/Nested Page Table virtualization feature. However it is noted that this will result in a significant performance impact.
[0] https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html
However this does not mean that HT with VMs is totally secure, as there may be more vulnerabilities relating to HT yet to be disclosed/released as alluded to by Theo. (For context, see the previous discussion [1] around the Lazy FPU switching vulnerability where Theo made the decision to enable mitigations in OpenBSD[2] prior to the public disclosure of the bug based (Theo/OpenBSD was _not_ party to the embargo))
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#79So, realistically, how much performance did your average OpenBSD server just lose from following this mitigation?
I don't think you can answer that with a single question. It depends on how CPU-intensive the work that server was handling was. I think, though, that if you'd be particularly willing to knowingly allow these kinds of vulnerabilities in exchange for some performance, OpenBSD probably isn't a good fit for you in the first place.
> I think, though, that if you'd be particularly willing to knowingly allow these kinds of vulnerabilities in exchange for some performance, OpenBSD probably isn't a good fit for you in the first place.
I disagree. You may have consciously picked OpenBSD because you believe that security is critical for your business. But if you're renting a server (shared or otherwise) to handle your website and paid for X number of cores, RAM, etc., you establish a baseline for what kind of performance you get out of that setup. If that performance suddenly nosedives 20% overnight because the new mitigation patches turned off hyperthreading, the rig you paid for may have gone from sustainably handling your workload to buckling, causing service degradation, outages, etc. I imagine it could be a real problem. It's not so much "Oh, we can't handle that performance hit, we'll run without it" so much as wanting to know the extent of the damage before they take the plunge.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#80Will be interesting to see what Apple does about this in their next software update. I can’t imagine many people will be happy if the next software update forcibly disables hyper threading. (For those who aren’t familiar with Apple devices, Apple don’t expose settings like this to a user, which are usually available in the BIOS on a PC)
Will the loss of HT have apparent consequences on most Intel-based Apple hardware? Very few of them are servers under constant multithreaded load, throughput-oriented. I suppose almost all Macbooks and most Mac Pros will not visibly slow down.