Building a More Secure World with the RISC-V ISA
riscv.org
riscv.org
Indeed. RISC-V is an ISA and says little about how any given implementation may accelerate branches or load cache lines. It's entirely feasible to create a CPU based on the RISC-V ISA that is vulnerable to these attacks. There are proprietary RISC-V implementations in the wild today that may or may not have such properties, and while these deeply embedded implementations are likely to be simple, in-order non-speculative processors we can't really know.
Recently the RISC-V ISA was found to have an under specified memory model[1] that could manifest as memory ordering problems in more complex (and as yet hypothetical) implementations. This was discovered by Princeton researchers using a formal verification system. Since then RISC-V developers have been working[2] toward correcting this by fully specifying the RISC-V memory model (including two variants with different degrees of rigor.)
To my mind this specific case argues that open design may see real benefits from public scrutiny.
[1] https://www.electronicsweekly.com/open-source-engineering/ri... [2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/i...
I thought this was all down to an implementation detail and has nothing to do with ISAs.
> the open RISC-V ISA makes it possible for many different groups to experiment with alternative mitigation techniques and share results.
> [you/we have] an historic opportunity to “do security right” from the get-go with the benefit of up-to-date knowledge [so please let's do this]
Unlike operating systems, developing high-end microarchitiecture is not someting that bends well to open source model.
For example to fix Spectre attack, you would need some extra "speculative cache lines", which you would then copy to real cache lines once you decided they really need to be loaded or dump if not (having not flushed any observable cache lines). That would cost you a lot of extra silicon. Which would cost you dollars. Alternatively, you could just reduce speculation, which would cost you performance. The third alternative is what we're doing now: nothing. That costs you security.
I don't think your equation is fact or rigorous, I respect your work but it call bull on it. And there are way more than 3 options, this is a false dichotomy.
To break this equation, you need a new paradigm, which often comes from outsiders adding their perspective. And open source is a great way to do this.
Either way, this is the time everyone and their brother, sister, mother and child will have something to sell you, so it's not surprised the RISC-V people are out to sell their architecture now.
One can only hope! At this point we could stand to have some architectural fragmentation. I'm pretty happy to see RISC-V blatantly capitalizing on this situation.
- Can load across protection boundaries Valid data is usable; invalid data cannot be seen
At the very least, this probably makes ASLR pretty easy to defeat across protection boundaries. Are you really willing to bet that there will never be a more clever exploit that can determine more information? In slide 51 of the IPC talk[0] they explicitly say that they put permissions checking after the cache, and that this is essential for their performance and power claims.
[0] https://millcomputing.com/docs/inter-process-communication/
Creating IRC clones, UNIX clones, talk clones, FB clones is anything but innovation.
Also, if you do come up with a better way, you've a much greater chance of persuading someone to implement it.
True but misleading. Rocket is an in-order chip. Not only it does not perform memory accesses speculatively, it does not speculate at all.
Wasn't the BOOM CPU (https://github.com/ucb-bar/riscv-boom) fabricated? It definitely seems vulnerable to Spectre.
No one has fabricated a BOOM processor. It's a synthesizable core that runs on FPGA.
>> It definitely seems vulnerable to Spectre.
The question has been asked but there is no answer yet; it depends on the details of BOOM branch prediction and no one has made any claims yet about BOOM one way or the other.
This slide deck says that BOOMv2 was taped out in August for TSMC 28nm HPM:
https://content.riscv.org/wp-content/uploads/2017/12/Wed0936...
> The question has been asked but there is no answer yet; it depends on the details of BOOM branch prediction and no one has made any claims yet about BOOM one way or the other.
It's a pretty standard out-of-order design that executes loads speculatively. The BOOM spec has a sentence beginning
"As BOOM will send speculative load instructions to the cache…"
How would such a design not be vulnerable to Spectre?
> "As BOOM will send speculative load instructions to the cache…"
> How would such a design not be vulnerable to Spectre?
Hypothetically (I'm not familiar enough with BOOM to say whether this applies in this case or not), if the "speculation load depth" is limited to 1, then it seems it could be invulnerable? From the spectre paper, the exploit uses code like
if (x < array1_size) y = array2[array1[x] * 256];
So if the speculation load depth would be limited to 1, the cpu could speculatively load array1[x], compute "array1[x] * 256", but not load "array2[array1[x] * 256]" until the branch has been resolved?
Now, I don't know enough about micro-architecture to say whether such an idea makes any sense in general. Secondly, it seems Spectre is only the first on a long series of side channel attacks that target speculation, so it might be that the hypothetical "speculation load depth limited" design I envisioned above is vulnerable to some other variation of the attack.
What does "synthesizable core" mean here? Does it simply mean that someone has written the Verilog that could actually produce a working core and made it available?
That means two things. One, that the design description ("RTL code") can be pushed through synthesis and place-and-route tools and turned into gates. This is useful for putting the design onto an FPGA or getting a piece of silicon (ASIC chip).
But it also means "not custom", as in, the gates are not auto-generated from "synthesizable RTL" but rather than laid out by hand. Full custom can eke out some improvements over synthesizable logic, but it's also more expensive and can preclude testing out designs on FPGAs before manufacture.
Most modern chips are mostly synthesized with some of the more critical components (and more "regular" structures) handled using custom or semi-custom methodologies.
If we take this stricter definition, is there any RISC-V hardware out there except the SiFive ones, which are apparently simple enough that they are indeed not susceptible to these issues?
Anyone interested in what a better hardware/software-security architecture for RISC-V might look like should check out these exemplary projects:
http://www.crash-safe.org/papers.html
http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
https://vtechworks.lib.vt.edu/bitstream/handle/10919/29244/e...
CHERI already runs FreeBSD on a FPGA machine. I previously suggested merging Rocket with a version of CHERI as a start for that reason. Then, Draper is modifying or has modified RISC-V to use SAFE architecture. They're creating a brand around it as below.
http://www.draper.com/solution/inherently-secure-processor
So, that's what I've seen so far that addresses piles of vulnerabilities with a whole-system style of protection.
I think they're fairly clearly stating that the licensing and community arrangements around RISC-V make it an excellent testbed for high performance mitigations to these problems.
https://millcomputing.com/blog/wp-content/uploads/2018/01/Sp...
(I'm currently porting Fedora to RISC-V)
The more the complexity, the harder it is to keep software (or hardware, which for CPUs is defined as software) bug-free.
CISC simply has no place in the networked world, and RISC-V is the best RISC architecture.
Nowadays it just doesn't matter, because CPUs translate ISA into whatever they please.
Cache and out of order buffers (speculation) is what is behind latest security issues.
That's one way to look at it. Another is that opaque CPU designs are a big issue (at least for meltdown, which is a bug; spectre is more of a broken design philosophy).
Doing that comes at a cost, which compounds the complexity already added by merit of being CISC in the first place.
Besides, this translation layer is not a major source of complexity anymore. Even instruction decoding in x86 is not a big deal anymore.
What larger code size?
RISC-V is no worse than x86-64.
Refer to: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu...
Being a new ISA, RISC-V does have an advantage of being able to learn from past mistakes.
It's very nice, indeed. Unlike the established RISC ISAs, this one's created with decades of RISC (and CISC) experience to draw from.
I'd of course still have my doubts whether this is going to draw any traction, if it wasn't for the list of RISC-V Foundation members.
RISC only made sense when logic cycle times, memory cycle times, and I/O cycle times were at rough parity.
As for your claims on RISC not making sense, I'll just say it makes more sense than ever, as complexity leads to issues, which could affect security, and security is important in the present networked world.
This is why Spectre is as ubiquitous as it is. Speculative execution is not a feature someone implements just for the sake of it.
Requires is debatable. If someone manages to match it with a simpler design, it's an improvement. RISC-V open implementations are surprisingly very competitive already.
>With a very simple ISA,
Seems to imply that this is a minus, but what CISC really means in the present world is that there's a CISC->RISC translation layer, which is not free, and a lot of work passed down to toolchain developers, as they have to generate code for a CISC ISA.
In x86/amd64, the complexity is such that no individual can be expected to understand the whole thing, and CPU designers, low level software and compiler developers have to deal with this (and will inevitably screw up). Why this isn't seen as a massive problem baffles me.
More like a mixture of something like CISC->VLIW and CISC->"micro-ops". Remember x86 implementations can actually combine x86 ISA instruction pairs into a micro-op [0].
RISC is just a concept that was a great fit to the constraints the industry had in the nineties. It was great for achieving high clock speeds back then. The constraints are just different nowadays.
In RISC-V parlance, it'd be the new vector extensions. They're pretty cool as they've made the width variable. Refer to 7th workshop proceedings.
>micro-ops
Are a fancy word. It just means a (hidden) RISC architecture. There's a bunch of RISC architectures out there, but they get down to doing more or less the same things.
Most RISC and CISC architectures in use today are evolved from ones existing back in the 80s, and carry a lot of baggage. RISC-V benefits from having a clean slate at this, using the experience of existing ISAs.
>can actually combine x86 ISA instruction pairs into a micro-op
More complexity, and more tickets for the implementation bug lottery.
> More complexity, and more tickets for the implementation bug lottery.
Well, the slides (and accompanying paper) you linked to earlier in this thread makes the cases for using macro-op fusion in high-performance RISC-V designs.
Very nice and very clean when done as they propose with this RISC ISA.
Do you have some sources for this?