3 ms·

> Selling EV charging products based on Raspberry Pi, which is a prototyping board, is unwise. What's the difference between a prototyping board and a product

> Selling EV charging products based on Raspberry Pi, which is a prototyping board, is unwise. What's the difference between a prototyping board and a product built using the lessons learned while integrating the prototyping board? The compute module is intended for use as an embedded board that simplifies development by mass producing the more difficult, expensive parts of embedded computers and letting the end user install it in a product. It's intended for exactly this sort of use case. > When both device manufacturers were contacted by the white hat penetration testers who conducted the penetration testing, the response was typically reactive seeing the device makers put in place a new server, app updates and firmware updates to the chargers. This is symptomatic of the general lack of strategic security thinking that goes into the manufacture of many embedded devices today. For example, one of the chargers had a Raspberry Compute Module 3 (CM 3) which lacked the necessary security features for such a use case. They updated with patches for the vulnerabilities. What more do you want? It's not like there are two kinds of computers, on one side insecure prototyping computers like Raspberry Pis that can be made to do unintended things, and on the other side secure IoT EV charger computers that only do what they are intended to do. There are only EV chargers that are controlled by general-purpose computers.

trangus_1985 5y ago
If you want a material example, the raspberry pi's SOC is designed to be mounted in read only mode with industrial on-board flash. It is meant to be used with the broadcom toolkit that includes multiple boot partitions for safe and validated updates. In addition, (afaik) that SDK includes a hardened and stripped down linux kernel with watchdog, chain of trust and binary signature verification - a far cry from the raspberry pi's kinda "open like whatever" standard desktop and server grade distro. A material consequence of this is that raspberry pis (pre 4, at least) that lose power during a SD write have had a common tendency to leave the flash in a really bad state, rendering the device unusable until a reflash happens. The compute model suffers from all of this. I use the compute modules for lighting and other fun such activities, at art and music festivals. I have gotten used to carrying spare SD cards (for non compute) and a laptop with flash snapshots (for CMs). More than once, a breaker has blown and the compute module wouldn't come up after due to a trashed filesystem. I will admit, the CMs are wayyy more robust than the normal ones, due to whatever emmc they're using. I could probably mount the flash as RO also but that tends to cause "weird things" to happen. If I have to flash a CM once in a weekend, that's a small price to play > What's the difference between a prototyping board and a product built using the lessons learned while integrating the prototyping board? The difference is that the lessons learned likely won't cover the large amount of pitfalls you'd encounter in the field, but those pitfalls still exist. TLDR: Raspberry pi doesn't include a hardened sdk and distro intended for robust, embedded applications.
hughrr 5y ago
The issue is likely the general purpose potentially network attached computer should not be trusted for the safety critical portion of the system such as power control and monitoring. That should be a fully isolated computer with a light weight communications protocol with the host over SPI/I2C etc. The isolated processor can run an RTOS with some deadline guarantees as well then. If the host is compromised, the physical hardware cannot be controlled past trivial (audited) requests issued to the isolated processor. Also on top of that, not joking but the Pi hardware, even the compute model, is not very good quality compared to typical industrial computers assigned to or designed for these tasks. The only reason people do this with the pi is to trade safety for cost savings which is a stupid idea when you’re playing with hundreds of amps.
HeyLaughingBoy 5y ago
Right. There seems to be this mythos that embedded systems developers are the hallowed priests of high-quality software development and embedded systems as these robust combinations of specialty electronics that can withstand everything up to a nuke dropped nearby. In truth, embedded systems engineers and the hardware they use/design have the same span of quality you'll find in most other types of software developments outside Safety Critical products. I've seen some really dumb things done by people who should know better and on the flip side, some systems that I'd happily trust my life to. There's no magic.

trangus_1985 5y ago

If you want a material example, the raspberry pi's SOC is designed to be mounted in read only mode with industrial on-board flash. It is meant to be used with the broadcom toolkit that includes multiple boot partitions for safe and validated updates. In addition, (afaik) that SDK includes a hardened and stripped down linux kernel with watchdog, chain of trust and binary signature verification - a far cry from the raspberry pi's kinda "open like whatever" standard desktop and server grade distro. A material consequence of this is that raspberry pis (pre 4, at least) that lose power during a SD write have had a common tendency to leave the flash in a really bad state, rendering the device unusable until a reflash happens. The compute model suffers from all of this. I use the compute modules for lighting and other fun such activities, at art and music festivals. I have gotten used to carrying spare SD cards (for non compute) and a laptop with flash snapshots (for CMs). More than once, a breaker has blown and the compute module wouldn't come up after due to a trashed filesystem. I will admit, the CMs are wayyy more robust than the normal ones, due to whatever emmc they're using. I could probably mount the flash as RO also but that tends to cause "weird things" to happen. If I have to flash a CM once in a weekend, that's a small price to play > What's the difference between a prototyping board and a product built using the lessons learned while integrating the prototyping board? The difference is that the lessons learned likely won't cover the large amount of pitfalls you'd encounter in the field, but those pitfalls still exist. TLDR: Raspberry pi doesn't include a hardened sdk and distro intended for robust, embedded applications.

hughrr 5y ago

The issue is likely the general purpose potentially network attached computer should not be trusted for the safety critical portion of the system such as power control and monitoring. That should be a fully isolated computer with a light weight communications protocol with the host over SPI/I2C etc. The isolated processor can run an RTOS with some deadline guarantees as well then. If the host is compromised, the physical hardware cannot be controlled past trivial (audited) requests issued to the isolated processor. Also on top of that, not joking but the Pi hardware, even the compute model, is not very good quality compared to typical industrial computers assigned to or designed for these tasks. The only reason people do this with the pi is to trade safety for cost savings which is a stupid idea when you’re playing with hundreds of amps.

HeyLaughingBoy 5y ago

Right. There seems to be this mythos that embedded systems developers are the hallowed priests of high-quality software development and embedded systems as these robust combinations of specialty electronics that can withstand everything up to a nuke dropped nearby. In truth, embedded systems engineers and the hardware they use/design have the same span of quality you'll find in most other types of software developments outside Safety Critical products. I've seen some really dumb things done by people who should know better and on the flip side, some systems that I'd happily trust my life to. There's no magic.