# Does RISC-V dodge the plague **URL:** \ **Category:** RISC-V\ **Created:** [January 4, 2018, 10:00pm UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965 "2018-01-04T22:00:14Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![blubee](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/blubee/32/858_2.png) [@blubee](https://forums.sifive.com/u/blubee)\ **Post date:** [January 4, 2018, 10:00pm UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965/1 "2018-01-04T22:00:14Z")
I am sure that we’ve all heard about [Meltdown & Spectre](https://spectreattack.com) cpu bugs. Does the RISC-V architecture suffer from these issues? ---
**Author:** ![andrew](https://avatars.discourse-cdn.com/v4/letter/a/f19dbf/32.png) [@andrew](https://forums.sifive.com/u/andrew)\ **Post date:** [January 4, 2018, 10:16pm UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965/2 "2018-01-04T22:16:56Z")
Meltdown and Spectre are both microarchitectural timing attacks. Speculative and out-of-order-execution implementations of any instruction-set architecture are potentially vulnerable to this family of attack. SiFive’s current RISC-V implementations do not perform the sort of speculation that these attacks rely upon, so they are not vulnerable. However, that is not to say that RISC-V is inherently invulnerable. ---
**Author:** ![blubee](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/blubee/32/858_2.png) [@blubee](https://forums.sifive.com/u/blubee)\ **Post date:** [January 4, 2018, 10:25pm UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965/3 "2018-01-04T22:25:06Z")
This is good to hear but it’s also a good lesson and hopefully the open source nature of RISC-V can implement these features in ways that are more secure. This is great news for open source hardware and RISC-V is in a great position to capitalize from these issues. It’s a major oversight when so much multi-user tech is built on inherently single core processors with multiple cores bolted together, is this outcome really a surprise? open source hardware can definitely help but we also need a new generation of thinkers to create truly multi-core architectures with security as a first class citizen. ---
**Author:** ![sailfish009](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/sailfish009/32/906_2.png) [@sailfish009](https://forums.sifive.com/u/sailfish009)\ **Post date:** [January 5, 2018, 6:58am UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965/5 "2018-01-05T06:58:19Z")
here is some information about it: > **[Preventing branch prediction timing attacks](https://rdist.root.org/2009/04/20/preventing-branch-prediction-timing-attacks/)** > > A few years ago, Aciicmez et al published a new timing attack (1, 2, 3) exploiting the branch prediction feature of x86 processors. They explained how to extract the RSA private key in one process … > Preventing branch prediction timing attacks > Filed under: Crypto,Network,Security — Nate Lawson @ 10:06 am > A few years ago, Aciicmez et al published a new timing attack (1, 2, 3) exploiting the branch prediction feature of x86 processors. They explained how to extract the RSA private key in one process by monitoring the behavior of the branch prediction unit in a concurrent spy process. This is an extension of the previous work on improving cache timing attacks (see also Percival and Bernstein). > These kinds of attacks all target microarchitectural features of the processor where a shared resource (I or D-cache, branch prediction buffer) is maintained by the processor across context switches. Any resource that is instruction or data-dependent and can be measured outside the security boundary can potentially be used for side-channel attacks. > Most developers don’t get the security boundary right. Usually, they will consider the whole machine as the boundary. But of course, even this simple concept can be more complicated in practice (say, host vs. guest VM environments). Others consider the OS process boundary as their security boundary. But consider a web server process with built-in SSL. After the SSL decryption, any changes in the performance of the general webserver code due to the cache state of the SSL decryption may reveal information about the private key. Thus, it is important to first draw the security boundary as narrowly as possible. > In a branch prediction attack, the attacker typically runs a spy process concurrently with the cipher. It repeatedly does the following: > ``` > Execute a set of branches > Measure the overall execution time of all its branches > > ``` > Since an RSA decryption happens over a relatively long period of time, the cache and BTB state can be measured multiple times by the spy process during a single decryption. Public key algorithms take longer because they are doing a multi-word computation, and there are often conditional branches based on the private key. Also, the spy process can do various things to try to force the crypto process to context-switch more often. > Last year, I wrote about the patch Intel submitted to mitigate cache timing attacks. The OpenSSL patch they submitted for dealing with branch prediction attacks (“Smooth CRT-RSA”) is also interesting. They created new big number functions BN\_mod\_inverse\_no\_branch() and BN\_div\_no\_branch(), which remove any conditional branches based on information related to the private key. See section 5.3 of their paper for details or just read the comments in the diff above. > The key insight behind these functions is that the extra reduction step can be eliminated if the domain for the value returned by Montgomery-Multiply can be extended. The modulus n in RSA is composed of two primes, p and q. The MMUL algorithm returns a value from [p, 2p). This means the naive implementation performs an optional extra reduction to fit the value into the range [0, p). The patch avoids this reduction by adding an extra word to the parameters passed to MMUL, effectively zero-padding them. Additionally, the Montgomery parameters are increased by n/2 to account for this modified range. > The lesson from all this is that it’s very hard to eliminate side channels, and you have to be careful when defining the security boundary. Even if you used this branchless CRT implementation, you might still be vulnerable to timing attacks if you used a naive algorithm for loading the private key from a file and converting it to binary format in memory (e.g., for loop with atoi()). ---
**Author:** ![allenl](https://avatars.discourse-cdn.com/v4/letter/a/3bc359/32.png) [@allenl](https://forums.sifive.com/u/allenl)\ **Post date:** [January 6, 2018, 1:44am UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965/6 "2018-01-06T01:44:29Z")
**[SiFive Statement on Meltdown and Spectre](https://www.sifive.com/blog/2018/01/05/sifive-statement-on-meltdown-and-spectre/)** Andrew Waterman, Co-Founder and Chief Engineer at SiFive The [recently disclosed](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html) speculation-based timing attacks [Meltdown](https://meltdownattack.com/meltdown.pdf) and [Spectre](https://spectreattack.com/spectre.pdf) have received much attention this week—and rightly so. The vulnerabilities these attacks exploit are not limited to a particular instruction-set architecture, nor are they restricted to a single vendor’s implementations. Many processors that rely upon speculation to improve performance are affected, even some that do not use out-of-order execution. Fortunately, SiFive’s RISC-V Core IP offerings are not affected by Meltdown and Spectre. Meltdown attacks (CVE-2017-5754) rely upon speculative access to memory that the processor does not have permission to access; our processors do not perform this form of speculation. The Spectre attacks (CVE-2017-5753 and CVE-2017-5715) rely upon speculative memory accesses causing cache state transitions; our processors do not speculatively refill or evict data cache lines. As the [RISC-V Foundation’s statement](https://riscv.org/2018/01/more-secure-world-risc-v-isa/) on these vulnerabilities keenly observes, now is the time for open architecture and open hardware designs to shine. Researchers and implementers are already working to develop both architectural solutions and novel microarchitectures that are hardened against this form of attack. We look forward to contributing to this effort. ---
**Author:** ![blubee](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/blubee/32/858_2.png) [@blubee](https://forums.sifive.com/u/blubee)\ **Post date:** [January 7, 2018, 7:11am UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965/7 "2018-01-07T07:11:38Z")
This is good news and like I said before, open source hardware should shine some light on these moldy corner cases. I remember when reading the original rowhammer attack I was thinking, doesn’t anyone see how disastrous thing was for computing. ---
**Author:** ![bruce](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/bruce/32/452_2.png) [@bruce](https://forums.sifive.com/u/bruce)\ **Post date:** [July 12, 2018, 11:06pm UTC](https://forums.sifive.com/t/does-risc-v-dodge-the-plague/965/8 "2018-07-12T23:06:26Z")
In case anyone finds this thread in future, Chris Celio gave a talk in May about ways to design OOO RISC-V cores to prevent such attacks. 90% of the solution is just realising there is a problem. And not having already shipped billions of cores 🙂