The microarchitectures that I saw and the ones that I hope to one day see [pdf](hardwear.io)
hardwear.io
The microarchitectures that I saw and the ones that I hope to one day see [pdf]
https://hardwear.io/usa-2023/presentation/the-microarchitectures-that-I-saw-and-the-ones-that-I-hope-to-one-day-see.pdf
28 comments
"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 :)
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
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.
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)
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?
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?
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.)
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.)
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.
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.
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.
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).
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?
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.
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..
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.
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.
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
> 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
[deleted]
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.
Compared to the simplicity of the decorator design pattern, I always found AOP libraries unnecessarily complicated and too implicit (magic.)
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?