> Ibex® is a small and highly configurable open-source RISC-V embedded processor available under an Apache 2.0 licence. It is formally verified and very well validated, and it has excellent toolchain integration, which has led many companies to use it in their commercial SoCs.
> [...]
> Ibex is the main CPU in the OpenTitan® root of trust, which has brought the quality of the design and documentation to new heights.
I worked on OpenTitan for around 5 years at lowRISC. It certainly has its ups and downs but it's generated some great stuff and I'm very glad to see hit proper volume production like this. Whilst there's definitely open source chips out there and lots more using bits of open source that don't actually advertise this fact I believe this is the first chip with completely open RTL that's in a major production volume use case.
One of highlights working on OpenTitan was the amount of interest we got from the academic community. Work they did could actually get factored into the first generation silicon making it stronger. Ordinarily chips like that are kept deeply under wraps and the first time the wider security community can take a look at them development has long completed so anything they might find could only effect generation 2 or 3 of the device.
Academic collaboration also helped get ahead in post quantum crypto. This first generation chip has limited capabilities there but thanks to multiple academics using the design as a base for their own PQC work there was lots to draw on for future designs.
I'm no longer at lowRISC so I don't know where OpenTitan is going next but I look forward to finding out.
This is really great. OpenTitan has some useful IP components that can definitely be reused, and it's really cool that this is open. Nice one Google. I have to minority nitpick though:
> both individual IP blocks and the top-level Earl Grey design have functional and code coverage above 90%—to the highest industry standards—with 40k+ tests running nightly
This is definitely not "to the highest industry standards". I've worked on projects where we got to 100% on both for most of the design. It's definitely a decent commercial standard though - way above most open source verification quality.
Having spent several years working on OT I can tell you that most of the gaps are things that should be waived anyway. Getting waiver files reliably integrated into that flow has been problematic as those files are fragile, alter the RTL and they typically break as they refer to things by line number or expect a particular expression to be identical to when you did a waiver for it.
This has all been examined and the holes have been deemed unconcerning, yes ideally there'd be full waivers documenting this but as with any real life engineering project you can't do everything perfectly! There is internal documentation explaining the rationale for why the holes aren't a problem but it's not public.
I'm not seeking to criticise this product, I think this is a great development.
But, for almost all people this is shifting from one kind of "trust me bro" to .. another. We're not going to be able to formally prove the chip conforms to some (verilog?) model, has no backdoors, side channels, you-name-it. We're in the same place we were, with the same questions. Why do we trust this and the downstream developments? Because we do.
I know people who worked on cryptech, and I definitely had trust in their work, personal commitment to what they did, but that's "who you know" trust. The non transitive quality of this kind of trust is huge.
To be more critical my primary concern will be how deployment of this hardware is joined by significantly less benign design choices like locked bootloaders, removal of sideloads. To be very clear that's a quite distinct design choice, but I would expect to see it come along for the ride.
To be less critical, will this also now mean we get good persisting on device credentials and so can do things like X.509 certs for MAC addresses and have device assurance on the wire? Knowing you are talking to the chipset which signed the certificate request you asserted to before shipping is useful.
These things should be manufactured to be IRIS-compatible. IRIS is the "Infra-Red, In Situ" technique which lets you image the silicon of a chip through the packaging to verify that you don't have a counterfeit.
I'm more worried by the motivation for the whole secure chain. We will not own our devices and the encryption keys will be stored in vault of <ecosystem provider> like MS or Google, free to peruse by the government
The entire push seems to be motivated by actors that want to deny users access to their own devices in thinly veiled promises of "security".
It's basically asking someone to give their company your house keys on nothing more than "trust me bro".
And it's completely opposite of how it should be, it should be my device that I then can give the vendor app limited sandbox that I can access fully, not the other way around.
Look up bunnie's talks about hardware security, its basically impossible, there are too many parts to the chain leading up to the end user holding hardware in their hands that are all attackable.
Another thing to look up here is the bootstrappable.org community. They started at the software layer, how to create binaries from scratch without using any existing binaries. They are also interested in the hardware layer too.
Ah, I see. It's just another fucking tpm, which let's venders approve or deny execution of signed binaries. So more infrastructure to attack general computing.
No, TPMs and HSMs are fundamentally nothing more than secure hardware dedicated to storing private keys in a way that makes accessing the plaintext incredibly hard. All of modern computer security is based on them.
18 comments
[ 3.8 ms ] story [ 33.0 ms ] thread> Ibex® is a small and highly configurable open-source RISC-V embedded processor available under an Apache 2.0 licence. It is formally verified and very well validated, and it has excellent toolchain integration, which has led many companies to use it in their commercial SoCs.
> [...]
> Ibex is the main CPU in the OpenTitan® root of trust, which has brought the quality of the design and documentation to new heights.
So that's neat.
One of highlights working on OpenTitan was the amount of interest we got from the academic community. Work they did could actually get factored into the first generation silicon making it stronger. Ordinarily chips like that are kept deeply under wraps and the first time the wider security community can take a look at them development has long completed so anything they might find could only effect generation 2 or 3 of the device.
Academic collaboration also helped get ahead in post quantum crypto. This first generation chip has limited capabilities there but thanks to multiple academics using the design as a base for their own PQC work there was lots to draw on for future designs.
I'm no longer at lowRISC so I don't know where OpenTitan is going next but I look forward to finding out.
> both individual IP blocks and the top-level Earl Grey design have functional and code coverage above 90%—to the highest industry standards—with 40k+ tests running nightly
This is definitely not "to the highest industry standards". I've worked on projects where we got to 100% on both for most of the design. It's definitely a decent commercial standard though - way above most open source verification quality.
Having spent several years working on OT I can tell you that most of the gaps are things that should be waived anyway. Getting waiver files reliably integrated into that flow has been problematic as those files are fragile, alter the RTL and they typically break as they refer to things by line number or expect a particular expression to be identical to when you did a waiver for it.
This has all been examined and the holes have been deemed unconcerning, yes ideally there'd be full waivers documenting this but as with any real life engineering project you can't do everything perfectly! There is internal documentation explaining the rationale for why the holes aren't a problem but it's not public.
But, for almost all people this is shifting from one kind of "trust me bro" to .. another. We're not going to be able to formally prove the chip conforms to some (verilog?) model, has no backdoors, side channels, you-name-it. We're in the same place we were, with the same questions. Why do we trust this and the downstream developments? Because we do.
I know people who worked on cryptech, and I definitely had trust in their work, personal commitment to what they did, but that's "who you know" trust. The non transitive quality of this kind of trust is huge.
To be more critical my primary concern will be how deployment of this hardware is joined by significantly less benign design choices like locked bootloaders, removal of sideloads. To be very clear that's a quite distinct design choice, but I would expect to see it come along for the ride.
To be less critical, will this also now mean we get good persisting on device credentials and so can do things like X.509 certs for MAC addresses and have device assurance on the wire? Knowing you are talking to the chipset which signed the certificate request you asserted to before shipping is useful.
https://arxiv.org/pdf/2303.07406
Like, for example, the Boachip-1x MCU.
https://www.cnx-software.com/2026/03/04/dabao-board-features...
The entire push seems to be motivated by actors that want to deny users access to their own devices in thinly veiled promises of "security".
It's basically asking someone to give their company your house keys on nothing more than "trust me bro".
And it's completely opposite of how it should be, it should be my device that I then can give the vendor app limited sandbox that I can access fully, not the other way around.
Worked with the OT team at Google years ago and am glad to see this stuff finally taped out.
“Open source” has a very different meaning when it comes to silicon.
Not something I would want to touch.