State of RISC-V Security: November 13 2023
An attempt to breakdown state of RISC-V
This isn’t intended to be a comprehensive look at RISC-V security. I’m not in any companies with inside knowledge but a gathering of news articles I’ve come across from my interest as a hardware security enthusiast.
Adoption
Back at the end of October, Google released the update on RISC-V support for Android via this blog post: Android and RISC-V: What you need to know to be ready. This brought back some found memories of when I started working on Android back in 2007 before any devices were out and I was demoing POSIT on the emulator on my laptop. This is huge now. Android is a big ecosystem and seeing this level of readiness in an open source device means that a manufacturer building on RISC-V can legitimately target to run Android.
I’d love to see if there are any devices coming soon that can run Android.
AMD - MicroBlaze V
AMD released the MicroBlaze V based on RISC-V as a IP to build. Developers can target the MicroBlaze V processor to any AMD adaptive SoC or FPGA device supported by the Vivado Design Suite at no extra cost.
This looks very cool and likely competitive with SiFive’s design offering too.
SemiDynamics Tensor Unit for AI
Semidynamics has released a fully customizable 64-bit RISC-V processor, as well as an accompanying Tensor Unit for AI applications. Semidynamics collaborated with Signature IP to develop a multicore environment and coherent hub interface interconnect for the processor, which allows for deep customization of cores. The Tensor Unit is designed to integrate with Semidynamics' Vector Unit and Gazzillion technology to provide outstanding AI performance and simplify AI software development. The use of RISC-V in AI applications could lead to improved performance and power efficiency.
Regulation
Trouble Brewing For RISC-V As Issue Of Technology Transfer Is Questioned
Summary: A group of US politicians is petitioning the White House to restrict the transfer of Intellectual Property (IP) to RISC-V, a relatively minor player in the world of CPU instruction set architectures, as they believe it may benefit adversaries like China. Andrew 'bunnie' Huang, (I’ve featured his amazing writing on open source hardware security in past issue) has written an open letter to the US President, pleading not to restrict US citizens from dealing with the Switzerland-based RISC-V organization. The article also notes that California-based RISC-V startup, SiFive, has announced layoffs of 20% of its workforce, which could mean that US citizens would be forbidden from contributing to this ISA and surrounding ecosystem, depending on how the restriction is implemented.
Seems other news media have picked up Bunnie’s post too
The Register: Hardware hacker: Walling off China from RISC-V ain't such a great idea, Mr President
NBC News: 'I've Felt My Rights Chilled': Hacker 'bunnie' Huang Is Challenging the Government
It’s very important to voice our opinion on this like Bunnie has done. I don’t think attempting to restrict an open standard is very effective, especially one that’s extensible. There’s already fragmentation in RISC-V, lets not end up with a China and US forks of standards.
Software and Hardware
Earliear this year, Debian officially added support for RISC-V and you can even download ubuntu in handful of chips
CHERI
CHERI(Capability Hardware Enhanced RISC Instructions) is a deep rabbithole and while not exclusive to RISC-V, it’s in a good place to be supported by default unlike ARM chipsets which are backporting some of the features in the form of Memory Tagging Extensions. Google Project Zero has a good series on MTE - Part 1, Part 2, Part 3, and more recent on Pixel 8’s support of MTE.
I hadn’t heard of CHERI till recently - so I looked for what’s different between MTE and CHERI, and this Microsoft article on it was helpful.
https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris
The security of MTE, unlike CHERI, depends on secrets (the colors) and does not prevent pointer injection. MTE can deterministically mitigate linear overflows but, if an attacker can leak the color of a particular address (for example, by reading an existing pointer or using a speculative side channel to disclose it), then they can inject a pointer that MTE will consider valid.
What happens if you have both? CHERI protects against guarded manipulation and so makes it possible to restrict the rights to recolor memory to the memory allocator (or the owner of any given piece of address space) and prevents pointer forging, including preventing recoloring pointers. CHERI also provides bounds checks, removing the MTE requirement that two adjacent allocations must have different colors (to protect against linear overflows). In a system supporting both, recoloring memory immediately on deallocation protects against use after free, including allowing the allocator to safely store metadata in freed objects. Through using performance data from Morello, we will be able to explore research questions such as whether this would allow us to implement CHERI revocation more efficiently.
A Rusty CHERI - The path to hardware capabilities in Rust
This FOSDEM 2023 talk provides a vision of future where we have a Rust compiler for CHERI architectures. Link
Now that we also have Ferroscene also officially qualified, maybe the road is clearer for using rust for mission critical systems where safe rust with CHERI hardware can be used too.
Miscellaneous
I thought the 2022 RISC Summit keynote was great
“RISC-V is Inevitable”—A Tale of Two RISC-V Summit Keynotes
This site has documented attempts of trying to boot OS'es on RISC-V chips
Ox64 BL808 RISC-V SBC: Booting Linux and (maybe) Apache NuttX RTOS
RISC-V Ox64 BL808 SBC: Starting Apache NuttX Real-Time Operating System
Dr. Ian Cutress has great analysis here on what’s going on with SiFive
Thanks for reading,
Enjoy!