Friday, January 5th 2018
RISC-V Foundation Issues Statement on Spectre, Meltdown Exploits
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.
Source:
RISC-V Foundation
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.
10 Comments on RISC-V Foundation Issues Statement on Spectre, Meltdown Exploits
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.
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:)
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
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.
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.
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.
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.
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.