RISC-V Foundation Issues Statement on Spectre, Meltdown Exploits

[Raevenlord]

Recent articles in the media have raised awareness around the processor security vulnerabilities named Meltdown and Spectre. These vulnerabilities are particularly troubling as they are not due to a bug in a particular processor implementation, but are a consequence of the widespread technique of speculative execution. Many generations of processors with different ISAs and from several different manufacturers are susceptible to the attacks, which exploit the fact that instructions speculatively executed on incorrectly predicted code paths can leave observable changes in micro-architectural state even though the instructions' architectural state changes will be undone once the branch prediction is found incorrect. 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.





While these two vulnerabilities are independent of the ISA, they are just the most recent examples to showcase how the devices we use and trust every day are subject to a barrage of attacks from sophisticated adversaries. Each new attack causes architects to scramble to develop hardware and software mitigation techniques, but fixes are considerably more difficult to develop and verify when dealing with legacy architectures that come from a time before security was a zeroth-order concern. As we power up more intelligence everywhere, we need to develop new robust security approaches instead of just papering over the cracks in existing designs.

The RISC-V community has an historic opportunity to "do security right" from the get-go with the benefit of up-to-date knowledge. In particular, the open RISC-V ISA makes it possible for many different groups to experiment with alternative mitigation techniques and share results. The RISC-V Foundation was formed with an open and inclusive governance model to allow for contributions from leading experts across academia and industry. Witness how the processor security research community (DARPA SSITH RISC-V-based program) is standardizing around RISC-V because it is simple and open.



Together, we are unleashing a new innovation frontier by developing the extensible RISC-V ISA available for all to use in various micro-architectural incarnations across all forms of computing devices.

View at TechPowerUp Main Site

 

[bug]

Imho the issue here is not the age of x86 as this statement seems to imply, but the countless layers on top of what was once a clean and simple architecture.
For comparison, just look at where JS started and where it is today. There are (sound) reasons for why we do this time and again, but once we figure out a way to become more agile and embrace change more quickly, we'll all be in a better place.

 

[TheoneandonlyMrK]

Imho the issue here is not the age of x86 as this statement seems to imply, but the countless layers on top of what was once a clean and simple architecture.
For comparison, just look at where JS started and where it is today. There are (sound) reasons for why we do this time and again, but once we figure out a way to become more agile and embrace change more quickly, we'll all be in a better place.

Pre (emption google predictive text had me over) execution is a direct use of hardware to try and accelerate the performance of code ,, it's not per say a requirement of running x86 but it's performance was worth the development.
At the end of the day some very clever guy's learned something new about a side flaw in architectural development, most chip companies will be able to address this in hardware quite quickly some like Risc mitigated it by design already but with this being RISC it cant play crysis either so im ok with it not melting or spectering while it runs hard disks etc thanks Risc-V

 

[nem..]

Risc-V is great, really want to see it do well. About that technique of speculative execution i found this:

Translated; the loss of performance for data centers of 30% is insurmountable because the failure in the architecture of intel is at the level of hardware because the cpu intel try to predict what the user will execute to increase performance and through these speculations grant access to functions and privileged data protected in the system kernel

 

[First Strike]

I'm not that familiar with RISC-V, but I don't understand why an ISA architecture can be less susceptible to a microarchitecture flaw, as microarchitecture implementation is quite unrelated to ISA. Can't a RISC-V processor add a speculative feature?

And the statement itself is quite ambiguous. It just said "no existing RISC-V processor is vulnerable", "one of our microarchitecture does not do speculative access". But is it just because RISC-V community haven't found a decent speculative implementation yet?

Disclaimer: if RISC-V does have certain features that work around specualtive execution, all of above statements are annulled.

 

[close]

I'm not that familiar with RISC-V, but I don't understand why an ISA architecture can be less susceptible to a microarchitecture flaw, as microarchitecture implementation is quite unrelated to ISA. Can't a RISC-V processor add a speculative feature?

And the statement itself is quite ambiguous. It just said "no existing RISC-V processor is vulnerable", "one of our microarchitecture does not do speculative access". But is it just because RISC-V community haven't found a decent speculative implementation yet?

Disclaimer: if RISC-V does have certain features that work around specualtive execution, all of above statements are annulled.

There's no guarantee. They're just taking the opportunity to get free publicity. Implementation bugs could still sneak in and be detected years later. Open doesn't necessarily mean secure. And Heartbleed is the best example, with the bug going undetected for years despite being totally out in the open. In theory issues "can" be identified faster. In practice they're not. You just get the promise and everybody sits calmly assuming someone else is looking at it.

I'm not saying that open is bad, or that RISC-V is bad, just that these guys just want to ride the wave and promote their name a little. They bring very little real world, concrete benefits. Only paper ones. I'm pretty sure that if a bug were to be found in a RISC-V CPU used as widely as x86 is it would have the exact same impact.

 

[XiGMAKiD]

They're just taking the opportunity to get free publicity.

TL;DR

 

[Vya Domus]

IBut is it just because RISC-V community haven't found a decent speculative implementation yet?

Pretty much , if they do want to turn this into an actual competitor to ARM and x86 they will have to include things like out-of-order execution but that isn't up to the people behind RISC-V bur rather to the ones that will implement it.

 

[MrMilli]

The article says itself: 'no announced RISC-V silicon is susceptible'. That doesn't mean the instruction set isn't, it's just that all announced cores are pretty simple cores that don't perform memory accesses speculatively. They're, simply said, just lucky no high performance core were developed yet.

While MIPS is not vulnerable to Meltdown. Linux on MIPS can not leak any kernel pages -- simply because MIPS does not do paging in kernel mode.
I would say from everything I've read, MIPS seems to be the grand winner here.

 

[moonscape]

Imho the issue here is not the age of x86 as this statement seems to imply, but the countless layers on top of what was once a clean and simple architecture.
For comparison, just look at where JS started and where it is today. There are (sound) reasons for why we do this time and again, but once we figure out a way to become more agile and embrace change more quickly, we'll all be in a better place.

I don't understand those statements. Those "countless layers" of complexity on top of the original architecture have taken time to accumulate. Like sediments building mountains.

You must be the first person I have heard to say x86 was ever a "clean and simple architecture". Ever since the launch of the 16 bit x86 it has been ridiculed by processor designers and users alike.

Back in the days when the 286 was a new thing, we had a fat document, under NDA, describing all the errors in that chip. Most of them were ways to break the protected memory model.

Javascript is neither here nor there. Certainly JS has sprouted some new features in recent years. After years of stagnation. It's basically the same old JS.

It is change that has brought us to this situation. By wanting to be more "agile", whatever that is, you are asking for more change, faster, with more un-thought through consequences.

 

[bug]

I don't understand those statements. Those "countless layers" of complexity on top of the original architecture have taken time to accumulate. Like sediments building mountains.

You must be the first person I have heard to say x86 was ever a "clean and simple architecture". Ever since the launch of the 16 bit x86 it has been ridiculed by processor designers and users alike.

Back in the days when the 286 was a new thing, we had a fat document, under NDA, describing all the errors in that chip. Most of them were ways to break the protected memory model.

Javascript is neither here nor there. Certainly JS has sprouted some new features in recent years. After years of stagnation. It's basically the same old JS.

It is change that has brought us to this situation. By wanting to be more "agile", whatever that is, you are asking for more change, faster, with more un-thought through consequences.

x86 has always been criticized for being CISC instead of RISC, that much is true. But the fact that 40 years later it's still with us means it wasn't that bad.
And those "countless layers" refer to pipelining and superscalar design which just an attempt to mimic RISC while keeping the x86 compatibility. SIMD. Layered caches.
For comparison ARM doesn't have those problems, they fielded a clean new design and took the smartphone market by storm. Intel was never able to make a dent in that market, even with their superior fabs.

And I agree with that last part, that's why I said "once we figure out a way to become more agile", because I'm fully aware we need the means and tools to build and verify new designs and architectures before we can afford to switch them altogether.