4 ms·

See. Not all the problems in embedded are network security risks. If you are evangelizing Rust, please stop trying to lure embedded developers with "networks ha

by scoutt 6y ago

See. Not all the problems in embedded are network security risks. If you are evangelizing Rust, please stop trying to lure embedded developers with "networks haxxor buffer overflow" FUD because it's simply not going to work. For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it. Edit to add: is not that security bugs are not important, but is not what we (embedded developers) are always chasing or taking away our sleep at night. Embedded is wide enough beyond computer networks. Please take a look at the room around you. Can you count every little chip in there? Including the one in your keyboard, LED lamps, coffee machine? Are all these ARM? NO. Are all these connected to the network? NO. Do you expect them to work 100% of the time without hiccups? YES, and they probably do without you noticing it. And they are probably running 1000s of lines of C. That's embedded.

wtetzner 6y ago
> For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it. And you don't think having the compiler check memory usage would be useful in this case? In my mind it means more effort can be put on making sure the logic itself is correct.
- scoutt 6y ago
  Maybe, but what checks would the compiler do on my small embedded memory for a program that processes a sensor and raises a pin? It might sound simple but it's an important core project. Would the compiler check a write outside the buffer that is filled with sensor data? Is that it? I'm not allocating anything so I cannot double free. The program executes in a main loop so there is no data races (perhaps one if the data buffer is shared with an interrupt, but it's a problem as old as the bible and we already have 1000 libraries with safe circular buffers). Or is the check done at runtime? Will it waste my cycles? Is that all I should change my language for? Would the sensor manufacturer help me if I give them a failing case written in Rust? Is it worth the risk of compiling on a nightly thing that will change next week? Note that people might get hurt for real. Damn! Now my MCU/sensor is going NRND. Should I freak out because Rust is still not supported for that new MCU yet, and I should write the thing all over again?
  - bsder 6y ago
    While I may not agree with your opinion, I upvoted you because your position is certainly not uncommon and saw your reply go grey. And that irritates me. I'm getting really pissed off about people downvoting who have nothing constructive to add to the conversation. Rather than downvoting, fucking REPLY. A downvote is lazy--it's actually worse than doing nothing on a low-vote thread--it's a sin on the level of turning down the premise when doing improv comedy. An articulated position furthers the conversation and actually represents effort. When did HN readership become such prissy hothouse flowers? FFS. (EDIT: I turned down the swearing a bit)
  - wtetzner 6y ago
    I don't actually disagree with any of what you're saying. My only point was that Rust's safety checks and features are useful for embedded. There are obviously many other considerations when making a decision about what to use on any given project. I suspect Rust will be a clear win on some subset of projects, and will not be worth it others.
deleted 6y ago
[deleted]
bsder 6y ago
> For instance, a developer writing the software for the sensors of a forklift Industrial is a very poor choice of counterexample. You should have stayed with consumer space counterexamples. Everybody in the industrial setting wants their telemetry and data transmitted to centralized computing whether they know what they are going to do with it or not. As for sensors, how are those distance sensors connected to the microcontoller? Perhaps a redundant automotive bus with real-time constraints like CAN? CAN often has a fairly decently sized, badly written, vendor supplied communication stack in order to use it. Is that forklift's sensor telemetry going anywhere? If not, then you're probably going to lose out to someone who does when you sell that forklift to Amazon or WalMart. They probably want to know about where the skulls are (gotta track those lazy humans) more than they want to know about where the forklifts are. > Are all these ARM? NO. Actually, they increasingly are. USB-C PD negotiation chips, for example, are basically ARM M3/4 cores with specialized hardware. The cost differential between 8-bit and 32-bit microcontrollers is so low that unless you have extreme volumes, you might as well use the 32-bit one and gain all the infrastructure that provides. > Are all these connected to the network? NO. Are you sure? Hotel locks had security vulnerabilities because they had a USB port. The problem isn't whether I can use the I2C bus on your Cuisinart to break into it--if you used a "standard" driver written in C I probably can. These small system don't have to worry about "secure" simply because they aren't worth breaking into--until some really creative person makes them worth breaking into. (Hey, there's a speaker on that innocuous thing that's loud enough that we can talk to Alexa. YAAAARRRR, Me Mateys!)
- scoutt 6y ago
  For Industry 4.0, yes telemetry is important. But, not all industrial cares about telemetry. In that case, what I have seen, is that all the data is sent to a concentrator that has the network stack. This is often a "high-end" (perhaps Linux based) machine with network access. Is not that every chip in a system is connected to the network. For what Rust matters, I'm really want to see high-level stack written on it, or libraries like libssl. I think that's where Rust should be placed not going any lower (in levels/layers). Regarding ARM, it depends. It's not just a matter of bits over price. Pretty often the combination of features you want are not available in an ARM chip. For example, long term support, some specialized tool, temperature/power supply range, price, available peripherals, etc. And sometimes you might be required to work on some strange 32-bit CISC from Renesas just because the salesperson took the purchasing manager to dinner somewhere. And yes, everything is hackable no matter the language you use. If you open the case and cut some PCB traces you might read and inject some data making some device to misbehave. But that's the way it is and I don't see the world falling apart because of this. If it really matters, then (electronically) tamper-proof your case would be my advice. Again, is my honest opinion and the opinion of many embedded developers I work and know: vulnerability FUD is just noise. I'm just being sincere. Of course if you make locks you have to make your system secure. The other billion of embedded applications might not. And that's it.

by scoutt 6y ago

wtetzner 6y ago

> For instance, a developer writing the software for the sensors of a forklift has enough to worry about to not crushing the skull of someone passing near it. And you don't think having the compiler check memory usage would be useful in this case? In my mind it means more effort can be put on making sure the logic itself is correct.

scoutt 6y ago
Maybe, but what checks would the compiler do on my small embedded memory for a program that processes a sensor and raises a pin? It might sound simple but it's an important core project. Would the compiler check a write outside the buffer that is filled with sensor data? Is that it? I'm not allocating anything so I cannot double free. The program executes in a main loop so there is no data races (perhaps one if the data buffer is shared with an interrupt, but it's a problem as old as the bible and we already have 1000 libraries with safe circular buffers). Or is the check done at runtime? Will it waste my cycles? Is that all I should change my language for? Would the sensor manufacturer help me if I give them a failing case written in Rust? Is it worth the risk of compiling on a nightly thing that will change next week? Note that people might get hurt for real. Damn! Now my MCU/sensor is going NRND. Should I freak out because Rust is still not supported for that new MCU yet, and I should write the thing all over again?
- bsder 6y ago
  While I may not agree with your opinion, I upvoted you because your position is certainly not uncommon and saw your reply go grey. And that irritates me. I'm getting really pissed off about people downvoting who have nothing constructive to add to the conversation. Rather than downvoting, fucking REPLY. A downvote is lazy--it's actually worse than doing nothing on a low-vote thread--it's a sin on the level of turning down the premise when doing improv comedy. An articulated position furthers the conversation and actually represents effort. When did HN readership become such prissy hothouse flowers? FFS. (EDIT: I turned down the swearing a bit)
- wtetzner 6y ago
  I don't actually disagree with any of what you're saying. My only point was that Rust's safety checks and features are useful for embedded. There are obviously many other considerations when making a decision about what to use on any given project. I suspect Rust will be a clear win on some subset of projects, and will not be worth it others.

deleted 6y ago

[deleted]

bsder 6y ago

> For instance, a developer writing the software for the sensors of a forklift Industrial is a very poor choice of counterexample. You should have stayed with consumer space counterexamples. Everybody in the industrial setting wants their telemetry and data transmitted to centralized computing whether they know what they are going to do with it or not. As for sensors, how are those distance sensors connected to the microcontoller? Perhaps a redundant automotive bus with real-time constraints like CAN? CAN often has a fairly decently sized, badly written, vendor supplied communication stack in order to use it. Is that forklift's sensor telemetry going anywhere? If not, then you're probably going to lose out to someone who does when you sell that forklift to Amazon or WalMart. They probably want to know about where the skulls are (gotta track those lazy humans) more than they want to know about where the forklifts are. > Are all these ARM? NO. Actually, they increasingly are. USB-C PD negotiation chips, for example, are basically ARM M3/4 cores with specialized hardware. The cost differential between 8-bit and 32-bit microcontrollers is so low that unless you have extreme volumes, you might as well use the 32-bit one and gain all the infrastructure that provides. > Are all these connected to the network? NO. Are you sure? Hotel locks had security vulnerabilities because they had a USB port. The problem isn't whether I can use the I2C bus on your Cuisinart to break into it--if you used a "standard" driver written in C I probably can. These small system don't have to worry about "secure" simply because they aren't worth breaking into--until some really creative person makes them worth breaking into. (Hey, there's a speaker on that innocuous thing that's loud enough that we can talk to Alexa. YAAAARRRR, Me Mateys!)

scoutt 6y ago
For Industry 4.0, yes telemetry is important. But, not all industrial cares about telemetry. In that case, what I have seen, is that all the data is sent to a concentrator that has the network stack. This is often a "high-end" (perhaps Linux based) machine with network access. Is not that every chip in a system is connected to the network. For what Rust matters, I'm really want to see high-level stack written on it, or libraries like libssl. I think that's where Rust should be placed not going any lower (in levels/layers). Regarding ARM, it depends. It's not just a matter of bits over price. Pretty often the combination of features you want are not available in an ARM chip. For example, long term support, some specialized tool, temperature/power supply range, price, available peripherals, etc. And sometimes you might be required to work on some strange 32-bit CISC from Renesas just because the salesperson took the purchasing manager to dinner somewhere. And yes, everything is hackable no matter the language you use. If you open the case and cut some PCB traces you might read and inject some data making some device to misbehave. But that's the way it is and I don't see the world falling apart because of this. If it really matters, then (electronically) tamper-proof your case would be my advice. Again, is my honest opinion and the opinion of many embedded developers I work and know: vulnerability FUD is just noise. I'm just being sincere. Of course if you make locks you have to make your system secure. The other billion of embedded applications might not. And that's it.