Engineering at the Edge

Using squashfs for fast, encrypted Torizon Secure Offline Updates (Lockboxes)

Wed, 09 Sep 2026 00:00:00 +0000

Torizon Offline Updates fire when a lockbox appears at a configured path. That works, but USB media is awkward in two ways:

Mount paths depend on the volume label (/media/<label>-…), so update sticks need a pre-agreed label, or the lockbox won’t appear at the correct path.
OSTree lockboxes are many small files, which can perform poorly on removable media—especially older filesystems like FAT.

We can instead ship the lockbox as a single squashfs image with a fixed name. All we need to do is add a small systemd path unit that finds it on any mounted USB volume and loop-mounts it to where Aktualizr already looks.

Hardening the software supply chain with a Yubikey: Torizon Cloud updates with zero trust and offline keys

Wed, 14 May 2025 00:00:00 +0000

Sometimes, when using security tools, there’s a gap between what you can do in principle, and what you can do in practice. This blog post is about my experience going zero-trust with my Torizon Cloud repository, the obstacles I faced along the way, and how I actually got everything working.

Overview

I’m a cybersecurity intern at Toradex. I’ve worked on TUF and Uptane during a residence at NYU Tandon in the Secure Systems Lab earlier, but that was only theoretical. Working at Toradex was my first interaction with a real-world Uptane implementation - so I thought I would see how it was to take an Uptane repository in Torizon, with online keys in Toradex custody, and update it so that the signing keys are completely offline, and stored on secure hardware where the actual private keys are completely impossible to extract.

How to Persist Application Data Across Torizon OS Updates

Mon, 02 Dec 2024 00:00:00 +0000

The Torizon OS is designed around the concept that different parties handle applications and OS development:

Applications: you, as a Torizon customer, develop and update your application on your development cycle
OS: we, the Torizon OS Team at Toradex, develop and update the base OS, releasing it every quarter

A question I sometimes get from customers is: how can I keep my application data when updating the base OS?

A Practical Answer

You must store the application data somewhere under the /var or the /etc directory. OSTree, the file system management tool used for OS Updates, keeps the /var directory intact during the updates. Also, OSTree only touches files under /etc if they haven’t been modified outside its knowledge, known as a 3-way merge.

Embedded Software Testing: Practical Continuous Integration with Hardware in the Loop (Part 2)

Sun, 03 Nov 2024 00:00:00 +0000

This is the second installment in the embedded software testing series. This one will be about the architecture of a system to test embedded software. I’ll give you a practical example of a test for an Embedded Device with integration to a CI/CD system. We’ll briefly cover what is usually called a “dual-targeting” approach as well.

Theory

In the previous installment we talked about the different levels of software testing, and the last one was “end-to-end testing”, which is treating the Device Under Test (DUT) like a black box, poking it with a certain stimuli (inputs), seeing how it reacts (output) and comparing with a known expected value.

Embedded Software Testing: the Hardware-Software Interface (Part 1)

Wed, 14 Aug 2024 00:00:00 +0000

This series of blogposts will deal with embedded software testing. I want to pass on to the reader the hard-earned knowledge from around 5 years of working with embedded software testing.

We’ll start with some definitions and then go through more practical aspects of software testing. Our focus here will be Embedded Linux, but the concepts and the tooling can surely go beyond it, such as in the realm of microcontrollers.

Wait! My Container is Crashing Before Startup

Thu, 08 Aug 2024 00:00:00 +0000

When using more than one container in a project, a probable scenario developers are faced with is startup errors due to a lack of inter-container app synchronization.

This often happens due to two reasons:

Containers are started in parallel leading to race conditions.
Even when starting one container after the other, containers don’t know when your application and its dependencies started.

Especially on Embedded Linux, which is the case of Torizon OS, this is bad. These systems might be deployed to remote, hard-to-reach locations, and on-site maintenance may cost a lot.

Why bare-metal Debian (and Raspberry Pi OS) is not a good choice for most Embedded Systems

Mon, 01 Jul 2024 00:00:00 +0000

Quite a few embedded vendors nowadays ship Debian or some derivative by default, specially for the hobbyist sector, but I don’t think people realize that there isn’t an expectation that Debian will be their production operating system, and when with ‘production’ I don’t mean one or two devices: by all means, if that’s your scale, continue using Debian in pet machines instead, that’s very much fine.

The real issue arises when you need real scale like multiple thousands of devices per year, which is the scale most SoM/SBC vendors are working with. Let’s go over some of the drawbacks you’ll have to deal with running Debian with those devices.

How does hardware acceleration work with containers?

Wed, 05 Jun 2024 00:00:00 +0000

At Toradex we build Torizon OS, which is a container-based embedded system. What do we mean by that? It means that the applications run in isolated environments called containers.

This begs the question: how do we access hardware resources like GPIOs from inside the containers, or even worse, how do we get GPU acceleration inside the containers?

A GPU acceleration primer

To run GPU accelerated applications on Linux in general you need some components in the userspace and some other components in the kernel space. So when you have an application that needs hardware acceleration, you link against libraries that provide a graphics API such as OpenGL which will in turn talk to another library that issues the ioctl() calls to the device descriptor created by the GPU driver.