[Cryptography] Does RISC V solve Spectre ?

Tom Mitchell mitch at niftyegg.com
Fri Mar 23 19:44:54 EDT 2018


On Tue, Mar 20, 2018 at 11:52 AM, Henry Baker <hbaker1 at pipeline.com> wrote:
> Someone has claimed to me that RISC V completely "solves" the Spectre problem.
>
> I'm still dubious.  Perhaps it is a derivative/modification of RISC V ?
> Is there any in-depth analysis of RISC V & Spectre online somewhere?

At one level RISC V is an instruction set.
https://riscv.org/
The problem is not with the instruction sets as much as it is the way the
processor is implemented.
These folk https://www.sifive.com/ at SiFive can say that their RISC V part
has eliminated the issue (may never have had it).
https://www.sifive.com/blog/2018/01/05/sifive-statement-on-meltdown-and-spectre/

RISC-V says..
https://riscv.org/2018/01/more-secure-world-risc-v-isa/
"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."
So someone could build a bad part but has not done so and put it on the market.

One way to add problems is with memory subsystems that have their own cache.
Another interesting mitigation to go fast might be to move the kernel
into a PCI card
that has access to memory but the OS lives on a part on that board.
The old time sharing systems had the OS live on a channel processor.
Some modest design tricks could make this a lot easier.

Some of the exploits in the  Meltdown and Spectre pair seem to be a
race condition
where the negation or validation of cache or prefetched data are invalid.
The inverse of overclocking could close those timing windows if they
are race-conditions.
DRAM interfaces may also be detuned (slowed) to close race-conditions.
BIOS updates control come of these clock timing settings... Look for
BIOS updates
and "overclock vs. saferclock" settings.

Interesting stuff.



-- 
  T o m    M i t c h e l l


More information about the cryptography mailing list