9 ms·
Building a More Secure World with the RISC-V ISA
- deepnotderp 9y agoOkay, I'm all for RISC-V, but this makes no sense, RISC-V isn't magically immune to spectre for no reason.
- jeffdavis 9y agoNeither the article nor the title imply that. They are saying open is better, colaborative is better, and that RISCV is a chance to start over with security at the forefront.
- dmitrygr 9y agoThat does not change the fact that SUM(security,speed,price /due to Si area/) == CONST
- garmaine 9y agoThat equation doesn’t hold, as open source software has demonstrated time and time again.
- cwyers 9y agohttp://heartbleed.com/ http://heartbleed.com/
- dmitrygr 9y agoI was talking about hardware 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.
- sitkack 9y agoYou outline only a single solution of which there are many. The thing RISC-V gets you is the ability to iterate on an implementation while still running the body of existing code. As ridiculous as it seems, this hasn't been possible before. RISC-V didn't technically need to exist but it did politically and legally. 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.
- Momquist 9y agoI think this equation actually makes sense when only the same people/minds are changing the factors. If the same team is given the task of improving a product, chances are they will be close minded and only able to tweak say security at the expense of the other two. 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.
- UncleEntity 9y agoSeems more like jumping on the bandwagon to me... I thought this was all down to an implementation detail and has nothing to do with ISAs.
- shawnz 9y agoIf you read the very short article: > the open RISC-V ISA makes it possible for many different groups to experiment with alternative mitigation techniques and share results.
- mlinksva 9y agoAlternative short article if RISC-V community is target audience: > [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]
- bobajeff 9y agoBeing open doesn't gain you much here either. At the end of the day there is no "updating" it once a vulnerability is found.
- nitrogen 9y agoIt does make it more likely that a compatible replacement can be found on the market, though.
- Nokinside 9y agoHigh performance microarchitectures for RISCV are still going to be proprietary. Unlike operating systems, developing high-end microarchitiecture is not someting that bends well to open source model.
- awalton 9y agoIn fact, in this case, it's more probably immune because it's less mature. Only with advanced prefetching and speculative execution do you hit the Spectre of data that could have been. 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.
- ansible 9y agoYes. Only when you completely eliminate the conventional kind of speculative execution [0] can you have a hope of being immune to these sorry of problems. [0] https://millcomputing.com/docs/metadata/ https://millcomputing.com/docs/metadata/
- phkahler 9y agoNot really. What nobody has said AFAICT is that the attacks all stem from the problem of running untrusted code on your processor. It's not just apps or websites, we let JS code run our machine for every little ad banner. We allow our cloud infrastructure to share cache with someone else's. These things are all done in the name of convenience. Only when security is considered a top priority will these problems really go away. We must stop running untrusted code. Even. In. A. Sandbox.
- taf2 9y agoWe will always have bugs. The amount of money and resource efficiency we gain from sharing is too big to ignore. These issue will be addressed and yes more issues will be uncovered. Our sandboxes will get better, our kernels will harden and our CPU designs will improve. It’s actually not possible to throw our hands in the air and stop as you suggest. From every mistake we grow stronger because we don’t run away. It’s great that these issues have been uncovered. It sucks dealing with the fallout but that is only short term.
- pjmlp 9y agoWe would have less of them if companies were liable like in other industries.
- topspin 9y ago>> RISC-V isn't magically immune to spectre for no reason. 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/risc-v-bugs-found-princeton-2017-04/ https://www.electronicsweekly.com/open-source-engineering/ri... [2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/hKywNHBkAXM https://groups.google.com/a/groups.riscv.org/forum/#!topic/i...
- Nomentatus 9y agoIt isn't well argued, but the point is that if you have two chip designers/ISA shops in the world, both may make the same mistake. If the ISA is open, you (hopefully) have a hundred, and not all will fool themselves the same way. Also, if you do come up with a better way, you've a much greater chance of persuading someone to implement it.
- cwzwarich 9y ago> No announced RISC-V silicon is susceptible Wasn't the BOOM CPU (https://github.com/ucb-bar/riscv-boom https://github.com/ucb-bar/riscv-boom) fabricated? It definitely seems vulnerable to Spectre.
- topspin 9y ago>> Wasn't the BOOM CPU fabricated? 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.
- cwzwarich 9y ago> No one has fabricated a BOOM processor. It's a synthesizable core that runs on FPGA. 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-BOOM-v2-An-Open-Source-Out-of-Order-RISC-V-Core-Celio.pdf 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?
- jabl 9y ago> 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? 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.
- snvzz 9y agoThey do have a point. 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.
- fooker 9y agoHaving complex instructions is not the only way to make a complex processor. With a very simple ISA, to even come close to what a modern processor can do with a certain amount of time and power requires a ridiculously complicated design. This is why Spectre is as ubiquitous as it is. Speculative execution is not a feature someone implements just for the sake of it.
- deleted 9y ago[deleted]
- snvzz 9y ago>To even come close to what a modern processor can do with a certain amount of time and power REQUIRES a ridiculously complicated design. 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.
- vardump 9y ago> there's a CISC->RISC translation layer... 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. [0]: https://en.wikichip.org/wiki/macro-operation_fusion https://en.wikichip.org/wiki/macro-operation_fusion
- m_eiman 9y agoI’m wondering if the Mill would evade Spectre 1 and 2, have they said enough yet to speculate about that?
- ithkuil 9y agoAre you concerned with spectre 1+2 across protection domains or in the context of running untrusted code within the same process (e.g. a like a JS VM)?
- m_eiman 9y agoUntrusted code within the same process seems like it'd be harder for the CPU do something about, since it can't know what portions of the address space are trusted and not.
- m_eiman 9y agoMill have written this: https://millcomputing.com/blog/wp-content/uploads/2018/01/Spectre.03.pdf https://millcomputing.com/blog/wp-content/uploads/2018/01/Sp...
- sanxiyn 9y ago> No announced RISC-V silicon is susceptible, and the popular open-source RISC-V Rocket processor is unaffected as it does not perform memory accesses speculatively. True but misleading. Rocket is an in-order chip. Not only it does not perform memory accesses speculatively, it does not speculate at all.
- jabl 9y agoRocket has a branch predictor; if you're not going to do any kind of speculation, why have it in the first place?
- NinjaKitten 9y agoAFAIK its load store unit does plenty speculation.
- tscs37 9y agoPreloading instructions into the cache or only executing instructions speculatively which only modify the CPU's internal state and no caches.
- al2o3cr 9y agoThe direction of a branch isn't going to be known until a couple stages into the pipeline ("EX" in the classic RISC version). Ideally, the preceding stages in the pipeline will be fed correctly - that can either be the instructions immediately following the branch (as in the "branch delay slot(s)" found in some architectures) or the instructions at where the CPU thinks the branch will lead.
- fulafel 9y agoa pipeline flush and unprefetched instruction fetch on each branch (20-25% of insns) would dramatically slow down the CPU. With branch prediction you can potentially have correctly predicted branches take zero cycles, even without speculative execution.
- blattimwind 9y ago
- jasonkostempski 9y agoYeah. RISC-V is good.
- Crontab 9y agoIs RISC-V vaporware? It’s on HN all the time but I never see where it is available for purchase.
- microcolonel 9y agoSiFive seems to be selling the only publicly available chips as of yet. The FE310 (~300MHz 32-bit microcontroller, FreeRTOS capable) can be bought on the HiFive1 and one other dev board, or as bare chips. They say they'll ship a FU500 (~1.5GHz quad-core application processor with supervisor mode and memory protection, capable of booting Linux and FreeBSD) dev board (board called HiFive Unleashed) this quarter.
- rwmj 9y agoSiFive are sampling their 64 bit chips now and have said they will have them on sale in Q1 this year. (I'm currently porting Fedora to RISC-V)
- panic 9y agoHiFive1 is a dev kit based on RISC-V you can buy: https://www.sifive.com/products/hifive1/ https://www.sifive.com/products/hifive1/
- nickpsecurity 9y agoThis is a piece without substance since it basically says "Oh hey, competing chips actually selling to customers have some issues. We promise we'll be better when our lab designs finally end up in your hands. Trust and fund us now!" We'll see. 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.crash-safe.org/papers.html http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://vtechworks.lib.vt.edu/bitstream/handle/10919/29244/edmison_joshua_dissertation.pdf?sequence=1&isAllowed=y 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 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.
- microcolonel 9y ago> This is a piece without substance since it basically says "Oh hey, competing chips actually selling to customers have some issues. We promise we'll be better when our lab designs finally end up in your hands. Trust and fund us now!" We'll see. 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.