8 ms·

It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP

It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP.

XMPPwocky 2y ago
What stops an attacker from uploading their own firmware that dumps out everything in OTP?
- ebenupton 2y ago
  Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
  - phire 2y ago
    Do you have any protection against power/clock glitching attacks?
    - geerlingguy 2y ago
      I was reading in I believe the Register article that yes, that's one of the protections they've tested... will be interesting to see if anyone can break it this month!
    - ebenupton 2y ago
      Yes, several approaches. More here: https://x.com/ghidraninja/status/1821570157933912462 https://x.com/ghidraninja/status/1821570157933912462
      - colejohnson66 2y ago
        Unrolled for those without accounts: https://threadreaderapp.com/thread/1821570157933912462.html https://threadreaderapp.com/thread/1821570157933912462.html
robomartin 2y ago
Nice! Thanks for the direct communication BTW. I guess you are very serious about competing with industrial MCU’s. We had to use a 2040 shortly after it came out because it was impossible to get STM32’s. Our customer accepted the compromise provided we replaced all the boards (nearly 1000) with STM32 boards as soon as the supply chain normalized. I hope to also learn that you now have proper support for development under Windows. Back then your support engineers were somewhat hostile towards Windows-based development (just learn Linux, etc.). The problem I don’t think they understood was that it wasn’t a case of not knowing Linux (using Unix before Linux existed). A product isn’t just the code inside a small embedded MCU. The other elements that comprise the full product design are just as important, if not more. Because of this and other reasons, it can make sense to unify development under a single platform. I can’t store and maintain VM’s for 10 years because one of the 200 chips in the design does not have good support for Windows, where all the other tools live. Anyhow, I explained this to your engineers a few years ago. Not sure they understood. I have a project that I could fit these new chips into, so long as we don’t have to turn our workflow upside down to do it. Thanks again.
- ebenupton 2y ago
  It's a fair comment. Give our VSCode extension a go: the aspiration is to provide uniform developer experience across Linux, Windows, and MacOS.
  - robomartin 2y ago
    I will when I get a break. I'll bring-up our old RP2040 project and see what has changed. I remember we had to use either VSC or PyCharm (can't remember which) in conjunction with Thonny to get a workable process. Again, it has been a few years and we switched the product to STM32, forgive me if I don't recall details. I think the issue was that debug communications did not work unless we used Thonny (which nobody was interested in touching for anything other than a downloader). BTW, that project used MicroPython. That did not go very well. We had to replace portions of the code with ARM assembler for performance reasons, we simply could not get efficient communications with MicroPython. Thanks again. Very much a fan. I mentored our local FRC robotics high school team for a few years. Lots of learning by the kids using your products. Incredibly valuable.
ryukoposting 2y ago
You can certainly do that, sure, but any Cortex-M MCU can do that, and plenty of others have hardware AES acceleration that would make the process much less asinine. Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.
- TickleSteve 2y ago
  520K RAM is huge for most typical embedded apps. Most micros are typically around the 48K->128K SRAM.
  - ryukoposting 2y ago
    Define "typical." To my recollection, every piece of Cortex-M firmware I've worked on professionally in the last 5 years has had at least 300K in .text on debug builds, with some going as high as 800K. I wouldn't call anything I've worked on in that time "atypical." Note that these numbers don't include the bootloader - its size isn't relevant here because we're ramloading. If you're ram-loading encrypted firmware, the code and data have to share RAM. If your firmware is 250K, that leaves you with 270K left. That seems pretty good, but remember that the 2040 and 2350 are dual-core chips. So there's probably a second image you're loading into RAM too. Let's be generous and imagine that the second core is running something relatively small - perhaps a state machine for a timing-sensitive wireless protocol. Maybe that's another 20K of code, and 60K in data. These aren't numbers I pulled out out of my ass, by the way - they're the actual .text and .data regions used by the off-the-shelf Bluetooth firmware that runs on the secondary core of an nRF5340. So now you're down to 190K in RAM available for your 250K application. I'd call that "normal," not huge at all. And again, this assumes that whatever you're running is smaller than anything I've worked on in years.
- dmitrygr 2y ago
  > Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years. what are you smoking? I have an entire decstation3100 system emulator that fits into 4K of code and 384bytes of ram. I boot palmos in 400KB of RAM. if you cannot fit your "application" into half a meg, maybe time to take up javascript and let someone else do embedded?

It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP.

XMPPwocky 2y ago

What stops an attacker from uploading their own firmware that dumps out everything in OTP?

ebenupton 2y ago
Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
- phire 2y ago
  Do you have any protection against power/clock glitching attacks?
  - geerlingguy 2y ago
    I was reading in I believe the Register article that yes, that's one of the protections they've tested... will be interesting to see if anyone can break it this month!
  - ebenupton 2y ago
    Yes, several approaches. More here: https://x.com/ghidraninja/status/1821570157933912462 https://x.com/ghidraninja/status/1821570157933912462
    - colejohnson66 2y ago
      Unrolled for those without accounts: https://threadreaderapp.com/thread/1821570157933912462.html https://threadreaderapp.com/thread/1821570157933912462.html

robomartin 2y ago

Nice! Thanks for the direct communication BTW. I guess you are very serious about competing with industrial MCU’s. We had to use a 2040 shortly after it came out because it was impossible to get STM32’s. Our customer accepted the compromise provided we replaced all the boards (nearly 1000) with STM32 boards as soon as the supply chain normalized. I hope to also learn that you now have proper support for development under Windows. Back then your support engineers were somewhat hostile towards Windows-based development (just learn Linux, etc.). The problem I don’t think they understood was that it wasn’t a case of not knowing Linux (using Unix before Linux existed). A product isn’t just the code inside a small embedded MCU. The other elements that comprise the full product design are just as important, if not more. Because of this and other reasons, it can make sense to unify development under a single platform. I can’t store and maintain VM’s for 10 years because one of the 200 chips in the design does not have good support for Windows, where all the other tools live. Anyhow, I explained this to your engineers a few years ago. Not sure they understood. I have a project that I could fit these new chips into, so long as we don’t have to turn our workflow upside down to do it. Thanks again.

ebenupton 2y ago
It's a fair comment. Give our VSCode extension a go: the aspiration is to provide uniform developer experience across Linux, Windows, and MacOS.
- robomartin 2y ago
  I will when I get a break. I'll bring-up our old RP2040 project and see what has changed. I remember we had to use either VSC or PyCharm (can't remember which) in conjunction with Thonny to get a workable process. Again, it has been a few years and we switched the product to STM32, forgive me if I don't recall details. I think the issue was that debug communications did not work unless we used Thonny (which nobody was interested in touching for anything other than a downloader). BTW, that project used MicroPython. That did not go very well. We had to replace portions of the code with ARM assembler for performance reasons, we simply could not get efficient communications with MicroPython. Thanks again. Very much a fan. I mentored our local FRC robotics high school team for a few years. Lots of learning by the kids using your products. Incredibly valuable.

ryukoposting 2y ago

You can certainly do that, sure, but any Cortex-M MCU can do that, and plenty of others have hardware AES acceleration that would make the process much less asinine. Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.

TickleSteve 2y ago
520K RAM is huge for most typical embedded apps. Most micros are typically around the 48K->128K SRAM.
- ryukoposting 2y ago
  Define "typical." To my recollection, every piece of Cortex-M firmware I've worked on professionally in the last 5 years has had at least 300K in .text on debug builds, with some going as high as 800K. I wouldn't call anything I've worked on in that time "atypical." Note that these numbers don't include the bootloader - its size isn't relevant here because we're ramloading. If you're ram-loading encrypted firmware, the code and data have to share RAM. If your firmware is 250K, that leaves you with 270K left. That seems pretty good, but remember that the 2040 and 2350 are dual-core chips. So there's probably a second image you're loading into RAM too. Let's be generous and imagine that the second core is running something relatively small - perhaps a state machine for a timing-sensitive wireless protocol. Maybe that's another 20K of code, and 60K in data. These aren't numbers I pulled out out of my ass, by the way - they're the actual .text and .data regions used by the off-the-shelf Bluetooth firmware that runs on the secondary core of an nRF5340. So now you're down to 190K in RAM available for your 250K application. I'd call that "normal," not huge at all. And again, this assumes that whatever you're running is smaller than anything I've worked on in years.
dmitrygr 2y ago
> Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years. what are you smoking? I have an entire decstation3100 system emulator that fits into 4K of code and 384bytes of ram. I boot palmos in 400KB of RAM. if you cannot fit your "application" into half a meg, maybe time to take up javascript and let someone else do embedded?