The reverse is true -- app developers see something "weird" in embedded code and think it must be wrong, but often there is a reason. E.g. the unintended vehicle acceleration scandals, where codebases were criticized for having large numbers of global variables... but it's because there's no allocation permitted, and message passing is more expensive than just setting a bit of memory in a massive cooperative multitasking loop.

You might see weird stuff in embedded code because it needs to interact with flakey hardware using a flakey compiler, and be cycle accurate in the process.

I get it. I’ve done enough systems program and reversed many more embedded systems, bug hunting for customers. There are still a lot of bad practices in the embedded world. It often exists outside of normal best practices. Many choices embedded devs make are just plain bad. Using outdated libraries and binaries from a decade or more ago, etc. it doesn’t have to be so bad. I haven’t found many embedded systems that weren’t really bad from a security perspective.

The way these systems get developed is a huge part of the problem. One team building hardware, another building the software no one communicating. Everyone hoping for the best. Frantic cleanup in software to make it all work on top of hardware thet can no longer change. I am sympathetic to the embedded developers position, but they still seem to exist in a different universe from modern software dev.

As a security practitioner I don’t blame the devs. I like to ask questions about how things got to be this way. How we can make it better. But make no mistake. A decade will pass and some embedded developer will still be linking some ancient binary or throwing together a bunch of sketchy CGI files that let an attacker scribble everywhere in memory. Embedded is like, the final frontier of software security :)

That’s my lens anyway :)

I work on embedded software and far more often there's no good reason. (the global variables thing is ambiguous: it could be just counting static variables with well-defined scopes and encapsulation, or it could be describing truely global variables which can be modified by any part of the code at any time. The former is a reasonable technique to seperate modules without allocation. The latter is hair-raisingly reckless software design and also probably the more common approach, even in safety-critical systems). The level of awareness of software engineering concepts in the embedded ecosystem seems far lower than other areas.

I think it's a symptom of the field. A lot of arduino code is ghastly but mostly comes down to hardware people coding things for the first time and having zero professional development experience or formal education.

Yes, well, some of us are working with barely more than what a Commodore VIC-20 had to offer. (And we like it!)

;)