Ask HN: Is Spectre just as likely with RISC-V? | Hacker News Reader

Ask HN: Is Spectre just as likely with RISC-V?

6 pointsblitmap2 comments

I am very unrelated to CPU design. There are a lot of us hoping RISC-V will be in our future computers.

As I understand it, processors from AMD and Intel are quite liberal with the x86 instruction set. They [can] act like complex virtual machines which re-order and tentatively execute later instructions against known data in the hopes this will be used (if the right branch is taken). This can offer better performance, but the issue is information being leaked unintentionally when that path isn't taken.

1) Would we be in the same boat with RISC-V?

2) Are RISC-V processors even "there yet"? Are there RISC-V processors currently doing speculative execution?

3) Is there anything in the RISC-V spec that makes something like Spectre less likely to happen? Does the RISC-V instruction set lend itself in some way to make Spectre less possible? A [believed] benefit of RISC-V is that with a reduced instruction set, things become easier to reason about.

4) Is speculative execution even a goal for RISC-V? Can a reduced instruction set offer optimization opportunities that make speculative execution not worth the risk? Can RISC-V be competitive without it? (much speculation here)

Again, I am very uninformed. I think we'd be in the same situation but I thought I'd ask.

(Thank you for entertaining my hypothetical?)

"BOOM is currently susceptible to [Spectre], but a number of relatively simple, low-impact changes to the BTB/BPD structure (such as flushing or tagging) can guard against Spectre." https://groups.google.com/forum/#!topic/riscv-boom/yxDwmpjtQ...

Note that BOOM is the only RISC-V processor that's close to being high performance.

Answering the items for which I have something to contribute:

> 1) Would we be in the same boat with RISC-V?

If the hardware used the same style of speculative execution, without full cleanup when a miss-speculation happens, yes.

> 3) Is there anything in the RISC-V spec that makes something like Spectre less likely to happen?

Spectre is related to performing speculative execution without fully cleaning up all possible side effects of miss-speculation. Processor architecture spec's typically say nothing about speculative execution, because speculative execution is supposed to be a transparent performance enhancement. It turns out to not be so transparent, but the result is that unless the RISC-V spec. specifically disallowed any speculative execution, ever, a particular hardware implementation could be just as vulnerable. And even if the spec. disallowed speculative execution, there is no way to prevent a particular designer from building it into their CPU hardware design.

> 4) Is speculative execution even a goal for RISC-V?

It is unlikely the RISC-V spec. has anything to say about speculative execution. It would be up to a particular CPU designer to decide to implement a particular RISC-V chip with speculative execution for performance reasons in their particular design.

> Can a reduced instruction set offer optimization opportunities that make speculative execution not worth the risk?

A RISC instruction set is often more amenable to speculative execution designs because of its regularity, lack of special cases, and typical adherence to register to register operations with memory accesses only occurring for explicit load/stores. So it is possible that speculative execution for a RISC architecture is a larger performance booster than for a CISC CPU.

> Can RISC-V be competitive without it?

Given how far Intel has pushed x86, largely by ever more aggressive speculative execution, it is unlikely any CPU design without speculative execution can be competitive on a raw performance basis.

Now, a particular RISC-V chip might be "fast enough" without speculative execution for a large majority of tasks most users put their computers to (most CPU's sit around idle waiting for the user to do something 99.9% of the time). But for raw performance needs (video encoding, 3D gaming, etc.) it would likely not be competitive.

Reply on news.ycombinator.com