Hacker News Reader

Comment by Findecanor | Hacker News Reader

The title makes it sound as if RISC-V is a liability. The liability lies in it being possible to reactivate cores that were supposed to have been permanently disabled.

View on HN

The RISC-V implementation on RP2350 does not have any security features - it has no business to be on silicon that was supposed to be marketed for security features, but it is there. Then there are bits to disable ARM and/or RV cores, but disabling the ARM core takes priority over disabling insecure RV core - these are human decisions not architectural.

This isn't about the technology - the organization's priorities are clearly divided between two segments - one that's trying to expand the revenue by expanding into enterprise/commercial market and another that is trying to stick-on cool stuff and prioritizing fun. In this case neither won - the fun guys got kneecapped by the E9 bug making this silicon unusable for hobbyist projects, and the fun stuff kneecapped the enterprise stuff by bypassing the security bit.

(as you can imaging, I'm extremely disappointed with RP2350 - RPi needs to focus or they hobby/maker market is done)

If the RISC-V cores were removed, the bit assignment for the critical OTP flags would be different. Quite likely this attack would then have directly enabled Secure debug access to the Arm cores.

Whoever wrote that headline lacked even a cursory understanding of the attack. You can do better by watching Aedan Cullen's excellent 38C3 presentation for yourself.

It seems a product that sells for $7 pushes security validation all the way to the right - the customers.

The RISC-V cores are innocent accomplices. Having a mix of cores with and without secure boot gives attackers more tool to play with. The exploit works because if both sets of cores are "permanently" disabled the hardware state machine instead of bricking the chip starts the RISC-V cores. Just defaulting to the ARM cores would've prevented this exploit from working.

It also looks like the chip designers didn't know about the read-persistence between the validation pattern reads and the actual configuration reads achievable by glitching only the OTP memory block (the USB peripheral isn't enabled at this stage). Without access to the documentation for the OTP memory block we can only guess who deserves the most of the blame for this oversight.

Reply on news.ycombinator.com