Microarchitectural Attacks on Hardware RISC-V CPUs

[Matthias Tarasiewicz]

Not sure if anyone has seen this?

https://news.ycombinator.com/item?id=36670064

Cheers, Matthias

--

Matthias Tarasiewicz

RIAT Embedded R+D

https://linkedin.com/in/parasew

[Don Bailey]

Thanks for shipping this out. This is a good paper and it's the first I've observed it. I only skimmed it, but I need to dive in. 

D

--
You received this message because you are subscribed to the Google Groups "RISC-V Developer Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devboard-commun...@riscv.org.

[Daniel Maslowski]

I have read this, and it shows typical symptoms of hardware/firmware mess:

The authors haven't looked into setting vendor specific CSRs that may partially mitigate the issues. That is sad.

On the other hand, firmware needs to be *easily* accessible and SoCs need *full* *public* documentation for better evaluation.

That said, I have yet to reproduce their work (haven't bothered yet), and then I'd like to see if CSR tweaks can improve things.

[Theo de Raadt]

'Daniel Maslowski' via RISC-V Developer Board Community <devboard-...@riscv.org> wrote:

> The authors haven't looked into setting vendor specific CSRs that may partially
> mitigate the issues. That is sad.

They took on the responsibility of academic review.

They did not take on additional responsibilities. That is fine.

Your mail doesn't contain an actual list of mitigations either...

The lack of rigor in riscv64 product is not surprising; it is not an
emergent property. I do not know of a new product which didn't arrive
with such errors. Future hardware can be better (I won't say "will").