[HN Gopher] How secure are RISC-V chips?
       ___________________________________________________________________
        
       How secure are RISC-V chips?
        
       Author : giuliomagnifico
       Score  : 48 points
       Date   : 2023-01-07 17:52 UTC (1 days ago)
        
 (HTM) web link (semiengineering.com)
 (TXT) w3m dump (semiengineering.com)
        
       | willnonya wrote:
       | 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.
        
       | xiphias2 wrote:
       | Link to the 2017 technical paper that found bugs in RISC-V ISA:
       | https://mrmgroup.cs.princeton.edu/papers/ctrippel_ASPLOS17.p...
        
       | nix23 wrote:
       | >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?
        
         | Eleison23 wrote:
         | [dead]
        
         | photonbeam wrote:
         | Do mips and power accept changes/extensions suggestions?
        
           | cwzwarich wrote:
           | Does RISC-V accept changes to ratified specs beyond
           | clarifications of existing intent?
        
       | chrisrohlf wrote:
       | 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.
        
       | gchadwick wrote:
       | 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 wrote:
         | > 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 wrote:
           | 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 wrote:
             | An open ISA merely allows anyone to implement their own
             | core without worrying about getting sued.
        
               | [deleted]
        
           | gchadwick wrote:
           | 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 wrote:
       | 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 wrote:
         | > 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 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 wrote:
         | 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!
        
         | colejohnson66 wrote:
         | > For example, ARM ISA is fully described in a publicly
         | available documents.
         | 
         | Wasn't Spectre discovered through nothing more than a careful
         | reading of Intel's publicly available documentation?
        
       | snvzz wrote:
       | Secure (i.e. capable of high assurance) enough for seL4 to
       | recommend them.
        
       | sylware wrote:
       | 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 wrote:
         | The problem is that this only applies to the design and not the
         | implementation. There is no perfect design and certainly no
         | perfect implementations.
        
       ___________________________________________________________________
       (page generated 2023-01-08 23:02 UTC)