It’s important for us to keep up with the latest developments in the landscape of embedded Linux and to meet like minded people from the open source community – that’s why, last month, we sent 12 of our engineers to the Embedded Linux Conference 2026 in Prague (part of the Open Source Summit). In this blog post we shall share some of our highlights from the event.
Munich After LiMux: More Open Source Than Ever – Dr. Laura Dornheim, Chief Digital Officer, City of Munich
Laura Dornheim’s talk was an excellent keynote showcasing the journey of the city of Munich through the task of replacing its admin infrastructure with free open source alternatives. The first such attempt was started when Microsoft decided to drop support for Windows NT 4.0 but there were also obvious economic benefits that supported that action. Hence, the city council of Munich launched an ambitious project code named LiMux in 2003 that spanned 10 years and by end of which, in 2013 all 14800 machines had migrated to Ubuntu and LibreOffice – this was every PC that was owned by the city administration.
Government-owned institutions like the city council are heavily dependent on the current political agenda. There was a change of governance in 2014, and in 2016 Microsoft has moved its HQ to Munich as well. As a result, by 2023 the Microsoft OS was back and Linux OS was gone. However, with another with change in the political agenda in 2020, open source was in favour again, but switching the OS back yet again was, at that stage, not deemed a good idea. So the takeaway here was that the politics drives the technology used in public domains.
The city of Munich committed to using FOSS as the default regardless and its own development work is open source as well but without adding disruption as before – so without changing the OS to Linux. A great example of its commitment is the city’s own DAVe software for traffic data analysis (charging for smart parking) that is now used by other cities in Germany as well, see the Munich GitHub here. Other moves towards FOSS were also covered, such as the city council IT moving from VMware to Proxmox to cut costs, moving from Oracle to PostgreSQL and also moving from Jira to OpenProject – we do especially sympathize with the last two items.
The talk finished with tips on how to navigate the politics and gain support for open source.
Keynote: Linus Torvalds, Creator of Linux & Git, in Conversation with Dirk Hohndel, Head of Ericsson Software Technology, Ericsson
This talk was a live conversation between Linus and his good friend Dirk – a format that Linus himself prefers, as it means he doesn’t have to prepare slides and can relax during the process. The talk touched on the 35 years history of of Linux, the early days of maintaining it and the events that led up to creating git, and AI.
Linus reflected on the fact that at the very beginning of the Linux kernel his mindset regarding maintenance of the codebase was still that of a single owner and contributor. It took him 3-4 months to get on board with the idea of allowing others to modify his work and code. At the start his procedure was to just read the intention from some else’s patch and do the actual implementation in his own way. So embracing open source and getting used to working with the community might take time, but it is normal to have a burn-in phase.
Initially the source control of the Linux kernel tree was done by releasing weekly: source as compressed tarball, a patch and the diff, which lasted until 2002 (note that you can still download the Linux kernel in this format today). This was done to make sure that everyone had the same distributed copy and setup. It was also possible because the project was a lot smaller than today. The centralized Concurrent Versions System existed at the time but it was very painful to use, especially for branching and setting it all up. However, some subsystems like the networking subsystem did move to CVS over time but Linus was never a real fan of it.
Then BitKeeper came along which is open source today under the Apache 2.0 License, but back in the day it was proprietary software, so not everyone was on board with using it. However, it allowed to have a truly distributed system and it did speed up the process. Experience with BitKeeper taught Linus what a source control system should be doing and gave him good ideas on how that could be improved further. BitKeeper’s community license said that it could be used for open source projects as long as the developers that work with it did not try to reverse engineer it, which, of course, happened in 2005 and so the Linux kernel has lost access to its source control tooling.
As a result in 2005 Linus took everything he liked in BitKeeper and wrote git, which was hard to accept initially for people with CVS backgrounds who had missed the BitKeeper train (as it was not open source). All of the commands were intentionally conceptually different and renamed out of Linus’s disdain for CVS. Linus did not anticipate that git would basically take over open source source control management. On that note, Linus thinks that he is getting too much credit for git as the project evolved into something better after he handed it over to Junio C Hamano after about half a year after its creation.
Next the talk went into the history of release process of the Linux kernel. Initially the releases were done every one to three years with a lot of technical debt accumulated over time. In 2006, this was replaced with the current model where there is a new Linux mainline kernel released every 9-10 weeks, with 2 weeks for merge window, 7 weeks for release candidates etc. So the philosophy was changed to have incremental steady progress instead of having big and buggy new features in the kernel release.
The talk concluded with a bit of commentary on AI. Linus had an optimistic and pragmatic approach, and thinks that AIs can be used for generating the code you do not really care about (like user interfaces) and that they are a great gateway drug for newcomers to the craft of programming to get instant dopamine-inducing results as it lowers the bar. Linus said that he has a hobby of making distortion guitar pedals and he is using AIs there to aid him with some of the tasks that he does – when the AI is instructed exactly what to do and how. However, he expects that for real programming tasks the engineers should still be able to understand and write the code. It was also noted that the Sashiko review bot has been found to be very useful tool for the Linux kernel maintainers. So according to Linus, AI vibecoding is fun but for critical code a code comprehension and having a human brain is still a must.
FIT happens, Ahmad Fatoum, Pengutronix
FIT image has become the de-facto standard for packaging and signing kernel images, device tree blobs and other data files used when booting an embedded Linux system. Over the years the flexibility of FIT has grown, and with that the complexity.
Ahmad Fatoum’s talk went into detail about all the ways FIT images can be used but also the fundamental flaws in the design. The use of flattened device tree (FDT) made sense when FIT images were designed. The code existed already in boot loaders. It could be trivially extended to provide a format to encapsulate kernel images, and include signatures.
The problem is that parsing FDT is complicated and so likely to include subtle bugs. On a non-secure boot system these just result in an un-bootable system. But for secure boot, this presents a far too large attack surface running at the highest privileged level. The inevitable result is vulnerabilities that can be used to compromise the security of the boot chain. One such example is CVE-2026-33243 found in Barebox but it is likely others are lurking in the code waiting to provide a way to break your secure boot system.
The main takeaway from the talk was that you should not trust the FDT parsing code. Only give it a FIT image that is known to be good. So this means signing the entire image rather than making use of the signing of individual elements in the FIT image.
More generally this is a reminder that boot loaders should be as simple as possible. The more code running with boot loader level privileges, the more vulnerabilities there will be.
Also testing was highlighted as being critical. Have you built an unsigned image and made sure it doesn’t boot? What about a modified signed image?
To be trusted, any secure boot implementation needs a thorough set of tests to prove that it is really secure.
Fit Happens, Ahmad Fatoum, Pengutronix, ELCE 2026, Prague
No Reboot Required: Over-the-Air Updates for Immutable Filesystems, Jana Perić, Mender.io
The conventional approach to securing embedded devices often relies on an immutable, read-only root filesystem, such as SquashFS or EROFS, and combined with full A/B partition updates. However, even a one-line fix can necessitate deploying an entire root file-system image, potentially requiring hundreds of megabytes of downloads and a device reboot. This results in unnecessary downtime and significant bandwidth consumption, particularly in bandwidth constrained deployments.
In “No Reboot Required: Over-the-Air Updates for Immutable Filesystems,” Jana Perić demonstrates how systemd-sysext can address this limitation by dynamically overlaying lightweight SquashFS or EROFS extension images onto /usr and /opt. This allows compatible software updates to be activated at runtime without modifying the underlying base OS or rebooting the device, although individual services may still need to be restarted. Rather than relying exclusively on full A/B image updates, a tiered strategy could reserve full-image deployments for major base system changes while using lightweight file-system extensions for targeted fixes and incremental software updates.
This approach can also incorporate security mechanisms to mitigate the risks associated with runtime updates. Although extension images will reside on writable partitions, such as /var or a dedicated /data mount, cryptographic signatures and the Linux’s kernel dm-verity can help protect their authenticity and integrity. Signature verification can establish whether an extension was signed by a trusted key, while dm-verity verifies data blocks against a trusted hash tree as they are read.
The talk presents an interesting proof of concept using Mender to demonstrate this workflow. The underlying architectural pattern could be adapted to other embedded OTA update frameworks, such as SWUpdate and RAUC. However, integrating file-system extensions into these frameworks would require additional developer implementation rather than relying on a built-in feature. The approach warrants further investigation, particularly into its security implications, rollback mechanisms and how it would handle update failures.
No Reboot Required: Over-the-Air Updates for Immutable Filesystems, Jana Perić, Northern.tech, ELCE 2026, Prague
Is it time to retire kas? Felix Mößbauer, Jan Kiszka, Siemens
The mainstay for many Yocto engineers has become Siemens’ tool kas. An “all-in-one” setup tool designed specifically for managing complex bitbake projects.
Opening with kas’s main selling point: a “single statement setup & build for Bitbake Projects” the authors went on to show kas (and its container’s) continued success and popularity with over 1 million downloads in the year 2025 and 77k just for Debian (Trixie). Certainly not the time to retire kas at all. Jan Kiszka and Felix Mößbauer also noted an interesting anomaly in November 2020 that they noticed 660k downloads of the kas-container for some reason…surely some one made a mistake in their config. The rest of the talk outlined the latest developments of the project, including that it is now packaged at version 4.8 for Debian’s stable branch along with now having man pages not just for kas but also plugins such as kas-build, kas-diff, kas-purge etc.
Support for diff between kas configurations has been added via kas diff which does exactly that, kas-lock allows the creation (and updating) of a lock-file that pins repositories to specific a commit “[…] while still keeping an easy update path”. Build attestation can be captured in SLSA Provenance Format using the –provenance switch who’s output can then be cosign’ed against the image. Further, developers can now perform commit signature verification in kas’s project configuration. Project configuration also supports downloading, verifying, caching, and using Yocto’s buildtools.
At a more “meta” level, kas-container works reliably as rootless in both podman and docker (but better in the former than the latter). It also now aligns file ownership and can –preserve-paths between host and guest. Further OCI containers are Debian based using a fixed snapshot and are “bit-by-bit” reproducible. On the CI side of things, kas explicitly supports well-known CI environments, and edits git URLS and injects tokens for fetching transparency. Support for AWS SSO and OCI Registry Authentication has also been added.
The talk finishes stating that kas is still used primarily for its container, its menu, and its “convenience”. A comparison of Yocto’s default system compared with kas itself shows it’s still the go-to (if ancillary to Yocto itself). And finally stating that it is here to stay. It’s a “state-of-the-art” product and has been used for over 10 years on some projects internally at Siemens. We use kas on every single project at The Good Penguin, hence we are glad to hear this.
Is It Time To Retire kas?, Jan Kiszka and Felix Mößbauer, Siemens, ELCE 2026, Prague
Triaging CVEsLinux Kernel, Christoph Steiger, Negar Masoudifar, Siemens
With the manufacturer CRA reporting obligations now in-place (11th September 2026), and the deadline for full compliance and open source maintainers fast approaching (11th December 2026) there was again a big focus this year on managing and triaging CVEs with Yocto.
The Linux kernel has been its own CNA now since 2024 so many bug fixes end up with CVE numbers assigned.This leads to a large volume of CVEs, but also means that each CVE will have a patch upstream. Whilst there is a lot of good work done upstream back-port fixes to LTS branches (in addition to shipping an exclusion list in the case of yocto-linux), vendor kernels often update late, partially or never.
A tempting approach here is to cherry-pick fixes manually into your own set of kernel patches, but the CVE’s patch won’t take into account any dependent changes prior and its context.
The simplest solution here is to avoid using vendor kernels all together, and to favour closer to upstream alternatives like yocto-linux. For those who can’t, Jan has created a Yocto layer meta-kernelcve-test that will, as part of your build:
- Filter out CVEs based on their attack vector & severity (physical might not matter if its in a locked cage)
- Locate the fix on the stable branch (using Ubuntu CVE tracker)
- Attempt to apply the fix on your real source tree
- Check if the code is even compiled using your kernel .config (using koverage)
You then can look through the summary, and decide which patches can be ignored, applied ot need to be verified.
He demonstrated using this to filter setups for the NVIDIA Jetson Orin Nano devkit and Variscite DART-MX8M-PLUS targets, setup here.
| Board | Vendor kernel | Unpatched | Relevant | Affected and compiled |
| Variscite i.MX8M Plus | 6.6.144 | 725 | 117 | 27 |
| Jetson Orin Nano | 5.15.185 | 3444 | 499 | 71 |
Triaging CVEsLinux Kernel, Christoph Steiger, Negar Masoudifar, Siemens, ELCE 2026, Prague
Beyond Strace: Syscall Analysis the Wireshark Way, Roland Knall, Wireshark Foundation
When conducting network traffic analysis, Wireshark is often the go-to tool, offering network packet capture, deep packet inspection and rich filtering support all from a single user interface. This greatly helps in gaining a greater understanding of exactly what is happening on the wire.
Conversely, tracing of system calls at the operating system level is typically performed using tools such as strace and bpftrace. While these tools are excellent at providing visibility into the otherwise hidden syscall interface, you may find yourself left with an overwhelming amount of raw output to sift through, most of which may be irrelevant to the problem at hand. In this case, `grep` is usually the go-to for filtering, but it can only help so much, and regexes can quickly become unwieldy. We can use `strace -e trace=<…>` to filter which syscalls are traced, but this requires knowing ahead of time which syscalls we want to pay interest to. Then we also run the risk of later realising that we need to adjust the filter, and must reproduce the problem while tracing again.
This talk by Roland Knall introduces Stratoshark, developed by the Wireshark Foundation, which aims to address some of these shortcomings. Stratoshark provides the powerful dissection engine of Wireshark, but tailored for the analysis of system call traces. Stratoshark (or the companion `sysdig` utility) can capture a full system-wide syscall trace for all processes on the system. Later, during analysis, we can dig down into the system calls made by our problem application. If we discover that the root of the problem actually originates inside another process, pivoting to inspect this process is easy – we already have a full system capture, all we need to do is adjust the filter.
Just like Wireshark, Stratoshark’s user interface also supports creating plots and IO graphs interactively, which can be a useful way to visualise a problem and explain findings to others.
Currently, Stratoshark is still in early development. As of the time of writing, version 0.10.4 is the most recent release. Support is included for four different syscall capture sources: `dumpcalls` for local system calls, `sshdig` for tracing calls on a remote host over SSH, `falcodump` to inspect Falco plugin logs, and additionally support for reading `.scap` files produced by `sysdig`.
Beyond Strace: Syscall Analysis the Wireshark Way, Roland Knall, Wireshark Foundation, ELCE 2026, Prague
Rsinit – a Tiny Initramfs Toolbox for Embedded Systems, Michael Olbrich, Pengutronix
In embedded systems, an initramfs becomes necessary whenever the kernel alone cannot do everything required to mount the root file-system – such as running user space utilities associated with mounting encrypted or verified file-systems. However, an initramfs comes with trade-offs: it adds another root file-system to build and maintain, and will always increase boot time.
Fortunately, Michael Olbrich and the team at Pengutronix developed rsinit, an open source, statically linked Rust binary that acts as the init process to mount the root file-system as quickly and simply as possible. It is small (under 450 KB using musl), fast, and robust. We are excited to see how rsinit develops and look forward to using it in our future projects.
For more information, take a look at the GitHub project page.
Conclusion
There were a lot of interesting talks this year and we have only scratched the surface, if like us, you have missed some of them while being there, the talks are archived and can be found here. It was great to see some of the people we know in the community in person and to navigate the pubs in the city of Prague. It was a great event to attend and we are already looking forward to the next OSS 2027 that will be held in Glasgow. It is fair to say that we had enough of pork meat and lager beer after that week.