06:59 <wbezs[m]> I wanted to share an open-source project that helped me with my thesis, and hopefully, it will help others orchestrating multiple MCUs like ESP32, STM32, or even Nordic Semi.... (full message at <https://catircservices.org/_irc/v1/media/download/Ae1ldWr6BC5IeEtm2Hnqbm30K2rTZKeD-UJWbGWdthguQgy2q4K1GI1s5wCT_cvGBfwKKwHR3jA1GMJQ9YQJDUC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9aQ2pvQ3RQVWZzZXJFTXdSVHlScG1KdnQ>)

07:31 <thejpster[m]> It looks interesting for those who need UART logs. But it seems Linux only and I’m on a Mac.

08:35 <LiamKinne[m]> Does anyone know of anything using a defmt like approach for data visualization?

08:35 <LiamKinne[m]> I've been experimenting with Rerun.io and RTT to expose high-frequency data from the target over the debugger. Should have something cleaned up in a public repo soon.

08:36 <diondokter[m]> LiamKinne[m]: Not sure how you want to intern runtime data...

08:39 <LiamKinne[m]> diondokter[m]: The data isn't interned, just the metadata like names, kind of data, etc.

08:41 <LiamKinne[m]> LiamKinne[m]: This is the wire protocol. The point_id gets expanded into the rerun path like "robot/zed/acceleration" on the host.

08:41 <diondokter[m]> LiamKinne[m]: Can't you just make it so that both sides know about that already? Have a Rust crate that implements datatypes you have. Then on your device serialize it with postcard or something and on the host deserialize it

08:43 <diondokter[m]> diondokter[m]: Or are you building something super generic?

08:45 <LiamKinne[m]> diondokter[m]: I have seen/done that approach for things like event counters but I wanted something with similar ergonomics to defmt.

08:45 <diondokter[m]> LiamKinne[m]: Does the host have the elf file?

08:46 <LiamKinne[m]> diondokter[m]: Yeah yeah this is purely for development work. Not ever something a user would interact with.

08:46 <LiamKinne[m]> diondokter[m]: Hence why it's also over the debug interface and not USB or serial.

08:47 <diondokter[m]> LiamKinne[m]: Well, the way defmt does it is not inherently difficult. You should look at their (expanded) macros and their linker script

08:47 <diondokter[m]> diondokter[m]: In essence you need to duplicate that

08:48 <diondokter[m]> diondokter[m]: But maybe you can reuse defmt? You can create `istr`s and maybe share those? Then defmt will already intern it for you

08:48 <diondokter[m]> diondokter[m]: Ah, but there's no public api to get the index: https://docs.rs/defmt/latest/defmt/struct.Str.html

08:50 <thejpster[m]> diondokter[m]: Can you just use defmt, and get the output from the decoder as JSON (or build your own tool on top of the decoder library)?

08:51 <LiamKinne[m]> thejpster[m]: I should be more clear: I already have something working.

09:01 <LiamKinne[m]> <thejpster[m]> Can you just use defmt, and get the output from the decoder as JSON (or build your own tool on top of the decoder library)?

09:01 <LiamKinne[m]> Right now I'm using separate channels for defmt and my lib. I have my own tool that opens the rtt channels and decodes the info. Both the logs and data points go to rerun.

14:13 <dngrs[m]> Chat, any favorite MCUs with a secure enclave?

14:13 <diondokter[m]> dngrs[m]: Any chip with trustzone?

14:13 <diondokter[m]> Or do you mean anything more specific?

14:14 <dngrs[m]> diondokter[m]: "good Rust support" was kinda implied I guess :V

14:14 <K9001> nRF?

14:14 <K9001> I think they might be the only ones to not get horribly glitched

14:14 <dngrs[m]> (RISCV has nothing then?)

14:15 <K9001> RISC-V doesn't really have a direct TrustZone equivalent

14:15 <dngrs[m]> K9001: thx!

14:15 <diondokter[m]> There's chips with specific enclaves for stuff like keys. So there's probably one out there for RISC-V

14:16 <dngrs[m]> diondokter[m]: Yeah I'm thinking keys; given what K900 wrote, nrf might be the safe bet though

14:16 <K9001> Please don't quote me on that

14:16 <K9001> If you are dealing with that level of attacker

14:16 <thejpster[m]> RP2350 has secure boot, but I don't know how that works on the RISC-V side

14:16 <K9001> I don't think I've seen nRF52 get glitched

14:16 <K9001> But I can't promise you this didn't happen

14:16 <K9001> RP2350 definitely got glitched though

14:16 <dngrs[m]> So to be really specific I was wondering about building a Yubikey equivalent

14:17 <K9001> I think Yubikeys use NXP something something

14:17 <diondokter[m]> Ha well, any chip can be glitched really. Some are just more difficult

14:17 <thejpster[m]> On the Arm side you boot from code you put in OTP, or use the ROM to verify the digital signature of an image in Flash, which the ROM can decrypt and copy to SRAM for execution.

14:17 <K9001> diondokter[m]: Well yes but I have not seen anyone pull it off in practice on nRF52 and I've definitely seen people pull it off on RP2350

14:17 <thejpster[m]> To be fair, Raspberry Pi said "here's free chips and if you can hack them we'll give you ten grand"

14:18 <diondokter[m]> nRF52 doesn't have trustzone btw

14:18 <diondokter[m]> You'd need the 53, 91 or 54 series

14:18 <K9001> Sorry yes nRF53

14:18 <K9001> Brain is mush

14:20 <thejpster[m]> nRF52 APPROTECT has been broken: https://www.hackster.io/news/aaron-christophel-s-open-source-tool-unprotects-reads-and-flashes-any-nrf52-from-an-esp32-94d457b5a885

14:25 <JamesMunns[m]> Didn't they do a silicon rev to address this? I think there's still a lot of old stock of the affected versions though

14:25 <JamesMunns[m]> https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/working-with-the-nrf52-series-improved-approtect

14:25 <JamesMunns[m]> dunno if that one has been broken yet tho

14:29 <JamesMunns[m]> usually (AFAIU) there's a distinction between "lets you run user code/less trusted code, should allow you to prevent access to a bunch of stuff, including potentially secure data" (TrustZone), and "you can store a limited number of crypto keys in a way (usually OTP writes) that aren't easy/possible to get back out in plaintext, even for your firmware, but the hardware will let you do crypto ops (signing/decrypting) with the keys

14:29 <JamesMunns[m]> and give you the result"

14:30 <JamesMunns[m]> I think a lot of devices with the former have the latter

14:30 <JamesMunns[m]> I know dion knows more than me about this and will correct me if I'm totally off base 😃

14:31 <diondokter[m]> I'm definitely not an expert in this area :P

14:31 <diondokter[m]> I was just early-ish with exploring trustzone with Rust

14:32 <diondokter[m]> And also, I don't know what to believe. Every vendor says their chips are super secure, so who knows

14:33 <diondokter[m]> I know NXP is used regularly in these areas. I'm now working with an MCXA device and it has a special place for a 'customer' certificate in the special secret place their ROM bootloader uses

14:34 <diondokter[m]> But I despise that bootloader

14:34 <K9001> I think the latest Yubikeys are Infineon something or other

14:36 <diondokter[m]> If you can store a key in a special key area, that's likely better than in flash with some protection bits turned on

14:36 <JamesMunns[m]> AFAIU, TrustZone allows you to gate access to memory/periphs between "Secure" and "NonSecure" mode, the latter of which can only touch what the former allows. This means that if you manage to exploit NonSecure space, it still can't get access to private keys or modify things. This means you can have a hardened kernel/hypervisor/whatever that mediates access, and doesn't give private data back out ever.

14:36 <JamesMunns[m]>

14:36 <JamesMunns[m]> The "secure storage only" stuff means that you can't really use normal vulns to read back keys, because it's not necessarily even mapped in the addressable memory space, so even if you get access, it won't spit out the key. But, if you have totally pwned the device, you can still make it decrypt/sign things for you. And yeah, usually the secure storage tries to be more resistant to EMI/glitching/decapping than other flash memory.

14:38 <diondokter[m]> Yes, trustzone only protects against bad code execution in the nonsecure area. Nothing else

14:38 <JamesMunns[m]> When dngrs said "enclave", it definitely sounded like TrustZone to me, but I dunno if that's what was needed or just "I wanna put secrets somewhere safe".

14:41 <diondokter[m]> Secure Enclave is also often the name for those external chips you can send bytes to to haven de/encrypted IIRC

14:41 <diondokter[m]> *

14:53 <dngrs[m]> protected storage is a good first step, on top of that it would be nice to have protection against malicious firmware that tries to brute force keys (e.g. yubi firmware will delete private keys after like 7 consecutive failed pin entries, a modified firmware could omit that deletion)

14:53 <dngrs[m]> s/protection/mitigations/

14:54 <dngrs[m]> (or maybe it won't delete straight away but require a PUK unlock)

14:54 <JamesMunns[m]> There's _also_ sometimes support for the hardware bootloader to only load firmware images signed with keys stored inside the secure enclave

14:54 <dngrs[m]> yeah, was thinking signed firmare

14:54 <JamesMunns[m]> again, sort of chip dependent more than a general thing

14:54 <JamesMunns[m]> protip: if you're ever going to do that, buy a couple spare dev boards

14:55 <dngrs[m]> that's why I asked :) I guess nrf53/54 is worth checking out

14:55 <JamesMunns[m]> everyone I know who has ever worked on any kind of secure boot process has accidentally hard-locked themselves out of a board or three during development

14:56 <JamesMunns[m]> sometimes there's a "pretend we're fused to secure but it's actually still revertable" for development, but usually once you fully burn the "okay secure forever" bits, there's no coming back, and you'd better hope whatever you put in there works right

14:59 <dngrs[m]> yip, very good point, cheers - I think stubbing out the hardware security part and getting all that out in the open and community audited would probably be my first step, after that it gets interesting/expensive mistake territory :v

15:04 <i509vcb[m]> Please vendors do not put these bits in your main flash. It's very easy otherwise to brick a chip by complete accident

15:44 <thejpster[m]> STM32U5 will happily reset the Option Bytes (including the TrustZone enable bit) using ST Cube Programmer, but probably not the keys in OTP.

15:51 <LiamKinne[m]> <i509vcb[m]> Please vendors do not put these bits in your main flash. It's very easy otherwise to brick a chip by complete accident...

15:51 <LiamKinne[m]> Discovered this trying to get Rust up and running on an NXP S32K which has this. Spent about 100$ on micro-controllers before I threw in the towel.

15:54 <LiamKinne[m]> * Discovered this trying to get Rust up and running on an NXP S32K which has this. Spent about $100 on micro-controllers before I threw in the towel.

16:04 <i509vcb[m]> <LiamKinne[m]> Discovered this trying to get Rust up and running on an NXP S32K which has this. Spent about 100$ on micro-controllers before I threw in the towel.

16:04 <i509vcb[m]> I have killed a S32K11x board that way as well...

17:04 <LiamKinne[m]> Here's the prototype of what I was discussing before: https://github.com/umi-eng/devis

17:04 <LiamKinne[m]> I think I broke the defmt logger but otherwise it works great.

21:47 <az1[m]> <LiamKinne[m]> Discovered this trying to get Rust up and running on an NXP S32K which has this. Spent about 100$ on micro-controllers before I threw in the towel.

21:47 <az1[m]> kit was working on that btw. Last I heard he had started splitting things up into a proper PAC and HAL.

21:48 <az1[m]> * kit was also working on

21:49 <az1[m]> The RA chips that put their option memory (all 40 bytes of it) in the middle of flash will happily lock you out of the debugger if you zero out the wrong thing. Absolutely infuriating.