Hacker News Reader

Comment by justaguy88 | Hacker News Reader

Why are they still releasing new CPUs with these issues?

Cheaper to keep the mitigations in place than to design around the side channel. Rearchitechting an entire CPU seems like it would be a boondoggle. Especially since the well of side channels runs infinity deep unless you're back to single core, single thread CPUs. As soon as they 'fix' this side channel, another will be found. It's just an inevitability of multi-tennant processing.

I'd have preferred a hardware flag that says "I accept that if untrusted code runs on this CPU, I've already lost" and keep the performance boosts of speculation, but alas.

well there's the mitigations=off kernel command-line switch in linux :)

A few reasons.

1) It takes a long time for desired design changes to make it to fabs, so it was always going to take years for the classes of vuln that were discovered to get mitigated in hardware.

2) More have been discovered in the intervening period.

3) Speculative execution really speeds things up, so the fixes are removing/changing as little spec. ex as you think you can get away with, and leaving the rest.

4) Intel's design pipeline is significantly messed up by its 10nm fab issues.

I think the tick-tock strategy[0] was still salvageable when these vulnerabilities were discovered, and it would be reasonable to assume that the next tock would fix these. Isn't Intel's 10 nm mass production five years late?

[0] https://en.wikipedia.org/wiki/Tick-tock_model

Spectre was disclosed to Intel sometime in 2017. Skylake (14nm) was the most recent rearchitecture at that point. The 10 nm rearchitecture was most certainly already in development, and may have been too far in to substantially address. I would expect it to be substantially addressed in the 7 nm rearchitecture, whenever that happens.

Many large customers don't need the mitigations because the attacks aren't relevant in their threat model and they prefer the peak performance provided by as much speculative execution as they can buy.

Because they aren't a bug, nominally - they're very potent side channels that peer directly into the CPU's operation at a very topological level.

CPUs are extremely expensive to design and verify, and astronomically expensive to make - these things take time.

Because if you discover how to fix Spectre completely, that would make (specialized) news.

Given common high perf microarchitectures, that's quasi-impossible. You can use somewhat efficient mitigations though.

Would segmented caches be a solution? What I mean is, allow the operating system to flag each memory page as belonging to a certain tenant id, and not allow speculation across tenant boundaries? This doesn't seem like a complicated addition, given that we already have multi-level page tables, caches and MMU accelerators for virtual environments.

Then again, if the solution was simple, I'm sure it would have already been implemented.

You want to protect against multiprocessor attacks through MESI. At which point I just have no idea of what to do purely in hardware.

The best system design change IMO would be to tag at programming language level (to systematize the introduction of the needed barriers, without needing too many of them, thus minimizing the overhead -- which is a must otherwise you can as well remove OOO entirely), but I suspect that's not going to happen for most systems. Or even any of them.

For Meltdown, they aren't. It was silly to do lazy validation of memory accesses and Intel fixed that.

For Spectre, you can't really have a high performance chip that isn't vulnerable to it in theory. A processor can't read your mind and know which code within a process should be able to communicate with which data within the process unless you tell it. You could just go to strict in order but that's taking a huge performance hit. Programmers cominging secure information and JITs running untrusted code within the same process will have to work to make sure they're not vulnerable to Spectre going forward.

> For Spectre, you can't really have a high performance chip that isn't vulnerable to it in theory.

You could if you had a fully transactional cache such that branch misses could be rolled back. It's highly non-trivial and likely far too expensive in die space to justify, but theoretically solvable.

But I think realistically CPUs are just going to say "processes are the only security boundary we offer" and leave it at that. Which puts things like WASM in a very questionable spot (particularly things like WASM in the kernel), but Intel & AMD probably don't care about that too much. For web browsers all the major ones just gave up on in-process sandboxing and that's why we have things like per-iframe process sandboxes now ( and then reduced privileges in-process iframes with the 'sandbox' attribute: https://caniuse.com/?search=sandbox )

For decades now hardware has been designed that can only be fully exploited by sufficiently advanced software. With CPUs this started in a big way when multiple cores became the norm. But the trend exists in completely different areas too, like DNA sequencing machines. Some people argued about this kind of thing many years ago, but it shows no signs of changing.

Because they mostly don't matter. Where is a practical, real world exploit? (This means not POC that works under perfect conditions.)

You're talking to people who are paranoid about Google using their search history to show more relevant ads... Just disable mitigations and let everyone else decide for themselves.

I do understand the need for top security in enterprise applications. But for personal use, all of this seems a bit ridiculous.

I've disabled mitigations on every computer in my home, will enable if I get burned. ~10-20% performance difference - I consider it a decent tradeoff.

But then again, I don't stress much about being hacked or privacy. It's not worth the mental effort, plus I'm a nobody and I accept that.

Even for many enterprise applications it is not necessary. What is the point of enabling mitigations on a single tenant database server, for example?

cpus would be extremely slow without the issues

Reply on news.ycombinator.com