The microarchitectures that I saw and the ones that I hope to one day see [pdf] | Hacker News Reader

The microarchitectures that I saw and the ones that I hope to one day see [pdf]

hardwear.io

100 pointsluu27 comments

Just starting to read this, but I already am on board based on the humor and extremely accurate re-writing of the famous do what you love and never work a day in your life quote.

mid read edit - wow, this is a pretty huge indictment that literal cross company gang conspired to suppress security issues in modern processors? Unless I drastically misread?

And that google / others failed to bother to apply some of these mitigations well or at all?

"We do this not because it's easy, but because we thought it'd be easy" is gold.

Perhaps not his, but I will steal it for my next presentation :)

Also very true in my experience

Me: "this should be easy"

Narrator: It was extremely not easy

Product vision: this ought to be easy

> that literal cross company gang conspired to suppress security issues in modern processors

Alarming, but sadly not uncommon in software either; vendor internal politics means that a lot of people really do not like "disclosure" and push for everything to be behind closed doors. Not to make things insecure (although it may have that effect), but to avoid the perception of insecurity.

I don’t get it. If security is so important, then it should be okay to sacrifice performance. Why is there such inertia in accepting this? If security is all that is needed, get an in order completely non speculative core with no branch prediction (you can’t even run your side channels in this case efficiently)

Are these even sold today? Outside of embedded systems I mean.

Not for desktop use, no. Probably the most powerful example remaining will be some sort of DSP designed for predictable cycle-accurate timing.

Arm Cortex-R series is intended to very hard real-time, and do branch prediction only if explicitly enabled

> However, the Cortex-R7 and Cortex-R8 do not enable branch prediction automatically at reset. This means software must enable branch prediction to get the maximum hardware performance.

https://community.arm.com/arm-community-blogs/b/architecture...

Its still OoO but idk how much that impacts anything

Edit: apparently only r7/8 were ooo, r52/82 are in-order again

The problem is that nobody is willing to pay a x100 penalty for security for general purpose computing.

Even a very low penalty isn't something that the industry is willing to produce..

For example, the RISC-V is derived from the MIPS, the MIPS had some instruction to trap on integer overflow, it's a very minor penalty to have these instructions, and guess what? They haven't been included in RISC-V..

RISC-V would not add instructions w/o a strong justification, as simplicity has value in itself, and RISC-V is very RISC in recognizing that.

If it's not that frequent and it can be done with 2 instructions, it'd be quite hard to make the argument for a dedicated instruction.

Except that as soon as you have two instructions instead of one, people starts talking about cache pressure and turns off the safety. Optional security == no security.

By that same logic, you might as well run everything in M mode.

This is extremely controversial given that the only marketing criterion of CPUs is .. performance.

If it can be hived off to a separate core, quite possibly on a separate die to avoid power attacks, then that seems a sensible approach from a hardware architecture point of view. But that complicates the software: how do you run your security critical browser Javascript on the co-processor?

Absolute secure system is absolutely not practical. Good security is always a tradeoff. Sacrificed performance means increases resource usage - more chips and more energy per unit of computation and while humanity still burns coal/carbohydrates to make electricity increased CO2 emissions can be too high price to gain marginal improvement in security. Even if electricity is free of negative externalities we still have limited resources and need to think if better to allocate them to improve security or something else.

Alas, security generally isn't so important.

How many times have you been hacked by a side-channel exploit? (Or people you know? Or any publicly documented case?) Are you going to use a computer that runs at 1/10th the speed to mitigate that risk going forwards?

Keep in mind that a ton of non-side-channel exploits are caught in the wild every year, so your slow new computer isn't really secure, it's just not vulnerable to these specific attacks.

(For 1/10th: the Cortex-A55 in the following chart is the only "in-order" CPU: https://images.anandtech.com/doci/17102/SPECint2017_575px.pn... - though arguably even it isn't completely non-speculative, and it definitely has branch-prediction, but it's at least a reasonable ballpark.)

Not sure you read that chart right. It's slower because it's much lower power.

Out of order execution gives on the order of 2x speed improvement not 10x. I would imagine branch prediction gives a much bigger benefit but nobody is going to make a performance sensitive processor without branch prediction (whereas in-order is still common).

Good point, it's likely that a high-power in-order chip could go faster. Do you know of any examples of high-power in-order cores I could compare to?

The problem is that security is only important when you're running your valuable IP code and extremely private data on someone else's computer, right next to arbitrary code written by a third party.

No, that's nothing like my day-to-day work in a text editor and compiler or CAD app on my personal box, where choosing performance over security is obvious. But it basically describes the hyper-competitive modern cloud computing ecosystem exactly.

Unfortunately, due to consumer irrationality and imperfect information, economics seems to indicate that the best way to get money out of the value that can be added through software is to sell subscriptions to online services, not shrink-wrapped DVDs. Now that this has been discovered, I think we're unlikely to get a world where we all have insecure, high-performance local machines that don't depend on cloud services.

I've never personally been hacked by a side-channel exploit. A customer I work with recently got hacked by ransomware, which was scary, they've spent the last month wiping everything and restoring ~95% of their data from backups, but I feel safe assuming I'm just not interesting enough to be at risk of to high-effort spear-phishing hardware side channel attacks.

> The problem is that security is only important when you're running your valuable IP code and extremely private data on someone else's computer, right next to arbitrary code written by a third party.

I mostly agree in principle but disagree with your introduction. Unless you don’t use a web browser.

Your browser is an untrusted computing environment that is constantly downloading and running 3rd party code in sandboxed environments.

A modern browser looks a lot like an edge node running on-demand short-lived programs from 3rd parties.

Perhaps looking towards the promised land of a practical macro and micro arch defensible in the real world, then start with a minimal ISA that can most readily implement a capabilities secure kernel like seL4. Too many features are a problem.

RISCV could run seL4 I think? https://riscv.org/blog/2020/06/sel4-is-verified-on-risc-v/

Definitely, as the seL4 team actually do recommend RISC-V.

Can someone post the link to the talk ?

The conference just happened a week ago and I believe this is an original talk. It might be a while until a recording is published.

Compared to the simplicity of the decorator design pattern, I always found AOP libraries unnecessarily complicated and too implicit (magic.)

Reply on news.ycombinator.com