Hacker News Reader

Comment by jjav | Hacker News Reader

> This is an unreasonable position. Vulnerabilities can be fixed

That's a highly optimistic position, to the point of being almost wishful thinking.

The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now.

Other similar ones to be published years into the future are also there today being likely exploited as we speak.

Running untrusted code on the same silicon as sensitive code (data), is unlikely to ever actually be truly safe.

View on HN

The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug.

We should move forward. Apple did a great job with the M{1,2} processors. Not only they are fantastic in terms of performance and energy usage, but also (to this moment) they don't seem to suffer from these issues. The reason is that the CPU is simpler, and a simpler thing is easy to design right in the first place.

Meltdown and Spectre affected ARM and POWER CPUs. Apple's included. PACMAN affected M1. The real problem is speculative execution seemingly.

Performance sorta hinges on it. It could be that the cheaper way the chipmakers deal with it is to phase out the 4core set and push the cores on a die higher, and to do that--incorporate an older core design into dedicated cores for untrusted code.

This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior.

Essentially: instead of shutting down SMT for the entire machine, make the customer "prove" the code is safe for elevation or else it gets scheduled as non-SMT.

> Performance sorta hinges on it.

Yes. I did not mean to imply the real problem had a simple solution.

> The real problem here is the x86 architecture

Even if we could say for sure that x86 has been disproportionately affected by speculative execution bugs (which already seems dubious), that could easily be due to a kind of selection bias. Presumably security researchers as a group more or less focus on the most popular and relevant ISAs/microarchitectures.

Reply on news.ycombinator.com