How secure are RISC-V chips? | Hacker News Reader

How secure are RISC-V chips?

semiengineering.com

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?

> 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.

Part of the problem is that existing ISAs have been (and still are) underspecified. At best software was software was written against observed implementation behaviour. More commonly software wasn't written against any (formal) specification from simple things like is shifting by a variable number of bits a constant time operation, to nastier things like does the latency of multiplication leak the magnitude or hamming weight all the way to does the the implementation speculate past permission checks and leak observable state changes left behind by speculative memory accesses. Most instruction sets don't specify the presence and absence of side channels. RISC-V is in a better position than most other ISAs to fix this "oversight".

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!

> 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?

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!

> 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.

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?

An open ISA merely allows anyone to implement their own core without worrying about getting sued.

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.

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

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.

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.

>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?

Do mips and power accept changes/extensions suggestions?

Does RISC-V accept changes to ratified specs beyond clarifications of existing intent?

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.

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

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?

>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-sLGbw...

The problem is that this only applies to the design and not the implementation. There is no perfect design and certainly no perfect implementations.

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.

Reply on news.ycombinator.com