3 ms·

Like the others are "more secured", and it is a bit more complicated than that... lol. Will please ARM FUD on RISC-V (remember than, currently, RISC-V is a deat

Like the others are "more secured", and it is a bit more complicated than that... lol. Will please ARM FUD on RISC-V (remember than, currently, RISC-V is a death sentence for ARM...). That said, is there a way to buy a RP2350 with the ARM cores disabled via hardware right from the start, on which raspberry did not pay ARM royalties?

oytis 2y ago
It's not ARM vs RISC-V per se, it's how RISC-V is implemented in RP2350. But also RISC-V only has a replacement for "big" Trustzone AFAIK, so it might not be easy to bridge RISC-V with Trustzone-M aware bus/peripherals.
- wren6991 2y ago
  RP2350 maps RISC-V M/U modes onto AHB protection attributes equivalent to the v8-M combinations Secure + Privileged and Non-secure + User. The system-level TrustZone-M filters apply to both architectures, since they're simple bus permission checkers (plus some branding), and therefore don't care about the processor architecture. Likewise the RISC-V PMP can divide M-mode and U-mode memory just like the SAU divides Secure and Non-secure memory; the SAU is just another layer of MPU. Secure/Non-secure interrupt targeting can be implemented by de-privileging an M-mode handler head into a U-mode handler tail, etc. You can read more about this stuff in chapter 10 of the datasheet (in particular section 10.6.2 covers the mapping of RISC-V modes to AHB bus attributes), but the short version is that the RISC-V cores have enough security features that you could put together a competent secure boot implementation. Really this attack has little to do with the cores, and everything to do with the fact it is possible to bypass the guard reads in the OTP power-up state machine and read invalid values into the critical flag state. If the flag assignment had been different we would have seen either a different hole -- e.g. direct through Arm Mem-APs into OTP, which perhaps these journalists would blame on the Arm cores -- or no hole.
crest 2y ago
You could argue that it was an oversight by Raspberry Pi to default to the cores without TrustZone if the configuration read from OTP was invalid. It doesn't matter that those cores are RISC-V an ARM -v6M or -v7M core would've worked too.

oytis 2y ago

It's not ARM vs RISC-V per se, it's how RISC-V is implemented in RP2350. But also RISC-V only has a replacement for "big" Trustzone AFAIK, so it might not be easy to bridge RISC-V with Trustzone-M aware bus/peripherals.

wren6991 2y ago
RP2350 maps RISC-V M/U modes onto AHB protection attributes equivalent to the v8-M combinations Secure + Privileged and Non-secure + User. The system-level TrustZone-M filters apply to both architectures, since they're simple bus permission checkers (plus some branding), and therefore don't care about the processor architecture. Likewise the RISC-V PMP can divide M-mode and U-mode memory just like the SAU divides Secure and Non-secure memory; the SAU is just another layer of MPU. Secure/Non-secure interrupt targeting can be implemented by de-privileging an M-mode handler head into a U-mode handler tail, etc. You can read more about this stuff in chapter 10 of the datasheet (in particular section 10.6.2 covers the mapping of RISC-V modes to AHB bus attributes), but the short version is that the RISC-V cores have enough security features that you could put together a competent secure boot implementation. Really this attack has little to do with the cores, and everything to do with the fact it is possible to bypass the guard reads in the OTP power-up state machine and read invalid values into the critical flag state. If the flag assignment had been different we would have seen either a different hole -- e.g. direct through Arm Mem-APs into OTP, which perhaps these journalists would blame on the Arm cores -- or no hole.

crest 2y ago

You could argue that it was an oversight by Raspberry Pi to default to the cores without TrustZone if the configuration read from OTP was invalid. It doesn't matter that those cores are RISC-V an ARM -v6M or -v7M core would've worked too.