Security patterns and anti-patterns in embedded development [LWN.net]

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 16:15 UTC (Tue) by rweikusat2 (subscriber, #117920)
Parent article: Security patterns and anti-patterns in embedded development

The Yocto build system with its wild mixture of Python, shell and all of the Bitbake ad hocery isn't exactly a shining example of something that's not "obscure" and I seriously doubt that the majority of people using it actually understand it. Further, the language isn't the real issue here but the code written in it. Most code written in any language will be "obscure" to most people, regardless if they know the language or not, possibly just for the trivial reason that there's a real lot of it (code) and they haven't really seen much of that.

How many people know that meta/classes/devtool-source.bbclass¹ exists and how many of these understand it?

¹ From the dated Yocto version I've worked with last.

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 17:50 UTC (Tue) by Paf (subscriber, #91811) [Link] (4 responses)

So I can't speak to Yocto... But while it's certainly true that writing build stuff in a less obscure language isn't some cureall... It's *also* true that it doesn't help! This can be an "and" type situation.

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 18:03 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

I think the bigger thing here is that Yocto doesn't take upstream's build system; it rewrites it, instead. As a result, backdoors in the build system don't get run, and there's a human tracing through how the build system works in order to redo the important bits in Yocto's system. Because the build system is "executed" by a human, a backdoor that depends on the build system will get caught in that execution.

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 19:18 UTC (Tue) by dezgeg (guest, #92243) [Link]

It's not the case that Yocto replaces the upstream build system (unlike say, the Android build system, or if I understood correctly Bazel), but just that the pre-generated configure isn't used but always generated on the fly by autoreconf et al.

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 21:16 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link]

This isn't really. It's pretty much a meta build system for integrating all kinds of software using all kinds of build system into a system for building an OS image from source. The default for handling autotools-based packages is the so-called autotools class which always invokes autoreconf as part of configuration. But that's an implementation detail which could well work in a different way. And there's obviously nothing which forces people to use the default autotools support.

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 21:27 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link]

The remark about obscure languages is really an obscure tangent. Understanding the autoconf m4 code is vastly more complicated than understanding the m4 syntax. And the same is true for any complex software system (written in a mix of different programming languages). The Yocto copy I have lying around here consists of 100,849 non-blank lines of text. A lot can be hidden in there even from people who are perfectly familiar with all the involved programming languages because the sheer volume of code mean most of it will always simply be taken for granted without even trying to understand what it does.

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 18:23 UTC (Tue) by atai (subscriber, #10977) [Link] (4 responses)

unrelated to Yocto or embedded development in general, but as a build system, bazel, used widely due to Google, seems also a system in obscurity.

Security patterns and anti-patterns in embedded development

Posted Apr 30, 2024 22:27 UTC (Tue) by willy (subscriber, #9762) [Link] (3 responses)

A lot of this is familiarity. When an unholy mess of shell, Makefile, sed, awk, perl spits out an error, I have an idea about how to go about diagnosing and even fixing it.

When it's something I don't know like m4, cmake or Bazel, I'm screwed. And honestly when it's something like Bazel which appears to exist Because Google Is Better At Everything Than You Are, I am disinclined to learn.

Security patterns and anti-patterns in embedded development

Posted May 1, 2024 11:47 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

Also there's cmake's propensity for spitting out errors halfway through a complicated setup and then, surprise, going through the other half of the complicated setup before finally dying … with an error message that kindof implies that the last step of the complicated setup has gone wrong.

Funnily enough, that last step often is looking for the precise flavor of the pthread[s] library, which habitually "fails" because the check for the 'wrong' variant prints an error message. A web search for pthreads "breaking" your cmake script yields a heap of confused examples.

Makefiles aren't exactly anti-pattern-free either. You can make them arbitrarily complex, if not NP-complete. Look at the Linux kernel's build system if you need an example.

Security patterns and anti-patterns in embedded development

Posted May 3, 2024 1:06 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Yes, sometimes you want `message(FATAL_ERROR)` to stop ASAP, other times you want to try and get as many questions in the cache at once to reduce reconfigure cycles when satisfying a project's requests. But as with any tool, starting with the *first* reported error is usually a good place to start.

Security patterns and anti-patterns in embedded development

Posted May 3, 2024 9:40 UTC (Fri) by mss (subscriber, #138799) [Link]

meson seems to be this decade build system of choice for OSS projects.

cmake was more like year 2010 thing.