Live data from Hacker News

Exploiting Undocumented Hardware Blocks in the LPC55S69

oxide.computer

11–18 of 18 posts

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#11
post #7

I am the author of the STM32F1 FPB security bypass exploit. Seeing this happen again, with another manufacturer, but this time with undocumented silicon, is just appalling. They will never learn. At least NXP replied to the email... I never got a reply from ST.

I'm halfway through your `One Exploit to Rule them All?` paper [1], and my jaw is on the floor. I mean... wow. I knew it was bad, but this really is ridiculous.

[1] https://www.usenix.org/system/files/woot20-paper-obermaier.p...

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#12

Given their stated goals, it seems odd to me that Oxide would even consider a chip with proprietary blobs; are there not good open options available?

Suggestions very much welcome! Unfortunately, this space does not really have any good open options: certainly, there is no ARM MCU that meets our security constraints and also has open firmware. (Indeed, there is no ARM MCU that I am aware of that has a completely open ecosystem; all of them have some proprietary bits, though some less than others.) Longer term, we are bullish on RISC-V, but it's not there yet with…

Unfortunately, going one layer down, most ASIC tooling is extremely opaque about what it does, and it's hard to share chip designs that are open at all levels (you may have open-source verilog, but the GDSII might have to be closed-source due to vendor NDAs). I suspect that if you have problems with FPGA tooling, you will also have problems with ASIC tooling.

However, the cost of an ASIC on an older node (~65-130 nm) is a lot lower than you think. There are (bad) free design tools and even older nodes may have open PDKs from foundries (the old scalable CMOS processes).

I have been considering starting up a company to build hardware root-of-trust chips along the lines of Titan/Cerberus,but I don't know if there's enough of a customer base out there to make it a reality.

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#13

Given their stated goals, it seems odd to me that Oxide would even consider a chip with proprietary blobs; are there not good open options available?

Suggestions very much welcome! Unfortunately, this space does not really have any good open options: certainly, there is no ARM MCU that meets our security constraints and also has open firmware. (Indeed, there is no ARM MCU that I am aware of that has a completely open ecosystem; all of them have some proprietary bits, though some less than others.) Longer term, we are bullish on RISC-V, but it's not there yet with…

You might be interested in what Anton Blanchard has been up to with the power ISA soft cores, it seems like his work has spanned the bulk of the FPGA toolkits, and I think his latest is taped out for the SKY130 run. His work is also being adapted for an openBMC replacement, which would offer an opportunity to dust off some old Xzibit templates, so thats good.

https://github.com/antonblanchard/microwatt

https://github.com/antonblanchard/chiselwatt

https://www.efabless.com/projects/29

https://gitlab.raptorengineering.com/kestrel-collaboration/k...

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#14

Given their stated goals, it seems odd to me that Oxide would even consider a chip with proprietary blobs; are there not good open options available?

Suggestions very much welcome! Unfortunately, this space does not really have any good open options: certainly, there is no ARM MCU that meets our security constraints and also has open firmware. (Indeed, there is no ARM MCU that I am aware of that has a completely open ecosystem; all of them have some proprietary bits, though some less than others.) Longer term, we are bullish on RISC-V, but it's not there yet with…

I’m working with a lot of IoT and more complex autonomous systems, and would really like to have something that’d perform as a local root of trust. The NXP still seems one of the better options presuming they actually fix the CVE. There’s likely others like me as well. If Oxide made an open chip with an appropriate PUF I’d love to be able to buy it!

Or perhaps the Raspberry Pi folks could be talked to adding one to their Pico boards. ;)

P.S. TI also has trust zone chips, all NDA bound, but various levels of open source firmware.

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#15
post #4

It's really unfortunate that hardware vendors are obsessed with shipping closed source firmware and ROM. Fortunately there's been a slow and steady buildup of pressure as open source has started being pushed lower into the stacks. Great to see Oxide Computers pushing on this. The rest of the NXP software stack is pretty open. Overall the LPC55S69 chips are pretty impressive chips! They have dual cores with plenty of…

If they shipped with open source firmware, you would have a number of companies copying it and using in their products undercutting the original manufacturer. The US and the West don't have teeth when it comes to IP violations in Asia.

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#16
post #4

It's really unfortunate that hardware vendors are obsessed with shipping closed source firmware and ROM. Fortunately there's been a slow and steady buildup of pressure as open source has started being pushed lower into the stacks. Great to see Oxide Computers pushing on this. The rest of the NXP software stack is pretty open. Overall the LPC55S69 chips are pretty impressive chips! They have dual cores with plenty of…

If they shipped with open source firmware, you would have a number of companies copying it and using in their products undercutting the original manufacturer. The US and the West don't have teeth when it comes to IP violations in Asia.

If you can't do anything against IP violations, closed source doesn't exactly protect you from clones (the range of reverse engineering/firmware extraction services available is impressive). It'll slow them down, but also gets in the way of your legit customers.

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#17
post #16

Earlier quoted context omitted.

If they shipped with open source firmware, you would have a number of companies copying it and using in their products undercutting the original manufacturer. The US and the West don't have teeth when it comes to IP violations in Asia.

If you can't do anything against IP violations, closed source doesn't exactly protect you from clones (the range of reverse engineering/firmware extraction services available is impressive). It'll slow them down, but also gets in the way of your legit customers.

That is true, but without source code the violators cannot improve "their" products much nor give any meaningful updates, so the original manufacturer can still have an edge. If sources were available, the violators could even make it better than original, without having to make even remotely the same R&D investment than original manufacturer.

Re: Exploiting Undocumented Hardware Blocks in the LPC55S69

#18
post #16

Earlier quoted context omitted.

If you can't do anything against IP violations, closed source doesn't exactly protect you from clones (the range of reverse engineering/firmware extraction services available is impressive). It'll slow them down, but also gets in the way of your legit customers.

That is true, but without source code the violators cannot improve "their" products much nor give any meaningful updates, so the original manufacturer can still have an edge. If sources were available, the violators could even make it better than original, without having to make even remotely the same R&D investment than original manufacturer.

Not sure this applies much for the ROM's on microcontroller. They're pretty small and mostly handle very low level details so there doesn't seem much space for meaningful improvement. Even when the firmware is completely open, the original firm often maintains a competitive edge because they have the know how to work with the code base and rest of the chip. Ideally they have internal simulation tools, a broad range of expertise, etc. The firmware often doesn't contain as much "secret sauce", but does contains lots of possible vulnerabilities or bugs for customers.
Post reply on HN