Open Source Summit + Embedded Linux Conference Europe 2026 (Prague) report and presentation notes
Finally I sufficiently edited my notes for a little belated post on the Open Source Summit + Embedded Linux Conference Europe 2026 in Prague. I was quite excited to attend as it was my first conference/summit, and it certainly delivered. Organizationally, it was handled very well, and there were always plenty of presentations, booths, and activities to attend. The schedule was also planned in such a way that coming up to the booths to talk about projects (which ranged from things like Flatcar container Linux to RISC-V automotive projects and many, many more across the entire open source and embedded space) in-between some talks and during breaks was generally feasible, so over the course of the several-day conference you could visit most if not all of them.
Below I will provide a non-exhaustive list of talks I attended with corresponding notes. I didn't write notes for all of the talks and keynotes I attended, so this list is partial, yet still mostly complete.
October 7th
Triaging CVEs for the Linux Kernel - Christoph Steiger & Negar Masoudifar, Siemens AG
https://hosted-files.sched.co/osselceu2026/79/triaging-cves-for-the-linux-kernel.pdf
- rising number of cves in 2026 (in part due to agentic explosion)
- on average every bug once per 7 days in 2026
- updates not always possible (espesially in embedded with various ctrict certifications)
- maintaining your own kernel fork is too much effort, many companies tried it, many abandoned the idea
- LTS is the way to go for the most part
- presented tool: kernel-cve-triage
- check CVE commit and fixing commit in version history
- find affected config opts with kmax
If you’re not building the file and you never build it – it doesn’t affect you – around 5-10% functionality of the kernel may actually be used in the build (personal note: similar to how our usage of brain capabilities is limited compared to its potential).
- kmax helps determing from a file which config options we need to set
- the presented tool takes 1-2 secs per CVE, mostly due to expensive git history lookups
- next: comparison with yocto CVE check
- yocto starting point: CVE -> check whether version is affected or not -> build the kernel, extract include files from debuginfo during building, check if affected files are built
- minor difference: yocto needs to build the kernel to extract info, while the presented tool just needs the source tree to determine the affected files and configs, no need for building empirical comparison or same kernel version and same config:
- patched and unpatched classification: tools are similar
- main difference: ignored category
- reasons: file determination can fail
- kmax sometimes fails to determine the relevant config
Shown approaches filter around 80 percent of CVEs, likely it’s the ceiling possible. Auhors suggest adding affected Kconfig in vulnerability reports (kernel CVEs), use LTS and SLTS (Super LTS), join communities like CIP.
Relevant links:
https://gitlab.com/cip-project
Reproducible Embedded Linux Testing From Laptop To CI To Scale - Anders Roxell, Linaro
https://hosted-files.sched.co/osselceu2026/32/Reproducible%20embedded%20linux%20testing.pdf
ARM CCA on QEMU * OP-TEE on QEMU and RPI 4
- OP-TEE and CCA are not one project
- OP-TEE: TF-A, OP-TEE, u-boot, linux …
- CCA: TF-A, TF-RMM, EDK2, Linux/kvm, qemu, guest/rootfs
Then there is FVP (ARM virtualization platform)
Overall: tuxmake (linux( tuxfirmware (tf-a, op-tee, userspace) tuxuboot (u-boot) shrinkwrap (CCA) → artifacts → tuxrun (qemu, fvp, board)
https://github.com/kernelci/tuxmake
local: python command, local/url files, build/test locally: cloud: yaml…
Overall I felt like the talk didn't really get its point across (at least to me) and was a bit confusing with its pacing. It ended 20 mins before schedule with no questions so maybe it's not just me who was a bit bamboozled :)
Keynote: Open Source at a Crossroads: Geopolitics, Sovereignty, and the Fight to Stay Open - Nithya Ruff, Chair, Linux Foundation Board & Johan Linaker, Senior Researcher, RISE Research Institutes of Sweden & Adjunct Assistant Professor, Lund University
Central point: open source enables govs to collaborate even with rivalry present; industry learned the lesson: open source their own code, co-invest in shared projects and solve problems. Should govs do the same?
In the end there was a list of sovereign AI projects by country (not exhaustive of course): Teuken, llm-jp, openeurollm, aperitus, sea-lion.
Personally I think collaboration would of course ease up tensions, but we should account for the fact that some govs may use others' open source advancements for their own malicious goals while not really sharing their own achievents. So there is a bit of a game-theoretic problem here.
What Is Linux Doing With My RAM? - Vlastimil Babka, SUSE Labs
https://hosted-files.sched.co/osselceu2026/1e/vbabka-linux-memory.pdf
Off the Laptop, Into Production: An Open Source Stack for AI Agents on Kubernetes - Brian Hammons & Nirmal Mehta, Amazon Web Services
Topic: how to run at scale prod agents
The presenters distinguish between outer/inner loop and related tooling
Outer: infra (shared): k8s, VPC, Karpenter, ArgoCD, ACK (AWS Controllers for Kubernetes)
outer (how you operate): build: gitlab /ci/cd/registry
deploy/dispatch: argo for gitops, karpenter for autoscale observability/evaluation: langfuse memory: milvus for vector db
inner loop: agent lifecycle loop request sandbox -> network policy -> identity bound -> harness config -> pod executes -> observe&store -> shutdown/pause/restart
projects for :1) agent orchestrator 2) inference gateway, 3) memory&context 4) sandbox 5) identity 6) network policy
Making the Kernel Chat: How To Get Debug Output - Richard Weinberger, sigma star gmbh
Interesting parallel talk that I would have liked to attend as well:
https://hosted-files.sched.co/osselceu2026/85/kernel-output-debugging.pdf
A Surprisingly Hard Question: How Much Memory Does My System Use? - Richard Weinberger, sigma star gmbh
https://hosted-files.sched.co/osselceu2026/5a/linux-ramusage_oss2026.pdf
This talk was a little bit more practical/workshop-ish with various tools and commands presented to learn about Linux memory usage (which is a huge topic). No, seriously, it's HUGE:
https://nostarch.com/linux-memory-manager
What you definitely need to remember though is the difference between SLAB, SLOB and SLUB :p
Also useful-to-know about
https://docs.kernel.org/mm/damon/index.html
There was a related talk (I didn't attend):
https://hosted-files.sched.co/osselceu2026/67/damon_howto.pdf
Kata at Scale: The Hidden Cost of Running VMs Behind Every Container - Kavitha Daula & Nigel Douglas, Edera
Edera is supposedly an alternative to Kata as a full-fledged platform. The presenters describe their experience and troubles with kata containers. Specifically, kata adds lots of complexity due to its architecture compared to “just containers" (true enough). You now have to manage a ton of stuff regarding the guest kernel – it’s part of the workload. Performance, modules, CVEs, etc. That is, the kernel is no longer infrastructure, it’s production artifact. If you add confidential containers (note: e.g. CoCo, EdgelessSystems Contrast, etc) to that, it becomes even more complex.
Some personal note: while the listed problems are true, I don't think they're necessarily a strong enough argument against Kata - I mean, everything today is so complex, so what's another convoluted project to manage, right? Although I can actually add even more examples that make Kata harder to use - for instance, while with "just containers" like Docker, Podman, cri-o, etc we have a rather established software stack for monitoring, tracing, observability of containers, we don't really have that with Kata, and what we do have is very limited compared to the mainstream (same problem exists with plenty of other heterodox approaches to containers, like gVisor, firecracker-containerd and so on, which happened to be one of the central topics of my Bachelor thesis, so I was pretty curious about the talk and shared production experience). In other words, in addition to managing Kata, we will also need to (largely manually) do a lot of instrumentation of existing tooling (whether eBPF-based or not) due to the idiosyncracies of Kata's architecture, or write our own tooling from scratch just to reproduce a traditional monitoring/observability/tracing stack with Kata - which is in addition to managing the lifecycle of Kata itself. Still, I feel like Kata and projects building on it, like confidential containers, offer benefits that are just too exciting to be outweighted by the added layers of complexity.
Embracing Service-Oriented Connectivity Across OpenStack and Kubernetes - Mitsuhiro Tanino & Rei Shimizu, LY Corporation
https://hosted-files.sched.co/osselceu2026/23/OSS_EU2026_Embracing_Service-Oriented_Connectivity.pdf
Presenters give on overview of their Flava Openstack-based cloud platform
athenz = authN + authZ
https://github.com/AthenZ/athenz
configuration repository
https://github.com/line/centraldogma
Microservice framework
They further describe their custom Service Connect implementation with plenty of detail
In their view, fewer boots is better than having hidden failures in half-working VMs (regarding their NOVA-based solution based on Openstack)
Life Finds a Way, Sandboxed Agents, Observable Verdicts - Henrik Rexed, Dynatrace
Setting the stage: intro to some CVEs related to deepseek and flowise; another 2 CVEs related to lack of authentication (regarding ryflow and 9r) k8s agentsandbox operator – scale and isolate agents in the cluster
https://github.com/kubernetes-sigs/agent-sandbox
Available runtimeclasses: gvisor, kata, firecracker, runc (default) Demo with openclaw, tetragon, other tools
Results: runc host syscalls: 6000 in 30 mins gVisor: 996
Sandlock: Rootless and Containerless Confinement for AI Agents - Cong Wang, Multikernel Technologies
https://hosted-files.sched.co/osselceu2026/39/sandlock-oss-eu.pdf
Problem statement: agents do many commands which need various permissions
sandlock wraps every command with its containment mechanism sandlock: rootless, containerless, cgroup-less, based on landlock + seccomp-bpf + seccomp user notifications
https://github.com/multikernel/sandlock
*October 8th
When the Kernel Writes Its Own Code: Debugging Runtime-Generated Instructions - Alexis Lothoré, Bootlin
https://hosted-files.sched.co/osselceu2026/e9/lothore-ebpf-debugging.pdf
Talk on debugging the kernel with gdb (note: interesting to know why pwndbg or GEF were not considered as alternatives to fine-tuning vanilla gdb) Useful tool:
https://github.com/arighi/virtme-ng
primer on KASAN, shadow memory memory granule (8 bytes) and corresponding shadow memory: 1:1 mapping then an example of custom gdb function to investigate shadow memory related to memory region Misc: gdb TUI! (C-x-C-a, TUI view is customizable, C-x s enters single-key mode)
problem: runtime-generated code by example of eBPF programs. Also: increasingly good eBPF support in GCC See e.g.:
https://lwn.net/Articles/1071973/
Side note: Bootlin has excellent training slides available for other topics that I highly recommend to check out
Own Your Stack: Sovereign Kubernetes From Bare Metal To Fleet - Sunnatillo Samadov, Ericsson & Bharath N R, Mirantis Inc.
Sovereign AI infra: motivation Challenges: server provisioning, cluster lifecycle (manage them without cloud API), fleet consistency, drift, no lock-in (modular open-source) k8s: GPU allocation with DRA (dynamic resource allocation)
https://github.com/kubernetes-sigs/dra-driver-nvidia-gpu
https://github.com/kubernetes-sigs/dra-example-driver
https://kubernetes.io/blog/2025/09/01/kubernetes-v1-34-dra-updates/
Suggested stack: k0rdent, cluster API, metal3 + baremetal GPU servers and AI workloads
k0rdent has components like cluster manager (built on cluster api, flux, k0smotron), state manager (project sveltos as a base); k0rdent observability and finops (based on opentelemetry, victoriametrics, opencost)
Primer on baremetalhost kind yaml file with various fields like bootMode: UEFI and so on
tradeoffs of your own stack: hardware operations, no managed services, slower scale-out, planned capacity
Beyond Strace: Syscall Analysis the Wireshark Way - Roland Knall, Wireshark Foundation
Talk on Stratoshark It finally has a website! When I encountered this project it was just in a repo. The site reportedly went live just before the talk :)
One thing briefly mentioned during the talk regarding comparison with other tools: strace can do fault injection! I didn't know this:
Rsinit – A Tiny Initramfs Toolbox for Embedded Systems - Michael Olbrich, Pengutronix
https://hosted-files.sched.co/osselceu2026/c6/rsinit.pdf
https://github.com/pengutronix/rsinit
LibreCar: Android Auto on Mobile Linux - Petr Hodina, SolderChef
https://gitlab.com/solderchef/libreauto
Some related/mentioned projects:
https://github.com/mobile-nixos/mobile-nixos
Using the Linux Tracing Infrastructure and eBPF for Latency Analysis - Jan Altenberg, Open Source Automation Development Lab (OSADL) eG
https://hosted-files.sched.co/osselceu2026/14/OSSEU_2026-Latency_analysis-Altenberg.pdf
Caching in the Storage Path - How To Gain Performance Without Loosing Data - Werner Fischer, Thomas-Krenn.AG
(wanted to attend this talk but in the end went to another one mentioned next)
*Your Agent Did What? Forensic Observability for Systems That Don’t Leave Obvious Footprints - Adriana Villela, Dynatrace & Kasper Borg Nissen, Dash0 *
Lots of useful projects mentioned, including https://github.com/perses/perses
(waiting for the slides for other links).
Though I have a feeling I should have gone to the previous talk (that track was more technical-ish in terms of details)
October 9th
On this day, the first 4 keynote speakers were fortunate enough to be placed before Linus Torvalds so the congress hall was packed full :) In parallel: another worthwhile talk by a Bootlin guy, would have liked to attend but I like that Bootlin's slides are always super informative
XDP & XSK Support From a Linux Driver Standpoint - Théo Lebrun, Bootlin
https://hosted-files.sched.co/osselceu2026/01/tleb-xdp.pdf
Keynote: Linus Torvalds, Creator of Linux & Git, in Conversation with Dirk Hohndel, Head of Ericsson Software Technology, Ericsson
A comfy talk about all kinds of topics, from pre-Git times and version control systems to (closer to the end) AI, sashiko and vibecoding (surprised that LT is softer on that now, at least for personal exploratory projects). Seeing Linux Torvalds in person for the first time was kinda similar to seeing Richard Stallman many years ago - they both don't really care about publicity and fame, and act fairly humbly. I like that.
A Native API for Linux Systems With Systemd + Varlink - Lennart Poettering, Amutable
Lennart Poettering had two presentations in a row, and he surely talks fast. Among other things, he announced a desire to eventually switch to Varlink from D-Bus.
The Little-Known Mechanism for Securely Parameterizing Systemd Services - Lennart Poettering, Amutable
Systemd-credentials talk
Keeping Track of Resources in the Kernel - Overview and Pitfalls of Resource Management Mechanisms - Bartosz Golaszewski, Qualcomm
https://hosted-files.sched.co/osselceu2026/0c/OSS%202026%20Prague.pdf
Lots of talking about devices and devres
Workshop: Linux Containers In (Less Than) 100 Lines of Shell - Michael Kerrisk, man7.org Training and Consulting
Somehow this talk felt very comfy, I guess due to the didactic talent of Michael Kerrisk. Great to see some of the things I know in such a gentle way, while also providing new interesting details that I didn't know about (although he didn't have time to finish all slides despite the session being so long :))
Who Watches the Watcher? Hardening eBPF in Production Security Deployments - Hanshal Mehta, Independent
I was curious to see a talk by someone also interested in eBPF (in)security shenanigans (I did that a lot during my Bachelor thesis), although this talk ended up being more about some specific vulnerabilities in eBPF-based tools while not going into that much detail about eBPF itself and its (in)security, which is quite a growing (though still relatively niche) field of research both in academia (e.g. securing eBPF verifier or providing alternatives to it) and industry (e.g. studying eBPF-based rootkits in the wild). Still, it was interesting to see some of the issues the presenter found in tools like Tetragon.
A Surprisingly Hard Question: How Much Memory Does My System Use? - Richard Weinberger, sigma star gmbh
https://hosted-files.sched.co/osselceu2026/5a/linux-ramusage_oss2026.pdf
Another practical workshop-ish talk by the presenter with useful insights on troubleshooting memory consumption on Linux.
Well, that was a long post and a good memory. Hopefully, I am going to provide similar posts about future conferences I attend as well (which I certainly would like to do).