Brings back memories of late nights trying to reverse engineer the Abit uGuru chip. Triggered by not being able to read the sensors in Linux while trying to overclock my computer into being less of a shit computer.
Reverse engineering was successful but the computer never got any better. Still, fun and educating times it was!
Yes, on hal level there will be a bunch of unsafe. On firmware application level it's not often I find the need to reach for unsafe though. It would typically be if the hal is lacking in some sense.
I was a bit taken aback when I realized that Embassy's low-level PAC crates expose all of the devices raw registers through "safe" interfaces though. I'm pretty sure that letting you configure DMA engines arbitrarily at any time is not in the spirit of safe Rust. AFAIK their high-level HAL crates do aim to be properly safe but their PAC approach makes me nervous.
Usually the HAL is between the main firmware and the PAC, so whether the PAC methods are marked as unsafe could almost be considered an implementation detail.
But yes, there has been a lot of discussion around how to handle DMA peripherals - the embedded_dma crate offers some abstractions that I've found handy.
I have replaced my use of C (and C++) in embedded with Rust for the last couple of years. Sure, some parts are still missing or immature, but overall also very promising.
And I do enjoy it so much more than the MCU manufacturer's please-insert-your-c-code-between-these-comments-and-pray kind of development.
Diffie-hellman would not be enough if there is a MITM at the time of the exchange, would it?
Somehow the control panel and the reader must authenticate each other. I'm no security expert but only way I can think of is to use some pre-shared key. A key set via a trusted side channel, or at a time when the osdp channel is known to not be intercepted.
I guess the default key is a problem too. Mainly since it might trick developers/manufactures that this somehow makes the key exchange secure if you use it while setting a device unique key.
I do work with OSDP devices and I have heard this argument from manufactures, like "we only support setting a new key while using the default key, it's more secure that way".
While it, at best, will just obfuscate the process.
Built this cdc tool for software update of embedded (Linux) systems and have deployed it with good enough performance on a couple of arm CPUs; https://github.com/oll3/bita
Though main goal has been keeping data usage low rather than speed up.
Not that this kind of stdin reading operation is something I do often. But at least the Rust code says what it does. Bitshifting stdin by a string on the other hand... Does it read a line, or forever, or read at all? I wouldn't call it the ultimate syntax for a line reader anyway. :)
Btw, binary formats can also be compressed though it typically won't yield the same compression ratio as similar json would since there will be less repeation in the binary format.
