Hacker News Reader

Comment by freedom-fries | Hacker News Reader

RP2350 was supposed to be a game-changer for the RPi (the corp) and customers alike. It's an immensely powerful, and well documented platform so it's a shame that critical bugs have stolen the thunder. First the E9 errata made me junk the RP2350 for projects where I needed to interface with any kind of tri-state logic and now this one basically shows that extra RISC-V cores are a liability for any security conscious design.

If Rpi wants to rescue RP2350, they must release a new bug-fix stepping soon, or this one is done.

View on HN

> E9 errata made me junk the RP2350 for projects where I needed to interface with any kind of tri-state logic

Do whatever floats your boat; the rest of us just uses the documented work-around [1], i.e. either use internal pull-up or an external pull-down resistor on the bus. Note that while tri-state devices are common, it is rarely a good idea to leave a bus line floating.

As for the OTP security retrieval: high security projects, e.g. 2nd factor authorization fobs seem to be out, bummer. Another important use case I'd think are small market specialized devices for which the manufacturer wants to delay the distribution of intellectual property, e.g. by encrypting part of the code. For that the functionality seems still sufficient.

[1] https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...

Afaik the internal pull-up/-down resistors aren't strong enough to stay outside of the problematic input voltage range and external ≤ 8kΩ resistors to 3.3V aren't acceptable unless you don't care about power consumption and your signal is still usable like that. It's a really annoying problem to have. I'm still waiting for a hardware revision that fixes the source of the problem instead of nasty workarounds.

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.

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.

I'm annoyed they didn't bother to add floating point maths to the RISC-V cores. Its useless and that E9 bug is definitely an issue.

Most microcontrollers sold don't have hardware floating point, but they seem to be useful. I'd bet the Cortex M0 and M3 vastly outsell the M4F.

The RP2040 didn't have floating point. It is/was popular.

It's annoying but makes sense for a simple state machine / sequencer core.

Reply on news.ycombinator.com