Another round of speculative-execution vulnerabilities [LWN.net]

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 3:25 UTC (Thu) by wtarreau (subscriber, #51152)
Parent article: Another round of speculative-execution vulnerabilities

As usual, what's really annoying is that we're having to make a compromise between performance and security because it was decided 50 years ago that it would make sense to cut costs by mixing multiple independent workloads on the same machine in a way that respects confidentiality and security so much that these would believe they're using the same machine. By then it was time-shared systems, and caches were not really a thing.

Of course that was a lie or at least a misconception that would conflict with all hopes for optimizations later. Caches are incompatible with confidentiality, yet they're absolutely mandatory with nowadays CPU frequencies. Busses are too small for the large number of cores and cause arbitration allowing to infer other cores' activities. The wide execution units in our CPUs are mostly idle, making SMT really useful but disclosing even more fine-grained activities, to the point that no more progress is being made in that direction (what CPU vendor does 4-SMT or 8-SMT, maybe only IBM's Power ?).

Meanwhile, the vast majority of us are using a laptop that we don't share with anyone and we all run commands using "sudo", most of the type not even having to re-type a password, because it's *our* machine, and we don't care about the loss of confidentiality there. And the huge number of users of cloud-based hosting shows that tiny dedicated systems definitely have a use case, so full machines of different sizes could be sold to customers, with zero sharing on them either.

Browsers are the only enemies on local machines and they could be placed into an isolation sandbox that runs in real-time mode and flushes caches and TLBs before being switched in. They would not be that much slower nor heavier anyway, they're already the most horrible piece of software ever created by humanity: software that takes gigs of RAM to start and do not even print "hello world" by default, doing nothing at all until connected to a site, so we could definitely afford to see them even slower.

With such mostly dedicated hardware approach, we could get back to using our *own* hardware at full speed and the way we want. We've entered an era where computers are getting slower over time only due to all mitigations for conceptual security trouble that most of us do not care about and that result in sacrificing performance.

to post comments

Multithread SMT

Posted Aug 10, 2023 5:19 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (2 responses)

Answering your question about high density SMT: Sun's Niagara T1 chip, introduced in 2006, had 4-way SMT. Its successor T2 bumped to 8-way SMT quickly. The line of CPUs ended with M8 in 2017 (still 8-way SMT).

Multithread SMT

Posted Aug 10, 2023 5:56 UTC (Thu) by dxin (guest, #136611) [Link] (1 responses)

Those are not SMT because the thread doesn't run simultaneously, but scheduled round-robin.
Technically it's "fine-grained multi-threading", like most GPUs. The switching threads each cycle in round-robin style makes the wall-time of each cycle much longer, from individual thread's point of view, so pipeline delays doesn't exist.

Multithread SMT

Posted Aug 10, 2023 18:02 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

Yeah so when you think you're having a 1.4 GHz CPU distributing available execution ports to waiting threads and where stalls are long, in fact you're really having eight 175 MHz processors working individually with stalls during the same in nanoseconds but not in cycles. It probably achieves higher total performance levels per transistor count but not in terms of peak performance. I better understand now why I was told gzip was ultra-slow on such machines.