Bit-baking with soda

What it this about? I know, I know strange title for a blog post. When dealing with YOCTO you mostly spend time at a single recipe while developing (at least I do), so everything is right at one place - not a big deal. But an image consists of multiple of those packages and they should all play well together. Sometimes there are "global" component (like web server) which are used by many components at the same time. And here comes the issue. I had the pleasure of putting a nginx based web server together which was configured by a bunch of configuration files, which were produced by a lot of different packages. In theory this works quite well, as you simply just adjust where it's needed, everything else should be done by bitbake - well in theory... The issue was that in a single configuration fragment a typo existed, which didn't get noticed until the whole construction was started on the target device - I personally think this is way too late. There has t...

When using YOCTO for building your software there always comes the point where everything is woven together to something bigger - usually all your recipes are put together to an image, which can be used directly for booting an embedded device. As this is the final step, extra care should be taken when it comes to checking on security. On an recipe level you can make your component as fortified as you could imagine, if another component doesn't care about security at all, your whole concept will fall into pieces. So how do I check on security when an image is created?  What do I need check for? Are there any helpful tools around, which can support me? To answer the last question first - YES there are some very useful tools around, for instance ansible . Ansible is a very flexible, extendable batch processor, which can automate most of the administrative tasks quite convenient. The result of a YOCTO build is mostly an more or less fully featured Linux system, you can...

In my last post I described a way how to ensure a safe and know configuration for KConfig-based system . But there is a lot more that could be altered when you include additional layer into your workspace. Just think of configure options build instructions additional patches being applied license changes (a very bad one) files remove which should have been there a.s.o. I though about this for a longer time... after a very deep dive into the way bitbake is handling the parsing of any file (bb, bbappend, inc, conf) I created a small helper bbclass which you can find here . This class can monitor changes done by bbappend file (no matter where they are actually located in your workspace) and diff them to the plain recipe. You can now define a set of variables which you don't want to be changed at all (like. SRC_URI, or LICENSE). The helper class does then the magic for you and diffs them against each other. If a variable (and all there machine/arch-specific var...

As you may know KConfig is a well-known system for configuring software modules, as used by busybox , linux kernel , u-boot and many more. If you are unfamiliar you might want to read this nice tutorial . So as KConfig is well established it is used at different locations throughout YOCTO. Basically YOCTO is doing it the following way. You have a base configuration file called "defconfig". This is placed somewhere in the recipe-tree. It describes the absolute minimum of configuration needed. Depending on the feature you want to add, there are *.cfg-file around the recipe-tree. The configuration is done with all the *.cfg-files being merged into the defconfig. This is passed to "make oldconfig" to sanity check and put all the not defined symbols into the configuration. And voila you have a fresh valid configuration to build your software. It's pretty obvious that this is one stage where things can go very wrong...! Mostly the basis (KConfig) is chan...

Have you ever faced software security alerts in your embedded product or project? I did - several times. Mostly this had been going in the following way read an article or got a mail about the security issue checked (or may double-checked) the version actually used in the product is affected informed head of development (or head of security) that there is a problem in the software made several rounds of discussions and planning (which could take some time) included the fix, if there was one available did all the needed Q&A process deployed the fixed version kept the fingers crossed that software will be installed to most of the devices before anyone actually exploits the issue The chain of disaster already starts at the first bullet - it's far too late - the whole process usually takes at least a few days - days devices in the field might be exploitable - and who's responsible in the end? Take a guess - mostly it's you. Of course you can put yourself on...