In modern electronic product development, many of the key features tend to be realised in the software or firmware stage. These are the processes that turn a lump of metal, plastic and silicon into a useful device.

My speciality is embedded software development and my role is focussed on embedded operating systems, which more often than not these days means Linux. As a result, the security of embedded Linux systems is a key issue and one that I personally spend a lot of time thinking about.

It would seem reasonable to me that a customer should be able to expect two things from the embedded software in the product they have just bought. Firstly, that it has been developed by engineers who know what they are doing, and secondly, that it should be adequately bug free and secure. In other words, fit for purpose and right from the outset.

In reality, the time taken, in any product development project, to reach key milestones is crucial and any way of speeding up the process always seems attractive to project managers. By contrast, any professional software engineer will tell you that taking shortcuts to speed up development tends to go hand in hand with an increase in both bugs and security risks.

Even if your software appears to be solid on day one, bugs do emerge over time and security flaws are revealed. Suddenly, that top of the range consumer product you put on the market several months ago becomes the target of choice for every hacker on the planet.

At that point (and if you’re sensible, long before then), your top priority is to decide what to do about it.

A perfectly acceptable reaction is to say “just fix the bugs and update the devices as quickly as possible”. Sadly, in practise, a secure remote software update is a very complicated proposition and therefore it is done infrequently or, sometimes, not at all. Worse still, software update mechanisms can themselves introduce reliability and security holes if they are not properly designed and implemented. Homebrew update schemes also have a track record of creating, rather than solving, such problems.

At this point, you are probably wondering how to deal with this. Well, the answer is not to invent your own scheme but to use the solutions that other people have spent years developing and fine-tuning.

This is where ‘Yocto’ enters the picture. Yocto is a software toolset designed to build highly customised, small embedded Linux distributions for resource limited hardware. The name ‘Yocto’ was actually chosen because it is the naming prefix for the smallest measurement scale (10^-24) in the SI system of units.

Yocto is based on layered, configurable scripts known as “recipes” that are “baked” to generate the software. In my opinion, Yocto has a number of advantages from a security perspective when compared with similar toolsets such as ‘Buildroot’. In particular, it is simple to use, extremely flexible, and it offers embedded Linux developers access to a massive base of open-source Linux software packages. That includes a number of reliable, secure, tried and trusted package-based update mechanisms.

Of course, Yocto won’t solve all of your problems but it does give you a robust starting point. When it comes to product development, it can save you months of development effort, making the project manager happy and putting you on the front foot. Most importantly, it might save you from that embarrassing security bug that would otherwise haunt you for the rest of your career.

For more information about Yocto, you can read Alan’s white paper on the subject here.