3 ms·

Firmware engineer here with an opinion from down in the trenches: The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various

Firmware engineer here with an opinion from down in the trenches: The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on. Who is expected to do this work? Today, it is done by the semiconductor vendor. When you buy a microcontroller, you’ll use an SDK and a toolchain that the vendor offers. The vendor is incentivized to keep their SDK and tool chain as general as possible to sell into as many different designs as possible. The OEM wants to ship a product as quickly as possible to make their cashflow model work. There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks. The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business. Most consumers today don’t know how bad the situation is to care about this stuff. It sucks because we firmware engineers want to do the right thing but we can’t justify it.

brightlancer 3y ago
> The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business. At least in the US, customers are very price conscious and will sacrifice a lot to save a dollar. To frame this from their standpoint, "Why do I have to pay more for ¨features¨ that I don't want?" I think folks _should_ demand more secure devices, but they also must be willing to pay for it. (Many folks will immediately respond, "We'll use the government to force companies to do this!" but that can cost even more, as the company provides the extra features and also pays for the bureaucracy.)
ilyt 3y ago
> The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on. No, that's the easy part (even if done manually). The hard part starts with networking > There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks. Most SDKs I've seen end up somewhere at level of TCP stack, sometimes at level of simple web server. Because everything above will be very application specific. It's near-entirely on the app vendor to fuck stuff above that. Don't try to push blame on manufacturer of the chip here, they didn't force your password to be 12345678
- fidotron 3y ago
  But SSH etc are totally inappropriate for embedded devices (microcontroller level) anyway. Suddenly you need to deal with either a clock battery or secure NTP on boot . . . This is opening the pandora’s box of replays etc. Frankly this whole idea the same protocols that are used on the web should go anywhere near microcontrollers is braindead. Edit: apologies if this was too strongly/inappropriately worded, but I stand by the underlying point.
  - GabeIsko 3y ago
    Not so much microcontrollers, but IoT devices. That's the reality we live in - as devices grow more complex and hardware becomes more mass produced and less expensive, commercial interests will find their way to just including a linux kernel with everything. And once that happens, ssh will be bundled with it. sshd has no place on most of these devices. But it comes packaged by default in many distributions. Real products are shipping with it right out of the box, and it's a problem.
stalfosknight 3y ago
This right here is why I am a rabid fan of Apple's vertically integrated way of doing things.
- AnthonyMouse 3y ago
  I needed a computer to sit in a corner and run some application, performance irrelevant. I had a Mac Mini that Apple calls "obsolete" and doesn't support, but it's really a PC so I put Linux on it. An old iPhone would have used less power, but "vertical integration" means when the vendor stops supporting it neither can anyone else. Vertical integration is not the solution, it's the problem. The hardware vendors are providing the firmware instead of a spec that allows you to write your own. Then you're stuck using their software to use their hardware, even if it's awful or they stop updating it. It's perfectly fine to provide a reference implementation, but that's not a substitute for hardware documentation sufficient to let you make your own if you don't want the vertical integration. Because the party with the economic incentive to make it better is the end user. Not all of them have the capacity to do that, but only one of them needs to and you have better code available to the whole world.

brightlancer 3y ago

> The current school of thought dominating MBA courses would see addressing these issues as a cost with no tangible benefits to the business. I can see their rationale: if consumers don’t signal that they care about security, then it is actually hard to argue that addressing security is a benefit to the business. At least in the US, customers are very price conscious and will sacrifice a lot to save a dollar. To frame this from their standpoint, "Why do I have to pay more for ¨features¨ that I don't want?" I think folks _should_ demand more secure devices, but they also must be willing to pay for it. (Many folks will immediately respond, "We'll use the government to force companies to do this!" but that can cost even more, as the company provides the extra features and also pays for the bureaucracy.)

ilyt 3y ago

> The reality is that it takes a ton of work to get a microcontroller to blink an LED. Various clocks need to be configured, various peripheral devices (I2C controllers, GPIO controllers etc) need to be configured, interrupt vector tables need to be set up and so on. No, that's the easy part (even if done manually). The hard part starts with networking > There’s a huge gap between these two ends where a ton of important stuff goes unaddressed. At no point are the OEM and semiconductor vendor incentivized to sit together and addresses all the issues that fall through the cracks. Most SDKs I've seen end up somewhere at level of TCP stack, sometimes at level of simple web server. Because everything above will be very application specific. It's near-entirely on the app vendor to fuck stuff above that. Don't try to push blame on manufacturer of the chip here, they didn't force your password to be 12345678

fidotron 3y ago
But SSH etc are totally inappropriate for embedded devices (microcontroller level) anyway. Suddenly you need to deal with either a clock battery or secure NTP on boot . . . This is opening the pandora’s box of replays etc. Frankly this whole idea the same protocols that are used on the web should go anywhere near microcontrollers is braindead. Edit: apologies if this was too strongly/inappropriately worded, but I stand by the underlying point.
- GabeIsko 3y ago
  Not so much microcontrollers, but IoT devices. That's the reality we live in - as devices grow more complex and hardware becomes more mass produced and less expensive, commercial interests will find their way to just including a linux kernel with everything. And once that happens, ssh will be bundled with it. sshd has no place on most of these devices. But it comes packaged by default in many distributions. Real products are shipping with it right out of the box, and it's a problem.

stalfosknight 3y ago

This right here is why I am a rabid fan of Apple's vertically integrated way of doing things.

AnthonyMouse 3y ago
I needed a computer to sit in a corner and run some application, performance irrelevant. I had a Mac Mini that Apple calls "obsolete" and doesn't support, but it's really a PC so I put Linux on it. An old iPhone would have used less power, but "vertical integration" means when the vendor stops supporting it neither can anyone else. Vertical integration is not the solution, it's the problem. The hardware vendors are providing the firmware instead of a spec that allows you to write your own. Then you're stuck using their software to use their hardware, even if it's awful or they stop updating it. It's perfectly fine to provide a reference implementation, but that's not a substitute for hardware documentation sufficient to let you make your own if you don't want the vertical integration. Because the party with the economic incentive to make it better is the end user. Not all of them have the capacity to do that, but only one of them needs to and you have better code available to the whole world.