6 ms·

RISC-V: The New Architecture on the Block

45 points by johnblood 5y ago

1MachineElf 5y ago
Lately I find myself upvoting every submission from Klara Systems[0]. Focus of the articles seems to be consistently good. I'm not affiliated with them, just an impressed onlooker. [0] https://news.ycombinator.com/from?site=klarasystems.com https://news.ycombinator.com/from?site=klarasystems.com
- ncmncm 5y ago
  I do not. This article is fluff, with at least one glaring falsehood noted in a sibling comment.
- mrtweetyhack 5y ago
  they are basically regurgitating content that has been told many times over
hlieberman 5y ago
At least one of the points in this article isn't true. The article states "RISC-V is not affected by the Meltdown and Spectre vulnerabilities... [because it does] not perform any speculative memory accesses" -- but that's only true for some designs, not anything done by the ISA. Many of the higher performance RISC-V designs do, in fact, do speculation. RISC-V BOOM[0], by Berkeley, is vulnerable to Spectre[1][2]. One of the attempts to create an extension to the RISC-V ISA that has integrated security features (CHERI, [3]) itself was shown to be vulnerable to Spectre-like attacks[4]. The fact that most RISC-V chips were not vulnerable to Spectre is simply because they hadn't implemented a particular kind of performance optimization, not because there was anything intrinsic to the ISA that prevented them from being so. [0]: https://boom-core.org/ https://boom-core.org/ [1]: https://github.com/abejgonzalez/boom-attacks https://github.com/abejgonzalez/boom-attacks [2]: https://boom-core.org/docs/replicating_mitigating_spectre_carrv19.pdf https://boom-core.org/docs/replicating_mitigating_spectre_ca... [3]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-risc-v.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... [4]: https://kth.diva-portal.org/smash/get/diva2:1538245/FULLTEXT01.pdf https://kth.diva-portal.org/smash/get/diva2:1538245/FULLTEXT...
- ncmncm 5y ago
  Yes, it is a fundamentally misleading assertion.
- brucehoult 5y ago
  What you say is true, but it's not the end of the story. Higher performance RISC-V CPU cores that do speculation are under development or in some cases have been announced but not yet shipped. They have the opportunity to design to avoid those vulnerabilities from the start, which is a lot easier than fixing things up afterwards -- or simply losing a lot of performance on already-shipped CPUs by turning features off. It's not actually very hard to avoid these kids of vulnerabilities. All that is needed is to not permanently update state until the instruction is no longer speculative. For example: - don't update the branch prediction tables until the branch is proven to execute - if loading a cache line causes another cache line to be evicted, keep both until it is known whether the load is supposed to execute This requires provisioning a few more of these kinds of resources than you might previously have had, which costs a little silicon area, but it doesn't cost speed. Sometimes particularly demanding code might cause you to run out of these speculation resources and then you have to stall until an entry is freed up. This can already happen with things such as store buffers. If it never happens then you've probably over-provisioned :-)
  - oldnews193 5y ago
    > - don't update the branch prediction tables until the branch is proven to execute > - if loading a cache line causes another cache line to be evicted, keep both until it is known whether the load is supposed to execute This sounds interesting. How do these countermeasures actually prevent Spectre V1? And if they do, why didn't Intel implement them? Seems like they are fully microarchitectural, and therefore opaque to the software world.
    - avianes 5y ago
      All Spectre/Meltdown attacks go through the same 3 steps in this order: 1) taking control over transient instruction execution 2) controlled transient instructions access a legal data (but illegal for us) 3) controlled transient instructions exfiltrate this data through a side channel between the microarch and the arch For Spectre V1: Step 1) is performed by the Branch-Predictor, step 2) depends on the gadget targeted within the victim code, and step 3) is completed using a FLUSH+RELOAD or a EVICT+RELOAD triggered by a transient load. If one of these 3 steps is not met then the attack is impossible. The brucehoult proposal (obviously not the first to suggest this) is to eliminate step 3): if no transient execution side effect/microarchitectural state is made observable, then there is no way to exfiltrate data. All Spectre/Meltdown attacks are therefore made unfeasible. The problem is that brucehoult's proposal does not guarantee that all side-channels are infeasible at all, it only guarantees that side channels based on branch prediction or caching are no longer possible. Furthermore, microarchitectural optimizations are made to have an observable effect on the execution time. Therefore, it's likely that other timing side-channels will be exposed/discovered/used.
cepher 5y ago
I’ve recently gained an interest in computer architecture and systems programming in general after some high performance computing projects. Have been hearing about RISC-V from a distance, and am wondering if delving into it would be one of the best ways to satisfy this interest and gain some valuable knowledge/skills at the same time.
- ncmncm 5y ago
  RISC-V is an OK design, but quite atypical. So, being simpler than others, it will be easier to understand; but for the same reason, does not acquaint you with details seen in designs currently used industrially. Some of the design decisions, and their expressed rationale, are considered unpersuasive by many involved with other architectures. For example, a status register, cited as interfering with optimal out-of-order execution, turns out not to be a problem in actual chips (where they rename it like other registers), so was omitted from the RISC-V design on what amounts to superstition. Some instruction sequences that would need to be "fused" to match performance of common chips involve many more instructions than are fused in any extant design, so it is unclear that such fusion would be practically achievable.
  - Symmetry 5y ago
    If you're working on a student or hobby project then simplifying the scoreboard or whatever OoO scheduling structure you use by having all instructions be 2 inputs and 1 output is a big help. Compared to the complexity of a modern core that's a drop in the bucket but for a single person or a few friends or grad students it can be a big deal. And by doing that project you're still learning the important things. So for someone in the position OP is in I'd certainly recommend RISC-V. Don't ask "Is RISC-V good or bad?" but rather "For what purposes is RISC-V suited?"
    - ncmncm 5y ago
      A better question is, "Given RISC-V, what mistakes can we avoid next time around?" They have been Turing complete from the first, so the differences are limited to speed, power consumption, and incidentals.
hulitu 5y ago
Will be nice to see some affordable motherbords and processors with this architecture.

45 points by johnblood 5y ago

Lately I find myself upvoting every submission from Klara Systems[0]. Focus of the articles seems to be consistently good. I'm not affiliated with them, just an impressed onlooker. [0] https://news.ycombinator.com/from?site=klarasystems.com https://news.ycombinator.com/from?site=klarasystems.com

ncmncm 5y ago
I do not. This article is fluff, with at least one glaring falsehood noted in a sibling comment.
mrtweetyhack 5y ago
they are basically regurgitating content that has been told many times over

hlieberman 5y ago

At least one of the points in this article isn't true. The article states "RISC-V is not affected by the Meltdown and Spectre vulnerabilities... [because it does] not perform any speculative memory accesses" -- but that's only true for some designs, not anything done by the ISA. Many of the higher performance RISC-V designs do, in fact, do speculation. RISC-V BOOM[0], by Berkeley, is vulnerable to Spectre[1][2]. One of the attempts to create an extension to the RISC-V ISA that has integrated security features (CHERI, [3]) itself was shown to be vulnerable to Spectre-like attacks[4]. The fact that most RISC-V chips were not vulnerable to Spectre is simply because they hadn't implemented a particular kind of performance optimization, not because there was anything intrinsic to the ISA that prevented them from being so. [0]: https://boom-core.org/ https://boom-core.org/ [1]: https://github.com/abejgonzalez/boom-attacks https://github.com/abejgonzalez/boom-attacks [2]: https://boom-core.org/docs/replicating_mitigating_spectre_carrv19.pdf https://boom-core.org/docs/replicating_mitigating_spectre_ca... [3]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-risc-v.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... [4]: https://kth.diva-portal.org/smash/get/diva2:1538245/FULLTEXT01.pdf https://kth.diva-portal.org/smash/get/diva2:1538245/FULLTEXT...

ncmncm 5y ago
Yes, it is a fundamentally misleading assertion.
brucehoult 5y ago
What you say is true, but it's not the end of the story. Higher performance RISC-V CPU cores that do speculation are under development or in some cases have been announced but not yet shipped. They have the opportunity to design to avoid those vulnerabilities from the start, which is a lot easier than fixing things up afterwards -- or simply losing a lot of performance on already-shipped CPUs by turning features off. It's not actually very hard to avoid these kids of vulnerabilities. All that is needed is to not permanently update state until the instruction is no longer speculative. For example: - don't update the branch prediction tables until the branch is proven to execute - if loading a cache line causes another cache line to be evicted, keep both until it is known whether the load is supposed to execute This requires provisioning a few more of these kinds of resources than you might previously have had, which costs a little silicon area, but it doesn't cost speed. Sometimes particularly demanding code might cause you to run out of these speculation resources and then you have to stall until an entry is freed up. This can already happen with things such as store buffers. If it never happens then you've probably over-provisioned :-)
- oldnews193 5y ago
  > - don't update the branch prediction tables until the branch is proven to execute > - if loading a cache line causes another cache line to be evicted, keep both until it is known whether the load is supposed to execute This sounds interesting. How do these countermeasures actually prevent Spectre V1? And if they do, why didn't Intel implement them? Seems like they are fully microarchitectural, and therefore opaque to the software world.
  - avianes 5y ago
    All Spectre/Meltdown attacks go through the same 3 steps in this order: 1) taking control over transient instruction execution 2) controlled transient instructions access a legal data (but illegal for us) 3) controlled transient instructions exfiltrate this data through a side channel between the microarch and the arch For Spectre V1: Step 1) is performed by the Branch-Predictor, step 2) depends on the gadget targeted within the victim code, and step 3) is completed using a FLUSH+RELOAD or a EVICT+RELOAD triggered by a transient load. If one of these 3 steps is not met then the attack is impossible. The brucehoult proposal (obviously not the first to suggest this) is to eliminate step 3): if no transient execution side effect/microarchitectural state is made observable, then there is no way to exfiltrate data. All Spectre/Meltdown attacks are therefore made unfeasible. The problem is that brucehoult's proposal does not guarantee that all side-channels are infeasible at all, it only guarantees that side channels based on branch prediction or caching are no longer possible. Furthermore, microarchitectural optimizations are made to have an observable effect on the execution time. Therefore, it's likely that other timing side-channels will be exposed/discovered/used.

cepher 5y ago

I’ve recently gained an interest in computer architecture and systems programming in general after some high performance computing projects. Have been hearing about RISC-V from a distance, and am wondering if delving into it would be one of the best ways to satisfy this interest and gain some valuable knowledge/skills at the same time.

ncmncm 5y ago
RISC-V is an OK design, but quite atypical. So, being simpler than others, it will be easier to understand; but for the same reason, does not acquaint you with details seen in designs currently used industrially. Some of the design decisions, and their expressed rationale, are considered unpersuasive by many involved with other architectures. For example, a status register, cited as interfering with optimal out-of-order execution, turns out not to be a problem in actual chips (where they rename it like other registers), so was omitted from the RISC-V design on what amounts to superstition. Some instruction sequences that would need to be "fused" to match performance of common chips involve many more instructions than are fused in any extant design, so it is unclear that such fusion would be practically achievable.
- Symmetry 5y ago
  If you're working on a student or hobby project then simplifying the scoreboard or whatever OoO scheduling structure you use by having all instructions be 2 inputs and 1 output is a big help. Compared to the complexity of a modern core that's a drop in the bucket but for a single person or a few friends or grad students it can be a big deal. And by doing that project you're still learning the important things. So for someone in the position OP is in I'd certainly recommend RISC-V. Don't ask "Is RISC-V good or bad?" but rather "For what purposes is RISC-V suited?"
  - ncmncm 5y ago
    A better question is, "Given RISC-V, what mistakes can we avoid next time around?" They have been Turing complete from the first, so the differences are limited to speed, power consumption, and incidentals.

hulitu 5y ago

Will be nice to see some affordable motherbords and processors with this architecture.