Is not it better just to disable Javascript instead of cutting your CPU performance?
Disable SMT/Hyperthreading in all Intel BIOSes
61–70 of 159 posts
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#62FTA >>> 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 ?
Intel cooperates with organizations that obey embargoes and don't badmouth their partners in public, like Red Hat, Canonical, and probably the Linux Foundation. Intel does not cooperate with OpenBSD.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#63So, realistically, how much performance did your average OpenBSD server just lose from following this mitigation?
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#64Earlier 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.
Possibly, but it's not uncommon to refer to x86 and x64 machines as intel architecture machines or as intel machines.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#65I've long felt that there's something less than half-baked about the multi CPU architecture we're currently using. The hacky contortions HFT coders have come up with to avoid things like False Sharing strike me as a big red flag. https://mechanical-sympathy.blogspot.com/2011/07/false-shari... How about an architecture more like Erlang's, where you have independent processes with their own CPU core, where each has the…
No networking can touch silicon-level interconnect between cores or within cores on a single chip, at least for latency. Erlang's model of computation doesn't have much to say about physical implementation, and multi-socket/distributed systems are not perfomant for latency-critical user applications. For servers and high performance computing sure, I guess in theory we could use tons of simple single-core chips, but…
No networking can touch silicon-level interconnect between cores or within cores on a single chip
So how about silicon-level interconnect that looks like networking? As it is now, it seems almost designed to elicit badly non-optimal code.
multi-socket/distributed systems are not perfomant for latency-critical user applications...fabrication costs and energy efficiency would be significantly worsened.
I think there would be tremendous benefits if we started designing multi-socket/distributed system that could perform in those situations. For one thing, Intel has currently painted itself into a corner with regards to large wafer yields, and AMD is kicking their butts by combining smaller dies.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#66I've long felt that there's something less than half-baked about the multi CPU architecture we're currently using. The hacky contortions HFT coders have come up with to avoid things like False Sharing strike me as a big red flag. https://mechanical-sympathy.blogspot.com/2011/07/false-shari... How about an architecture more like Erlang's, where you have independent processes with their own CPU core, where each has the…
That's like the Cell processor. For every year that you program for Cell you need at least two years of therapy.
If you're going to change the substrate or paradigm, then you need to do a dynamite job of supporting your users. Sony did not do that.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#67Earlier quoted context omitted.
You can give both hyperthreads in a physical core to the same tenant, no? Scheduling different VMs to run on the same hyperthreaded core at once seems like it can't be good for either VM's performance, even if there were no security concerns. Hyperthreading is much more useful for running multiple threads of the same app, accessing similar instruction caches etc. (There's also a question of safety within the VM, but…
Other things require sandboxed multitenancy than just full-on VMs. Database queries against a "scale-free" database like BigQuery/Dynamo, for example, where two queries from different tenants might actually be touching the same data, with much the same operations, and therefore you'd (naively) want to schedule them onto the same CPU for cache-locality benefits.
Okay, so many tennants are on the same BigQuery/Dynamo machine sharing cores.
If the API is "SQLish queries", I have a hard time believing you are going to be able to trigger these kind of attacks. You need a tight loop of carefully constructed code to flip them, no?
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#68Earlier quoted context omitted.
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.
Possibly, but it's not uncommon to refer to x86 and x64 machines as intel architecture machines or as intel machines.
Due to architectural differences, AMD CPUs are immune or nearly immune to some of the speculative execution attacks (though not all of them). For example, AMDs branch predictor uses the full address and so is not vulnerable to branch predictor poisoning in the same way as Intel.
The major win (whether AMD intended it or not) is that AMD cpus don't speculate loads until page permissions have been verified. Intel fires off the speculation immediately. That is one of the primary side channels underlying many of the attacks.
Intel has been actively muddying the waters with FUD to get people to think AMD is just as vulnerable. Please don’t buy into that. Intel is far more exposed. The subsequent slowdowns are more severe.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#69Is not it better just to disable Javascript instead of cutting your CPU performance?
Some of us like using websites.
Re: Disable SMT/Hyperthreading in all Intel BIOSes
#70So, 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.