5 ms·

How secure are RISC-V chips?

xiphias2 4y ago
Link to the 2017 technical paper that found bugs in RISC-V ISA: https://mrmgroup.cs.princeton.edu/papers/ctrippel_ASPLOS17.pdf https://mrmgroup.cs.princeton.edu/papers/ctrippel_ASPLOS17.p...
nix23 4y ago
>The original research papers around that work were published using RISC-V architecture, just because it was the only architecture that was open I was thinking that Mips and Power are "open" too, no?
- photonbeam 4y ago
  Do mips and power accept changes/extensions suggestions?
  - cwzwarich 4y ago
    Does RISC-V accept changes to ratified specs beyond clarifications of existing intent?
    - znwu 4y ago
      The open-sourced toolchain of RISC-V accepts any kind of extensions as long as they are in the reserved code space, basically out-of-the-box. The current ratifying body does not hold any special toolchain or legal influence other than its publicity, thus irrelevant in this comparison.
- Eleison23 4y ago
  [dead]
snvzz 4y ago
Secure (i.e. capable of high assurance) enough for seL4 to recommend them.
gchadwick 4y ago
This a rather broad question, one may as well ask 'Are locks secure?' or even 'Are computers secure?'. I'm not hugely convinced the open licensing of the ISA enables better security. Computer architecture and computer security researchers have worked with closed licensing ISAs for years and it hasn't stopped them finding issues. Open silicon on the other hand does form a good basis for secure design though one must not make the mistake that open design inherently provides better security. Rather it's more about providing trust and provenance (along with a bunch of other collateral) so design users can have confidence in the security. Like many RISC-V articles this one sadly freely mixes open ISA licensing with open design and they are not the same!
- rhn_mk1 4y ago
  > Computer architecture and computer security researchers have worked with closed licensing ISAs for years and it hasn't stopped them finding issues. I think this is kind of backwards. You want people to have access and find issues, so that you can correct them. Opening the ISA solves one half of this problem: access and finding.
  - ribit 4y ago
    Why is open ISA better in respect to this than simply documented ISA? Is this about public availability of reference implementations or some sort of validation tools?
    - SanjayMehta 4y ago
      An open ISA merely allows anyone to implement their own core without worrying about getting sued.
      - deleted 4y ago
        [deleted]
  - gchadwick 4y ago
    Well take arm and x86, plenty of research papers done on these (e.g. the original speculative execution attacks) but they are closed licensing. Were the ISA specifications also fully closed (i.e. no reading without an NDA, strict restrictions on any published research even if you did get access etc), then yes that would be an impediment, but practically that's not what we see.
ribit 4y ago
I have difficulty following some of the points made in that article. 1. I always thought that common vulnerabilities like Spectre were a problem with implementation (a certain way to do speculative execution) rather than with the ISA. How is RISC-V ISA supposed to solve these kind of issues? 2. I do not understand how openness of RISC-V makes it easier to find bugs in the ISA. For example, ARM ISA is fully described in a publicly available documents. What is stopping a security researcher from analysing the ARM specification and pointing out issues at the ISA level? Or do they mean that it's easier to analyse open-sources RISC-V implementations rather than ISA spec?
- gchadwick 4y ago
  > 1. I always thought that common vulnerabilities like Spectre were a problem with implementation (a certain way to do speculative execution) rather than with the ISA. How is RISC-V ISA supposed to solve these kind of issues? They are implementation dependent but the architecure can help. It can provides guarantees about the ways in which speculation is limited and provide features to help software isolate speculation (if you download the arm ARM here: https://developer.arm.com/documentation/ddi0487/latest https://developer.arm.com/documentation/ddi0487/latest and look at section A2.2.1 which lists post v8.0 architecture additions you'll see a whole bunch of stuff around speculative execution for instance. The RISC-V ISA doesn't inherently resolve these issues, indeed I don't think it says anything on speculative execution, provide certain features and and guarantees to help isolate it (like arm does). > 2. I do not understand how openness of RISC-V makes it easier to find bugs in the ISA. For example, ARM ISA is fully described in a publicly available documents. What is stopping a security researcher from analysing the ARM specification and pointing out issues at the ISA level? Or do they mean that it's easier to analyse open-sources RISC-V implementations rather than ISA spec? I don't think the ISA openness helps you much or at all here, researchers analyse x86 and arm all the time and publish results. I think they're mixing up open ISA with open design and with the latter, yes it does make it easier for external parties to find security issues.
- IshKebab 4y ago
  Yeah the point about not being able to do this for ARM makes no sense. Especially since the paper starts with an example of the issue from ARM!
sylware 4y ago
specter and friends showed us, again, that "security" is a fantasy. I would not expect anything different from RISC-V CPU designs. BTW, are specter and friends fixed in Zen4?
- willnonya 4y ago
  The problem is that this only applies to the design and not the implementation. There is no perfect design and certainly no perfect implementations.
  - sylware 4y ago
    RISC-V would be seen as an "average" modern ISAs. Like everything, it comes with trade-offs, and here some ISA design choices come straight from the experience accumulated on advanced CPU design. For instance, if I did understand well, the handling of arithmetics flags in RISC-V is what it is because of it makes out-of-order CPU design way easier.
- snvzz 4y ago
  >specter and friends showed us, again, that "security" is a fantasy. >I would not expect anything different from RISC-V CPU designs. Look into `fence.t` [0]. 0. https://youtu.be/C3nOjXhyPfk?list=PLtoQeavghzr3atxNQig-sLGbwoKBSVxGV&t=1171 https://youtu.be/C3nOjXhyPfk?list=PLtoQeavghzr3atxNQig-sLGbw...
willnonya 4y ago
Being open source does not make anything inherently more secure. It adds transparency and possibly confidence but for those without the resources to review the designs themselves it still boils down to a matter of trust in the competence of those maintaining the design. The potential trial for security does not equal security. Most arguments in favor of open source security boil down to speculating about what's behind the curtain of closed systems. That's not really the same thing as security. One thing that open source does do is lay bare any undiscovered flaws for future discovery, and exploitation.
chrisrohlf 4y ago
Reducing the likelihood of side channels through transparency is a worthy endeavor. But for RISC-V, adoption of Control Flow Integrity (CFI) and memory tagging capabilities will have far greater security impact for the vast majority of users.

Link to the 2017 technical paper that found bugs in RISC-V ISA: https://mrmgroup.cs.princeton.edu/papers/ctrippel_ASPLOS17.pdf https://mrmgroup.cs.princeton.edu/papers/ctrippel_ASPLOS17.p...

nix23 4y ago

>The original research papers around that work were published using RISC-V architecture, just because it was the only architecture that was open I was thinking that Mips and Power are "open" too, no?

photonbeam 4y ago
Do mips and power accept changes/extensions suggestions?
- cwzwarich 4y ago
  Does RISC-V accept changes to ratified specs beyond clarifications of existing intent?
  - znwu 4y ago
    The open-sourced toolchain of RISC-V accepts any kind of extensions as long as they are in the reserved code space, basically out-of-the-box. The current ratifying body does not hold any special toolchain or legal influence other than its publicity, thus irrelevant in this comparison.
Eleison23 4y ago
[dead]

snvzz 4y ago

Secure (i.e. capable of high assurance) enough for seL4 to recommend them.

gchadwick 4y ago

This a rather broad question, one may as well ask 'Are locks secure?' or even 'Are computers secure?'. I'm not hugely convinced the open licensing of the ISA enables better security. Computer architecture and computer security researchers have worked with closed licensing ISAs for years and it hasn't stopped them finding issues. Open silicon on the other hand does form a good basis for secure design though one must not make the mistake that open design inherently provides better security. Rather it's more about providing trust and provenance (along with a bunch of other collateral) so design users can have confidence in the security. Like many RISC-V articles this one sadly freely mixes open ISA licensing with open design and they are not the same!

rhn_mk1 4y ago
> Computer architecture and computer security researchers have worked with closed licensing ISAs for years and it hasn't stopped them finding issues. I think this is kind of backwards. You want people to have access and find issues, so that you can correct them. Opening the ISA solves one half of this problem: access and finding.
- ribit 4y ago
  Why is open ISA better in respect to this than simply documented ISA? Is this about public availability of reference implementations or some sort of validation tools?
  - SanjayMehta 4y ago
    An open ISA merely allows anyone to implement their own core without worrying about getting sued.
    - deleted 4y ago
      [deleted]
- gchadwick 4y ago
  Well take arm and x86, plenty of research papers done on these (e.g. the original speculative execution attacks) but they are closed licensing. Were the ISA specifications also fully closed (i.e. no reading without an NDA, strict restrictions on any published research even if you did get access etc), then yes that would be an impediment, but practically that's not what we see.

ribit 4y ago

I have difficulty following some of the points made in that article. 1. I always thought that common vulnerabilities like Spectre were a problem with implementation (a certain way to do speculative execution) rather than with the ISA. How is RISC-V ISA supposed to solve these kind of issues? 2. I do not understand how openness of RISC-V makes it easier to find bugs in the ISA. For example, ARM ISA is fully described in a publicly available documents. What is stopping a security researcher from analysing the ARM specification and pointing out issues at the ISA level? Or do they mean that it's easier to analyse open-sources RISC-V implementations rather than ISA spec?

gchadwick 4y ago
> 1. I always thought that common vulnerabilities like Spectre were a problem with implementation (a certain way to do speculative execution) rather than with the ISA. How is RISC-V ISA supposed to solve these kind of issues? They are implementation dependent but the architecure can help. It can provides guarantees about the ways in which speculation is limited and provide features to help software isolate speculation (if you download the arm ARM here: https://developer.arm.com/documentation/ddi0487/latest https://developer.arm.com/documentation/ddi0487/latest and look at section A2.2.1 which lists post v8.0 architecture additions you'll see a whole bunch of stuff around speculative execution for instance. The RISC-V ISA doesn't inherently resolve these issues, indeed I don't think it says anything on speculative execution, provide certain features and and guarantees to help isolate it (like arm does). > 2. I do not understand how openness of RISC-V makes it easier to find bugs in the ISA. For example, ARM ISA is fully described in a publicly available documents. What is stopping a security researcher from analysing the ARM specification and pointing out issues at the ISA level? Or do they mean that it's easier to analyse open-sources RISC-V implementations rather than ISA spec? I don't think the ISA openness helps you much or at all here, researchers analyse x86 and arm all the time and publish results. I think they're mixing up open ISA with open design and with the latter, yes it does make it easier for external parties to find security issues.
IshKebab 4y ago
Yeah the point about not being able to do this for ARM makes no sense. Especially since the paper starts with an example of the issue from ARM!

sylware 4y ago

specter and friends showed us, again, that "security" is a fantasy. I would not expect anything different from RISC-V CPU designs. BTW, are specter and friends fixed in Zen4?

willnonya 4y ago
The problem is that this only applies to the design and not the implementation. There is no perfect design and certainly no perfect implementations.
- sylware 4y ago
  RISC-V would be seen as an "average" modern ISAs. Like everything, it comes with trade-offs, and here some ISA design choices come straight from the experience accumulated on advanced CPU design. For instance, if I did understand well, the handling of arithmetics flags in RISC-V is what it is because of it makes out-of-order CPU design way easier.
snvzz 4y ago
>specter and friends showed us, again, that "security" is a fantasy. >I would not expect anything different from RISC-V CPU designs. Look into `fence.t` [0]. 0. https://youtu.be/C3nOjXhyPfk?list=PLtoQeavghzr3atxNQig-sLGbwoKBSVxGV&t=1171 https://youtu.be/C3nOjXhyPfk?list=PLtoQeavghzr3atxNQig-sLGbw...

willnonya 4y ago

Being open source does not make anything inherently more secure. It adds transparency and possibly confidence but for those without the resources to review the designs themselves it still boils down to a matter of trust in the competence of those maintaining the design. The potential trial for security does not equal security. Most arguments in favor of open source security boil down to speculating about what's behind the curtain of closed systems. That's not really the same thing as security. One thing that open source does do is lay bare any undiscovered flaws for future discovery, and exploitation.

chrisrohlf 4y ago

Reducing the likelihood of side channels through transparency is a worthy endeavor. But for RISC-V, adoption of Control Flow Integrity (CFI) and memory tagging capabilities will have far greater security impact for the vast majority of users.