THE LINUX FOUNDATION PROJECTS
Category

Ambassadors

Dec 10
Schrödinger’s test: The /dev/mem case - Blog by Alessandro Carminati, Red Hat

Schrödinger’s test: The /dev/mem case

By Ambassadors, Blog

This blog was originally published by Alessandro Carminati, Principal Software Engineer at Red Hat, on his personal blog and is republished here with permission.

Why I Went Down This Rabbit Hole

Back in 1993, when Linux 0.99.14 was released, /dev/mem made perfect sense. Computers were simpler, physical memory was measured in megabytes, and security basically boiled down to: “Don’t run untrusted programs.”

Fast-forward to today. We have gigabytes (or terabytes!) of RAM, multi-layered virtualization, and strict security requirements… And /dev/mem is still here, quietly sitting in the kernel, practically unchanged… A fossil from a different era. It’s incredibly powerful, terrifyingly dangerous, and absolutely fascinating.

My work on /dev/mem is part of a bigger effort by the ELISA Architecture working group, whose mission is to improve Linux kernel documentation and testing. This project is a small pilot in a broader campaign: build tests for old, fundamental pieces of the kernel that everyone depends on but few dare to touch.

In a previous blog post, “When kernel comments get weird”, I dug into the /dev/mem source code and traced its history, uncovering quirky comments and code paths that date back decades. That post was about exploration. This one is about action: turning that historical understanding into concrete tests to verify that /dev/mem behaves correctly… Without crashing the very systems those tests run on.

What /dev/mem Is and Why It Matters

/dev/mem is a character device that exposes physical memory directly to userspace. Open it like a file, and you can read or write raw physical addresses: no page tables, no virtual memory abstractions, just the real thing.

Why is this powerful? Because it lets you:

  • Peek at firmware data structures,
  • Poke device registers directly,
  • Explore memory layouts normally hidden from userspace.

It’s like being handed the keys to the kingdom… and also a grenade, with the pin halfway pulled.

A single careless write to /dev/mem can:

  • Crash the kernel,
  • Corrupt hardware state,
  • Or make your computer behave like a very expensive paperweight.

For me, that danger is exactly why this project matters. Testing /dev/mem itself is tricky: the tests must prove the driver works, without accidentally nuking the machine they run on.

STRICT_DEVMEM and Real-Mode Legacy

One of the first landmines you encounter with /dev/mem is the kernel configuration option STRICT_DEVMEM.

Think of it as a global policy switch:

  • If disabled, /dev/mem lets privileged userspace access almost any physical address: kernel RAM, device registers, firmware areas, you name it.
  • If enabled, the kernel filters which physical ranges are accessible through /dev/mem. Typically, it only permits access to low legacy regions, like the first megabyte of memory where real-mode BIOS and firmware tables traditionally live, while blocking everything else.

Why does this matter? Some very old software, like emulators for DOS or BIOS tools, still expects to peek and poke those legacy addresses as if running on bare metal. STRICT_DEVMEM exists so those programs can still work: but without giving them carte blanche access to all memory.

So when you’re testing /dev/mem, the presence (or absence) of STRICT_DEVMEM completely changes what your test can do. With it disabled, /dev/mem is a wild west. With it enabled, only a small, carefully whitelisted subset of memory is exposed.

A Quick Note on Architecture Differences

While /dev/mem always exposes what the kernel considers physical memory, the definition of physical itself can differ across architectures. For example, on x86, physical addresses are the real hardware addresses. On aarch64 with virtualization or secure firmware, EL1 may only see a subset of memory through a translated view, controlled by EL2 or EL3.

The main function that the STRICT_DEVMEM kernel configuration option provides in Linux is to filter and restrict access to physical memory addresses via /dev/mem. It controls which physical address ranges can be legitimately accessed from userspace by helping implement architecture-specific rules to prevent unsafe or insecure memory accesses.

32-Bit Systems and the Mystery of High Memory

On most systems, the kernel needs a direct way to access physical memory. To make that fast, it keeps a linear mapping: a simple, one-to-one correspondence between physical addresses and a range of kernel virtual addresses. If the kernel wants to read physical address 0x00100000, it just uses a fixed offset, like PAGE_OFFSET + 0x00100000. Easy and efficient.

But there’s a catch on 32-bit kernels: The kernel’s entire virtual address space is only 4 GB, and it has to share that with userspace. By convention, 3 GB is given to userspace, and 1 GB is reserved for the kernel, which includes its linear mapping.

Now here comes the tricky part: Physical RAM can easily exceed 1 GB. The kernel can’t linearly map all of it: there just isn’t enough virtual address space.

The extra memory beyond the first gigabyte is called highmem (short for high memory). Unlike the low 1 GB, which is always mapped, highmem pages are mapped temporarily, on demand, whenever the kernel needs them.

Why this matters for /dev/mem: /dev/mem depends on the permanent linear mapping to expose physical addresses. Highmem pages aren’t permanently mapped, so /dev/mem simply cannot see them. If you try to read those addresses, you’ll get zeros or an error, not because /dev/mem is broken, but because that part of memory is literally invisible to it.

For testing, this introduces extra complexity:

  • Some reads may succeed on lowmem addresses but fail on highmem.
  • Behavior on a 32-bit machine with highmem is fundamentally different from a 64-bit system, where all RAM is flat-mapped and visible.

Highmem is a deep topic that deserves its own article, but even this quick overview is enough to understand why it complicates /dev/mem testing.

How Reads and Writes Actually Happen

A common misconception is that a single userspace read() or write() call maps to one atomic access to the underlaying block device. In reality, the VFS layer and the device driver may split your request into multiple chunks, depending on alignment and boundaries, in this case.

Why does this happen?

  • Many devices can only handle fixed-size or aligned operations.
  • For physical memory, the natural unit is a page (commonly 4 KB).

When your request crosses a page boundary, the kernel internally slices it into:

  1. A first piece up to the page boundary,
  2. Several full pages,
  3. A trailing partial page.

For /dev/mem, this is a crucial detail: A single read or write might look seamless from userspace, but under the hood it’s actually several smaller operations, each with its own state. If the driver mishandles even one of them, you could see skipped bytes, duplicated data, or mysterious corruption.

Understanding this behavior is key to writing meaningful tests.

Safely Reading and Writing Physical Memory

At this point, we know what /dev/mem is and why it’s both powerful and terrifying. Now we’ll move to the practical side: how to interact with it safely, without accidentally corrupting your machine or testing in meaningless ways.

My very first test implementation kept things simple:

  • Only small reads or writes,
  • Always staying within a single physical page,
  • Never crossing dangerous boundaries.

Even with these restrictions, /dev/mem testing turned out to be more like diffusing a bomb than flipping a switch.

Why “success” doesn’t mean success (in this very specific case)

Normally, when you call a syscall like read() or write(), you can safely assume the kernel did exactly what you asked. If read() returns a positive number, you trust that the data in your buffer matches the file’s contents. That’s the contract between userspace and the kernel, and it works beautifully in everyday programming.

But here’s the catch: We’re not just using /dev/mem; we’re testing whether /dev/mem itself works correctly.

This changes everything.

If my test reads from /dev/mem and fills a buffer with data, I can’t assume that data is correct:

  • Maybe the driver returned garbage,
  • Maybe it skipped a region or duplicated bytes,
  • Maybe it silently failed in the middle but still updated the counters.

The same goes for writes: A return code of “success” doesn’t guarantee the write went where it was supposed to, only that the driver finished running without errors.

So in this very specific context, “success” doesn’t mean success. I need independent ways to verify the result, because the thing I’m testing is the thing that would normally be trusted.

Finding safe places to test: /proc/iomem

Before even thinking about reading or writing physical memory, I need to answer one critical question:

“Which parts of physical memory are safe to touch?”

If I just pick a random address and start writing, I could:

  • Overwrite the kernel’s own code,
  • Corrupt a driver’s I/O-mapped memory,
  • Trash ACPI tables that the system kernel depends on,
  • Or bring the whole machine down in spectacular fashion.

This is where /proc/iomem comes to the rescue. It’s a text file that maps out how the physical address space is currently being used. Each line describes a range of physical addresses and what they’re assigned to.

Here’s a small example:

By parsing /proc/iomem, my test program can:

  1. Identify which physical regions are safe to work with (like RAM already allocated to my process),
  2. Avoid regions that are reserved for hardware or critical firmware,
  3. Adapt dynamically to different machines and configurations.

This is especially important for multi-architecture support. While examples here often look like x86 (because /dev/mem has a long history there), the concept of mapping I/O regions isn’t x86-specific. On ARM, RISC-V, or others, you’ll see different labels… But the principle remains exactly the same.

In short: /proc/iomem is your treasure map, and the first rule of treasure hunting is “don’t blow up the ship while digging for gold.”

The Problem of Contiguous Physical Pages

Up to this point, my work focused on single-page operations. I wasn’t hand-picking physical addresses or trying to be clever about where memory came from. Instead, the process was simple and safe:

  1. Allocate a buffer in userspace, using mmap() so it’s page-aligned,
  2. Touch the page to make sure the kernel really backs it with physical memory,
  3. Walk /proc/self/pagemap to trace which physical pages back the virtual address in the buffer.

This gives me full visibility into how my userspace memory maps to physical memory. Since the buffer was created through normal allocation, it’s mine to play with, there’s no risk of trampling over the kernel or other userspace processes.

This worked beautifully for basic tests:

  • Pick a single page in the buffer,
  • Run a tiny read/write cycle through /dev/mem,
  • Verify the result,
  • Nothing explodes.

But then came the next challenge: What if a read or write crosses a physical page boundary?

Why boundaries matter

The Linux VFS layer doesn’t treat a read or write syscall as one giant, indivisible action. Instead, it splits large operations into chunks, moving through pages one at a time.

For example:

  • I request 10 KB from /dev/mem,
  • The first 4 KB comes from physical page A,
  • The next 4 KB comes from physical page B,
  • The last 2 KB comes from physical page C.

If the driver mishandles the transition between pages, I’d never notice unless my test forces it to cross that boundary. It’s like testing a car by only driving in a straight line: Everything looks fine… Until you try to turn the wheel.

To properly test /dev/mem, I need a buffer backed by at least two physically contiguous pages. That way, a single read or write naturally crosses from one physical page into the next… exactly the kind of situation where subtle bugs might hide.

And that’s when the real nightmare began.

Why this is so difficult

At first, this seemed easy. I thought:

“How hard can it be? Just allocate a buffer big enough, like 128 KB, and somewhere inside it, there must be two contiguous physical pages.”

Ah, the sweet summer child optimism. The harsh truth: modern kernels actively work against this happening by accident. It’s not because the kernel hates me personally (though it sure felt like it). It’s because of its duty to prevent memory fragmentation.

When you call brk() or mmap(), the kernel:

  1. Uses a buddy allocator to manage blocks of physical pages,
  2. Actively spreads allocations apart to keep them tidy,
  3. Reserves contiguous ranges for things like hugepages or DMA.

From the kernel’s point of view:

  • This keeps the system stable,
  • Prevents large allocations from failing later,
  • And generally makes life good for everyone.

From my point of view? It’s like trying to find two matching socks in a dryer while it is drying them.

Playing the allocation lottery

My first approach was simple: keep trying until luck strikes.

  1. Allocate a 128 KB buffer,
  2. Walk /proc/self/pagemap to see where all pages landed physically,
  3. If no two contiguous pages are found, free it and try again.

Statistically, this should work eventually. In reality? After thousands of iterations, I’d still end up empty-handed. It felt like buying lottery tickets and never even winning a free one.

The kernel’s buddy allocator is very good at avoiding fragmentation. Two consecutive physical pages are far rarer than you’d think, and that’s by design.

Trying to confuse the allocator

Naturally, my next thought was:

“If the allocator is too clever, let’s mess with it!”

So I wrote a perturbation routine:

  • Allocate a pile of small blocks,
  • Touch them so they’re actually backed by physical pages,
  • Free them in random order to create “holes.”

The hope was to trick the allocator into giving me contiguous pages next time. The result? It sometimes worked, but unpredictably. 4k attempts gave me >80% success. Not reliable enough for a test suite where failures must mean a broken driver, not a grumpy kernel allocator.

The options I didn’t want

There are sure-fire ways to get contiguous pages:

  • Writing a kernel module and calling alloc_pages().
  • Using hugepages.
  • Configuring CMA regions at boot.

But all of these require special setup or kernel cooperation. My goal was a pure userspace test, so they were off the table.

A new perspective: software MMU

Finally, I relaxed my original requirement. Instead of demanding two pages that are both physically and virtually contiguous, I only needed them to be physically contiguous somewhere in the buffer.

From there, I could build a tiny software MMU:

  • Find a contiguous physical pair using /proc/self/pagemap,
  • Expose them through a simple linear interface,
  • Run the test as if they were virtually contiguous.

This doesn’t eliminate the challenge, but it makes it practical. No kernel hacks, no special boot setup, just a bit of clever user-space logic.

From Theory to Test Code

All this theory eventually turned into a real test tool, because staring at /proc/self/pagemap is fun… but only for a while. The test lives here:

github.com/alessandrocarminati/devmem_test

It’s currently packaged as a Buildroot module, which makes it easy to run on different kernels and architectures without messing up your main system. The long-term goal is to integrate it into the kernel’s selftests framework, so these checks can run as part of the regular Linux testing pipeline. For now, it’s a standalone sandbox where you can:

  • Experiment with /dev/mem safely (on a test machine!),
  • Play with /proc/self/pagemap and see how virtual pages map to physical memory,
  • Try out the software MMU idea without needing kernel modifications.

And expect it still work in progress.

Nov 11
ELISA Project - Open Source Summit: Tokyo, Japan 2025

ELISA Project at Open Source Summit: Tokyo, Japan 2025

By Ambassadors, Blog, Critical Software Summit, Safety-Critical Software Summit

Open Source Summit is the place to connect directly with the people shaping open source – maintainers, developers, and community leaders, while learning from their experience and insights. It’s an opportunity to discover emerging technologies, explore practical solutions you can apply immediately, and collaborate on ideas and code that drive projects forward. Whether you’re looking to grow your skills, expand your network, or advance your career, the summit offers a unique environment to learn, contribute, and be part of the momentum powering the future of open source.

ELISA project will be represented by our community members at the Safety Critical Track.

This track explores the intersection of open source and safety standards, covering best practices for regulatory compliance, security updates, and safety engineering. Sessions will delve into requirements traceability, quality assessments, safety analysis methodologies, and technical development for safety-critical systems. Learn more.

Track Highlights:

1. Keynote: Space Grade Linux: Building a Safer, Open Source Future for Space Systems – Ramon Roche, General Manager, Dronecode Foundation

As launch cadence increases and development cycles tighten, the space industry turns to open source to meet the moment. Enter Space Grade Linux (SGL) — an initiative under the ELISA Project aimed at creating a reusable, safety-aware Linux foundation for spaceflight systems.

This talk will introduce the goals and current status of SGL, highlighting three foundational focus areas:
1. Kernel Configuration – Defining a shared starting point for space-focused Linux systems, emphasizing predictability, determinism, and traceability.
2. Booting into Linux: Exploring the safety-critical implications of system bring-up and strategies for improving reliability in space-grade deployments.
3. Userspace Strategy – Discussing early-stage decisions around minimal runtime environments, supervision, and what a safe, maintainable userspace might look like.

Attendees will get a hands-on overview of what’s already available in the GitHub repository, including a Yocto-based reference implementation and working kernel configuration. More importantly, they’ll learn how to get involved — through technical contributions, architecture discussions, or community collaboration.

2. A Human-Centric Quality Assurance Process for Open Source Software Projects – Wendi Urribarri & Carlos Ramirez, Woven by Toyota – Wednesday December 10, 2025 11:10 – 11:50 JST

As autonomous systems become part of our daily environments, ensuring software quality is critical, especially when defects can cause physical harm. In safety-critical domains like automotive, functional safety must be supported by development processes that ensure high quality and reliability, not only for embedded systems but also, in some cases, for software tools.

This talk presents an approach to support quality assurance of open source software projects. What sets this effort apart is the proposed integration of a human-centric quality strategy, rooted in human-error research informed by cognitive psychology and human factors, in the development process of these projects. We introduce a defect prediction engine designed to anticipate common error modes, enabling proactive defect prevention, focused code reviews, and targeted documentation checks. Our approach offers a fresh perspective on improving software quality across domains while aligning with the expectations of safety-critical frameworks.

3. Comparison and Proposal of Vulnerability Management Approaches in Yocto-Based Linux for the CRA – Akihiko Takahashi, Fujitsu Limited – Wednesday December 10, 2025 12:00 – 12:40 JST

Fujitsu has long provided multilateral support for SPDX, especially through activities in Yocto and SPDX. From 2016, we have been joining maintainers of meta-spdxscanner, enabling SPDX functionality for the Yocto Project. In 2024, We joined OpenSSF to enhance the security and trustworthiness of the global software supply chain. This marked a step forward in our continued dedication to this mission.

Due to the EU CRA, manufacturers in the EU will be obligated to report vulnerabilities starting in September 2026. In the context of Yocto, several vulnerability management approaches are being considered, such as cve-check, yocto-vex-check, and third-party tools. However, as of now, there is no clearly established best practice.
In this session, we will apply these vulnerability management approaches to practical use cases relevant to manufacturers covered by the CRA. The comparison includes the use of SBOMs and VEX to evaluate the effectiveness of each method. Through this analysis, we will clarify the strengths and challenges of vulnerability management in Yocto-based Linux and propose which approach is most suitable depending on the context.

4. Driving Safety Forward: Lessons Learned From Deploying OSS in Real-world Automotive – Jaylin Yu, EMQ – Wednesday December 10, 2025 14:00 – 14:40 JST

While OSS in Automotive is seen as the holy grail to solve SDV complexity challenges with faster time to market and higher performance, it still lacks practical real-world examples and showcases that address OSS usage in compliance with the stringent safety and security demands of Automotive.
In this talk, the author shares his real-world story of bringing OSS into mass production vehicles. This includes the impact of a healthy open-source community and how academic research helped solve security gaps, leading to increased system stability. This also embraces the impact of the software supply chain, providing a proven approach, refined through failures, helping to lower dependency risk for MQTT-based remote vehicle diagnostics.
The session is rounded out by highlighting the link between system utilities and safety functions, covering time synchronization, dependency management, and data integrity within a Linux system, which impact the selection of a file system, and what happens when a customer suddenly requires STR.
The audience will leave the session with a holistic impression of what to consider when creating a secure, safe, OSS-based SDV automotive system.

5. Decoding Safe(ty) Linux Architectural Approaches for Critical Systems – Philipp Ahmann, Etas GmbH – Wednesday December 10, 2025 14:50 – 15:30 JST

For years, diverse interpretations about what it means to “enable Linux in safety applications” exist – an observation spanning multiple industries but particularly pronounced in automotive. With its long history of Linux adoption (like AGL) and current software-defined vehicle (SDV) innovation challenges, the automotive sector is undergoing a transition by both manufacturers and suppliers seeking to implement Linux also in safety critical production systems.

This presentation intends to resolve confusion around the terminology “safety Linux” versus “safe Linux”, clarifying where safety responsibility is allocated to Linux itself versus handled at the system level. By examining architectural system concepts currently implemented in products or under development, the author cuts through marketing rhetoric to provide clear distinctions between approaches. It showcases solutions employed by distributors and identifies crucial elements for safety argumentation like watchdog & monitoring.

Attendees will gain practical insights for evaluating safety approaches in Linux-based systems, including key questions to ask when assessing different safety concepts.

6. LF Energy 101: How Open Source Is Powering the Digital Energy Transition – Darshan Chawda & Nao Nishijima, Hitachi -Wednesday December 10, 2025 16:40 – 17:20 JST

The current energy sector must shift from legacy control systems, which are rigid and hardware-bound, to digital, software-defined systems that enable greater sustainability, resilience, and intelligence. To support this transformation, LF Energy, a Linux Foundation initiative, has empowered industrial partners for over seven years to collaborate through community-driven OSS projects, accelerating innovation across the digital energy ecosystem.

This talk offers a beginner-friendly introduction to LF Energy and its key projects, with a demo highlighting their role in virtualizing substations, forecasting energy, and simplifying operations through automation. These projects show how IT and AI technologies enhance grid safety, which is critical because failures in energy systems can disrupt public infrastructure. However, unlike pure IT systems, energy infrastructure relies heavily on physical hardware, making large-scale digital adoption more complex. LF Energy’s open innovation model, focused on IT/OT convergence, helps overcome these barriers by enabling redundancy, virtualization, and collaborative development, which leads to a more reliable and intelligent energy future.

Learn more about the event and register here.

Sep 08
ELISA Project - Blog: When Kernel Comments Get Weird: The Tale of `drivers/char/mem.c`

When Kernel Comments Get Weird: The Tale of `drivers/char/mem.c`

By Ambassadors, Blog, Working Group

This blog is written by Alessandro Carminati, Principal Software Engineer at Red Hat and lead for the ELISA Project’s Linux Features for Safety-Critical Systems (LFSCS) WG.

As part of the ELISA community, we spend a good chunk of our time spelunking through the Linux kernel codebase. It’s like code archeology: you don’t always find treasure, but you _do_ find lots of comments left behind by developers from the ’90s that make you go, “Wait… really?”

One of the ideas we’ve been chasing is to make kernel comments a bit smarter: not only human-readable, but also machine-readable. Imagine comments that could be turned into tests, so they’re always checked against reality. Less “code poetry from 1993”, more “living documentation”.

Speaking of code poetry, [here] one gem we stumbled across in `mem.c`:

```
/* The memory devices use the full 32/64 bits of the offset,
 * and so we cannot check against negative addresses: they are ok.
 * The return value is weird, though, in that case (0).
 */
 ```

This beauty has been hanging around since **Linux 0.99.14**… back when Bill Clinton was still president-elect, “Mosaic” was the hot new browser,
and PDP-11 was still produced and sold.

Back then, it made sense, and reflected exactley what the code did.

Fast-forward thirty years, and the comment still kind of applies…
but mostly in obscure corners of the architecture zoo.
On the CPUs people actually use every day?

 

```
$ cat lseek.asm
BITS 64

%define SYS_read    0
%define SYS_write   1
%define SYS_open    2
%define SYS_lseek   8
%define SYS_exit   60

; flags
%define O_RDONLY    0
%define SEEK_SET    0

section .data
    path:    db "/dev/mem",0
section .bss
    align 8
    buf:     resq 1

section .text
global _start
_start:
    mov     rax, SYS_open
    lea     rdi, [rel path]
    xor     esi, esi
    xor     edx, edx
    syscall
    mov     r12, rax        ; save fd in r12

    mov     rax, SYS_lseek
    mov     rdi, r12
    mov     rsi, 0x8000000000000001
    xor     edx, edx
    syscall

    mov     [rel buf], rax

    mov     rax, SYS_write
    mov     edi, 1
    lea     rsi, [rel buf]
    mov     edx, 8
    syscall

    mov     rax, SYS_exit
    xor     edi, edi
    syscall
$ nasm -f elf64 lseek.asm -o lseek.o
$ ld lseek.o -o lseek
$ sudo ./lseek| hexdump -C
00000000  01 00 00 00 00 00 00 80                           |........|
00000008
$ # this is not what I expect, let's double check
$ sudo gdb ./lseek
GNU gdb (Fedora Linux) 16.3-1.fc42
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./lseek...
(No debugging symbols found in ./lseek)
(gdb) b _start
Breakpoint 1 at 0x4000b0
(gdb) r
Starting program: /tmp/lseek

Breakpoint 1, 0x00000000004000b0 in _start ()
(gdb) x/30i $pc
=> 0x4000b0 <_start>:   mov    $0x2,%eax
   0x4000b5 <_start+5>: lea    0xf44(%rip),%rdi        # 0x401000
   0x4000bc <_start+12>:        xor    %esi,%esi
   0x4000be <_start+14>:        xor    %edx,%edx
   0x4000c0 <_start+16>:        syscall
   0x4000c2 <_start+18>:        mov    %rax,%r12
   0x4000c5 <_start+21>:        mov    $0x8,%eax
   0x4000ca <_start+26>:        mov    %r12,%rdi
   0x4000cd <_start+29>:        movabs $0x8000000000000001,%rsi
   0x4000d7 <_start+39>:        xor    %edx,%edx
   0x4000d9 <_start+41>:        syscall
   0x4000db <_start+43>:        mov    %rax,0xf2e(%rip)        # 0x401010
   0x4000e2 <_start+50>:        mov    $0x1,%eax
   0x4000e7 <_start+55>:        mov    $0x1,%edi
   0x4000ec <_start+60>:        lea    0xf1d(%rip),%rsi        # 0x401010
   0x4000f3 <_start+67>:        mov    $0x8,%edx
   0x4000f8 <_start+72>:        syscall
   0x4000fa <_start+74>:        mov    $0x3c,%eax
   0x4000ff <_start+79>:        xor    %edi,%edi
   0x400101 <_start+81>:        syscall
   0x400103:    add    %al,(%rax)
   0x400105:    add    %al,(%rax)
   0x400107:    add    %al,(%rax)
   0x400109:    add    %al,(%rax)
   0x40010b:    add    %al,(%rax)
   0x40010d:    add    %al,(%rax)
   0x40010f:    add    %al,(%rax)
   0x400111:    add    %al,(%rax)
   0x400113:    add    %al,(%rax)
   0x400115:    add    %al,(%rax)
(gdb) b *0x4000c2
Breakpoint 2 at 0x4000c2
(gdb) b *0x4000db
Breakpoint 3 at 0x4000db
(gdb) c
Continuing.

Breakpoint 2, 0x00000000004000c2 in _start ()
(gdb) i r
rax            0x3                 3
rbx            0x0                 0
rcx            0x4000c2            4194498
rdx            0x0                 0
rsi            0x0                 0
rdi            0x401000            4198400
rbp            0x0                 0x0
rsp            0x7fffffffe3a0      0x7fffffffe3a0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x246               582
r12            0x0                 0
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0
rip            0x4000c2            0x4000c2 <_start+18>
eflags         0x246               [ PF ZF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
fs_base        0x0                 0
gs_base        0x0                 0
(gdb) # fd is just fine rax=3 as expected.
(gdb) c
Continuing.

Breakpoint 3, 0x00000000004000db in _start ()
(gdb) i r
rax            0x8000000000000001  -9223372036854775807
rbx            0x0                 0
rcx            0x4000db            4194523
rdx            0x0                 0
rsi            0x8000000000000001  -9223372036854775807
rdi            0x3                 3
rbp            0x0                 0x0
rsp            0x7fffffffe3a0      0x7fffffffe3a0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x246               582
r12            0x3                 3
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0
rip            0x4000db            0x4000db <_start+43>
eflags         0x246               [ PF ZF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
fs_base        0x0                 0
gs_base        0x0                 0
(gdb) # According to that comment, rax should have been 0, but it is not.
(gdb) c
Continuing.
�[Inferior 1 (process 186746) exited normally]
(gdb) 
```

Not so much. Seeking at `0x8000000000000001`…
Returns `0x8000000000000001` not `0` as anticipated in the comment.
We’re basically facing the kernel version of that “Under Construction”
GIF on websites from the 90s, still there, but mostly just nostalgic
decoration now.

## The Mysterious Line in `read_mem`

Let’s zoom in on one particular bit of code in [`read_mem`](https://elixir.bootlin.com/linux/v6.17-rc2/source/drivers/char/mem.c#L82):

```
	phys_addr_t p = *ppos;
	/* ... other code ... */
	if (p != *ppos) return  0;
```

At first glance, this looks like a no-op; why would `p` be different from
`*ppos` when you just copied it?
It’s like testing if gravity still works by dropping your phone…
**spoiler: it does.**

But as usual with kernel code, the weirdness has a reason.

## The Problem: Truncation on 32-bit Systems

Here’s what’s going on:

– `*ppos` is a `loff_t`, which is a 64-bit signed integer.
– `p` is a `phys_addr_t`, which holds a physical address.

On a 64-bit system, both are 64 bits wide. Assignment is clean, the check
always fails (and compilers just toss it out).

But on a 32-bit system, `phys_addr_t` is only 32 bits. Assign a big 64-bit
offset to it, and **boom**, the top half vanishes.
Truncated, like your favorite TV series canceled after season 1.

That `if (p != *ppos)` check is the safety net.
It spots when truncation happens and bails out early, instead of letting
some unlucky app read from la-la land.

## Assembly Time: 64-bit vs. 32-bit

On 64-bit builds (say, AArch64), the compiler optimizes away the check.

```
┌ 736: sym.read_mem (int64_t arg2, int64_t arg3, int64_t arg4);
│ `- args(x1, x2, x3) vars(13:sp[0x8..0x70])
│           0x08000b10      1f2003d5       nop
│           0x08000b14      1f2003d5       nop
│           0x08000b18      3f2303d5       paciasp
│           0x08000b1c      fd7bb9a9       stp x29, x30, [sp, -0x70]!
│           0x08000b20      fd030091       mov x29, sp
│           0x08000b24      f35301a9       stp x19, x20, [var_10h]
│           0x08000b28      f40301aa       mov x20, x1
│           0x08000b2c      f55b02a9       stp x21, x22, [var_20h]
│           0x08000b30      f30302aa       mov x19, x2
│           0x08000b34      750040f9       ldr x21, [x3]
│           0x08000b38      e10302aa       mov x1, x2
│           0x08000b3c      e33700f9       str x3, [var_68h]        ; phys_addr_t p = *ppos;
│           0x08000b40      e00315aa       mov x0, x21
│           0x08000b44      00000094       bl valid_phys_addr_range
│       ┌─< 0x08000b48      40150034       cbz w0, 0x8000df0        ;if (!valid_phys_addr_range(p, count))
│       │   0x08000b4c      00000090       adrp x0, segment.ehdr
│       │   0x08000b50      020082d2       mov x2, 0x1000
│       │   0x08000b54      000040f9       ldr x0, [x0]
│       │   0x08000b58      01988152       mov w1, 0xcc0
│       │   0x08000b5c      f76303a9       stp x23, x24, [var_30h]
[...]
```
Nothing to see here, move along.
But on 32-bit builds (like old-school i386), the check shows up loud and 
proud in the assembly. 
```
[0x080003e0]> pdf
┌ 392: sym.read_mem (int32_t arg_8h);
│ `- args(sp[0x4..0x4]) vars(5:sp[0x14..0x24])
│           0x080003e0      55             push ebp
│           0x080003e1      89e5           mov ebp, esp
│           0x080003e3      57             push edi
│           0x080003e4      56             push esi
│           0x080003e5      53             push ebx
│           0x080003e6      83ec14         sub esp, 0x14
│           0x080003e9      8955f0         mov dword [var_10h], edx
│           0x080003ec      8b5d08         mov ebx, dword [arg_8h]
│           0x080003ef      c745ec0000..   mov dword [var_14h], 0
│           0x080003f6      8b4304         mov eax, dword [ebx + 4] 
│           0x080003f9      8b33           mov esi, dword [ebx]     ; phys_addr_t p = *ppos;
│           0x080003fb      85c0           test eax, eax
│       ┌─< 0x080003fd      7411           je 0x8000410             ; if (!valid_phys_addr_range(p, count))
│     ┌┌──> 0x080003ff      8b45ec         mov eax, dword [var_14h]
│     ╎╎│   0x08000402      83c414         add esp, 0x14
│     ╎╎│   0x08000405      5b             pop ebx
│     ╎╎│   0x08000406      5e             pop esi
│     ╎╎│   0x08000407      5f             pop edi
│     ╎╎│   0x08000408      5d             pop ebp
│     ╎╎│   0x08000409      c3             ret
[...]
```

The CPU literally does a compare-and-jump to enforce it. So yes, this is a _real_ guard, not some leftover fluff.

## Return Value Oddities

Now, here’s where things get even funnier. If the check fails in `read_mem`, the function returns `0`. That’s “no bytes read”, which in file I/O land is totally fine.

But in the twin function `write_mem`, the same situation returns `-EFAULT`. That’s kernel-speak for “Nope, invalid address, stop poking me”.

So, reading from a bad address? You get a polite shrug. Writing to it? You get a slap on the wrist. Fair enough, writing garbage into memory is way more dangerous than failing to read it. Come on, probably here we need to fix things up.

Wrapping It Up

This little dive shows how a single “weird” line of code carries decades of context, architecture quirks, type definitions, and evolving assumptions.
It also shows why comments like the one from 0.99.14 are dangerous: they freeze a moment in time, but reality keeps moving.

Our mission in Elisa Architecture WG is to bring comments back to life: keep them up-to-date, tie them to tests, and make sure they still tell the truth. Because otherwise, thirty years later, we’re all squinting at a line saying “the return value is weird though” and wondering if the developer was talking about code… or just their day.

And now, a brief word from our *sponsors* (a.k.a. me in a different hat): When I’m not digging up ancient kernel comments with the Architecture WG, I’m also leading the Linux Features for Safety-Critical Systems (LFSCS) WG. We’re cooking up some pretty exciting stuff there too.

So if you enjoy the kind of archaeology/renovation work we’re doing there, come check out LFSCS as well: same Linux, different adventure.

Aug 13

ELISA Project Welcomes Simone Weiss to the Governing Board!

By Ambassadors, Blog

We are excited to announce that Simone Weiss, Product Owner at Elektrobit, has joined the Governing Board of the Enabling Linux in Safety Applications (ELISA) Project. She brings a wealth of experience in functional safety, embedded systems, and open source leadership that will help guide ELISA’s mission to enable the use of Linux in safety-critical applications. One of Simone’s first tasks will be to lead the creation of a glossary in the ELISA Project directory.

ELISA Project Welcomes Simone Weiss to the Governing Board!Elektrobit has been an active contributor to the ELISA Project for several years, and Simone’s appointment reflects the company’s commitment to advancing the use of open source technologies in industries such as automotive, industrial, medical, and beyond.

“It’s an honor to join ELISA’s Governing Board. I’m looking forward to working with the community to support collaboration between industry and safety experts and drive broader adoption of Linux in safety-critical domains.” – Simone Weiss, Elektrobit

The ELISA Governing Board plays a critical role in setting the project’s strategic direction, ensuring sustainability, and supporting the vibrant technical community that underpins ELISA’s success. With the addition of Simone, the board strengthens its collective expertise and reaffirms its dedication to transparency, collaboration, and safety excellence.

Simone recently traveled to Open Source Summit North America, which happened in Denver, Colorado in June, to attend her first in-person Governing Board meeting. 

ELISA Project Governing Board 2025

Please join us in welcoming Simone to the ELISA Project Governing Board!

Aug 06
Documenting the Design of the Linux Kernel - Chuck Wolber, The Boeing Company; Kate Stewart, The Linux Foundaiton; Gabriele Paoloni, Red Hat

Talk Highlights: Documenting the Design of the Linux Kernel – Chuck Wolber, The Boeing Company; Kate Stewart, The Linux Foundation; Gabriele Paoloni, Red Hat

By Ambassadors, Blog, Critical Software Summit, Industry Conference, Safety-Critical Software Summit

Open Source Summit North America, which happened on June 23-25 in  Denver, Colorado, had a total of 1,535 in-person attendees (47% hold technical positions) that represented 732 organizations. This year’s event featured vibrant conversations in the Safety-Critical Software track, sponsored by ELISA Project member Honda.

Safety-critical systems — whether in automotive, industrial, medical, or aerospace — are increasingly adopting open source technologies. The sessions in this dedicated track tackled real-world challenges and shared solutions around functional safety, tool qualification, compliance, and certifiability of open source software.

Highlights included:

  • Panel discussions on bridging the gap between open source innovation and safety assurance

  • Technical deep dives into applying safety analysis methods to Linux-based systems

  • Case studies from the ELISA Project working groups showcasing progress in automotive, medical, and industrial domains

This week we are highlighting the talk “Documenting the Design of the Linux Kernel – Chuck Wolber, The Boeing Company; Kate Stewart, The Linux Foundaiton; Gabriele Paoloni, Red Hat” from the Open Source Summit, North America 2025.

Documenting the Design of the Linux Kernel – Chuck Wolber, The Boeing Company; Kate Stewart, The Linux Foundaiton; Gabriele Paoloni, Red Hat

As Linux adoption grows in safety-critical industries like aerospace and automotive, structured design documentation and traceability become increasingly important. This talk presented the ELISA Project’s efforts to reverse-engineer and document low-level developer intent within the Linux kernel using a new, machine-readable requirements template.

Building on earlier discussions at Linux Plumbers 2024 and the December ELISA Workshop at NASA Goddard, the session outlined a proposed framework for capturing “testable expectations” in line with kernel development norms. The goal is to support pass/fail test development, improve test precision using code coverage, and eventually link low-level requirements to higher-level system design.

The speakers showcased early examples from the kernel’s tracing subsystem, discussed the balance between testability and maintainability, and explained how the effort helps address kernel technical debt and reduce certification barriers. The proposal also seeks to avoid burdening maintainers by decoupling documentation from core development.

Key topics included:

  • A breakdown of the proposed requirement template structure and fields
  • Examples of real-world kernel functions instrumented with low-level requirements
  • Integration plans with KernelCI for test coverage and traceability
  • Challenges encountered, such as avoiding pseudo-code duplication and handling evolving code
  • Community feedback from upstream maintainers and next steps toward broader adoption

To learn more and get involved in the Safety Architecture Working Group, check here.

What’s Next?

We’re excited to continue the conversations sparked at OSSummit through our public working groups, monthly meetings and upcoming events. Join the ELISA Project at Open Source Summit Europe, happening on August 25-27 in Amsterdam, at the Safety-Critical Software Summit. Check out the schedule or visit the ELISA Project ambassadors and leaders at the booth #29. Learn more here.

Learn more about the conference or register for it at the main Open Source Summit Europe page.

For more ELISA Project updates, subscribe to the LinkedIn page, Youtube Channel or join the community on our new Discord channel!

May 28

Criteria and Process for Evaluating Open-Source Documentation

By Ambassadors, Blog, Seminar Series

As the open source and safety (and security) communities collaborate more closely, there’s an opportunity to build trust by showcasing how open source development aligns with key safety principles. As part of the ELISA Seminar series, Pete Brink, Principal Consultant at UL Solutions and ELISA Project ambassador, recently presented the process designed to adapt to a variety of projects and contexts, including evaluation criteria.

This video aims to introduce a flexible, practical framework for evaluating documentation that supports trustworthiness in development practices. The goal is to empower teams to highlight their commitment to quality and safety in a way that works for them. Watch here:


The ELISA Seminar Series focuses on hot topics related to ELISA’s mission to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems amenable to safety certification. Speakers are members, contributors and thought leaders from the ELISA Project and surrounding communities. Each seminar comprises a 45-minute presentation and a 15-minute Q&A, and it’s free to attend. You can watch all videos on the ELISA Project Youtube Channel ELISA Seminar Series Playlist here.

For more ELISA Project updates, subscribe to @ProjectElisa or our LinkedIn page or our Youtube Channel.

Feb 13

ELISA Project and Linux Foundation Community Shine at FOSDEM 2025

By Ambassadors, Blog, Critical Software Summit, Industry Conference

Written by Ramon Roche, Dronecode Foundation General Manager and member of Space Grade Linux

Members and collaborators from the ELISA Project and the broader Linux Foundation community were excited to participate in FOSDEM 2025, joining thousands of open source enthusiasts in Brussels for a weekend dedicated to advancing open technology. For those who haven’t yet experienced FOSDEM, it’s difficult to put into words the vibrant, inclusive atmosphere of this registration-free event—it’s something you genuinely have to see and feel for yourself. Imagine developers buzzing between the historic buildings of the Université libre de Bruxelles, eagerly attending talks, sharing ideas, and forging connections over their shared passion for innovation. FOSDEM is more than just a conference; it’s a celebration of open-source collaboration and a testament to the power of community-driven technology.

“FOSDEM is more than just a conference—it’s a cornerstone of the open source world. From discovering new projects in various fields like open source scorecards and NGO-focused CRMs to engaging in critical discussions around the EU’s Cyber Resilience Act, FOSDEM offers unmatched opportunities for learning and collaboration. The hallway track, packed sessions, and the growing interest in AI and open hardware all underscore its role as a vital hub for innovation and community building. It’s where the open source ecosystem thrives, connects, and evolves.”

— Philipp Ahmann, Sr. OSS Community Manager at ETAS GmbH

Exhibits from Sponsors

One of the highlights of FOSDEM 2025 was the lively exhibit area, where attendees flocked to engage with some of the most influential projects and foundations in the open-source ecosystem. The halls were abuzz with energy, making it nearly impossible to walk through without getting swept up in the excitement! Zephyr RTOS had a standout presence among the many exhibits, drawing attention with its innovative real-time operating system solutions. Members of the ELISA community were also actively involved throughout the exhibits, connecting with attendees and sharing insights on safety-critical systems and open-source collaboration.

The FOSDEM community’s love for swag was on full display, with attendees proudly sporting T-shirts, stickers, and other goodies collected from various booths. A major crowd favorite was the Linux Foundation Europe booth, which attracted a steady stream of visitors with its impressive lineup of CNCF project merchandise and exclusive discounts on Linux Foundation training and certifications available only to FOSDEM attendees. The vibrant atmosphere and enthusiasm around the exhibits perfectly captured the spirit of innovation and community that defines FOSDEM.

 

 

Kate Stewart’s Zephyr Open Source Project Best Practices Over Time Presentation

Another highlight of FOSDEM 2025 was Kate Stewart’s talk titled Zephyr: Open Source Project Best Practices Over Time, where she shared insights into how Zephyr RTOS has evolved into a robust and widely adopted platform, now surpassing 100,000 commits in its main repository. Drawing on lessons from the Linux Kernel Community, she emphasized the importance of embedding best practices early on to ensure long-term sustainability and scalability. A key focus of her leadership has been security, which was integrated from the start rather than treated as an afterthought. With Zephyr advancing toward formal safety certification, Stewart’s vision continues to drive the project forward, solidifying its position as a trusted solution for embedded systems and safety-critical applications. Her meticulous attention to governance, security, and collaboration has been instrumental in taking Zephyr to new heights.

Software Bill of Materials (SBOM) devroom

The SBOM devroom at FOSDEM 2025 was a focal point for discussions on the growing importance of Software Bill of Materials (SBOM) in ensuring transparency and security across the open-source ecosystem. A standout session was Luigi Pellecchia’s talk on BASIL, an innovative open-source tool designed to simplify the creation and maintenance of traceability matrices for safety-critical applications. Pellecchia demonstrated how BASIL leverages the Software Package Data Exchange (SPDX) standard to integrate quality-related work items into SBOMs, enhancing consistency and reliability across complex toolchains. His presentation highlighted the critical role of SBOMs in fostering trust and compliance, making it clear that tools like BASIL are essential for modern software development workflows. The devroom’s sessions collectively underscored the value of SBOMs in building secure and sustainable software supply chains.

Embedded, Mobile, and Automotive devroom

The Embedded, Mobile, and Automotive devroom at FOSDEM 2025 was a hub of innovation, bringing together a vibrant community of developers and enthusiasts to explore the latest in open-source technologies. The program was packed with engaging talks, covering everything from CubeSat communication systems and general-purpose humanoid robotics with dora-rs to dual A/B update solutions for embedded Linux. Standout sessions included Thibault Poncelet’s deep dive into automotive communication systems with Reverse Engineering CAN Communication and Building ECUs Using Elixir and the BEAM, and Florian Limberger’s exploration of Bluetooth Low Energy applications in Developing BLE Host Applications with Zephyr. Attendees also got a closer look at the integration of MicroPython in embedded systems and enjoyed a lively update on the Zephyr RTOS during its dedicated roasting party. With a full house for nearly every session, the devroom highlighted the rapid advancements in embedded technologies and the critical role of open-source collaboration in shaping the future of the industry.

“FOSDEM is one of the most important open-source gatherings in the world, and this year was no exception,” said Walt Miner, AGL Community Manager at the Linux Foundation, devroom co-chair.  “I came to host the Embedded, Mobile, and Automotive devroom, as well as the Automotive BoF, but it’s also the best place to connect with a wide variety of experts across countless projects. What makes FOSDEM so special is its diversity—it’s not tied to a single project or technology, and every year brings new devrooms and discoveries. This year, I was excited to learn more about OpenPilot and meet some of the people using it.”

Miner continued, “In the Embedded, Mobile, and Automotive devroom, Zephyr was a recurring theme, with so many great talks that we could easily justify a dedicated Zephyr devroom next year. The devroom was a huge success—our 210-seat room was packed for every session, and we had three times more talk submissions than we could accommodate. It’s inspiring to see such enthusiasm and expertise in the community, and I’m already looking forward to next year!”

“Expect the unexpected. At FOSDEM, you have the opportunity to see new topics and trends.”

– Jan-Simon Moeller

Featured Talks you should check out:

BASIL an open source tool that supports requirements traceability with design sBOM

Zephyr: Open Source Project Best Practices Over Time

Dec 17

Safe Systems with Linux (Video)

By Ambassadors, Blog, Industry Conference, Linux Foundation

As Linux is increasingly deployed in systems with varying criticality constraints, distro providers are expected to ensure that security fixes in their offerings do not introduce regressions for customer products that have safety considerations. The key question arises:

  • How can they establish consistent linkage between code, tests, and the requirements that the code satisfies?
  • Which open source tools and specifically for Linux exist to support traceability in order to comply with standards such as ASPICE, ISO26262 or ISO21434?

This video from Open Source Summit Japan – presented by Philipp Ahmann, Sr. OSS Community Manager, Etas GmbH; and Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation – addresses critical challenges in requirements tracking, documentation, testing, and artifact sharing within the Linux kernel ecosystem. Functionality has historically been added to the kernel with requirements explained in the email justifications for adding, but not formalized as “requirements” in the kernel documentation. While tests are contributed for the code, the underlying requirement that the tests satisfies is likewise not documented in a consistent manner. This and further topics will be discussed. Additionally, the results from the “Safe Systems with Linux” micro conference at Linux plumbers will be summarized.

 

You can watch more ELISA-related talks on the Open Source Summit Japan Playlist on the ELISA Youtube Channel.

Jul 24

Safety Frontier: A Retrospective on ELISA

By Ambassadors, Blog

This is an abstract of a blog “Safety Frontier: A Retrospective on ELISA” originally published on Codethink by Paul Albertella. ELISA (Enabling Linux In Safety Applications) is an open source project that brings together functional safety practitioners, software engineers, and open source software contributors. The project aims to tackle the substantial challenge of integrating Linux into safety-critical systems, which include applications such as those found in vehicles, medical devices, and even aircraft, traditionally relying on bespoke software developed with rigorous controls.

As technologies in these areas evolve, there’s a growing inclination to utilize general-purpose and open source software. ELISA confronts the complexities of Linux, which consists of nearly 30 million lines of code, to establish methodologies that ensure its safe application. This involves creating safety arguments and conducting detailed safety cases backed by robust engineering and quality management processes.

Paul reflects on the collaborative journey of ELISA, emphasizing its community-driven approach. He discusses the difficulty in using a general-purpose OS like Linux in safety-critical environments, where each application requires specific adaptations and rigorous testing. The blog also touches on the ongoing initiatives within ELISA to outline essential Linux components for safe usage and to identify its limitations and risks.

The most recent ELISA workshop in Lund, Sweden, serves as a testament to the project’s vibrant collaboration and shared expertise, addressing the continuous challenges of integrating advanced software systems safely. Albertella’s narrative captures the essence of ELISA’s mission to not just adapt Linux for safe use but to foster a safety culture that benefits from and contributes to the open source community.

This abstract captures the essence of the themes explored in the original blog, making it an essential read for those involved in software engineering, safety standards, or open source projects interested in the intersection of open source software and functional safety. For more detailed information, you can read the original content on the Codethink blog.

Nov 21

Putting Linux into Context – Towards a reproducible example system with Linux, Zephyr & Xen 

By Ambassadors, Blog, Industry Conference

Last week, developers from around the world traveled to Richmond, Virginia for the annual Linux Plumbers Conference. Hosted at the Omni Richmond Hotel on November 13-15, the event was mostly in-person with a live-streaming element for those who couldn’t make it.

Philipp Ahmann, Product Manager for Embedded Open Source at Robert Bosch GmbH and Chair of the ELISA Project Technical Steering Committee (TSC), was at the event and gave presentation titled, “Putting Linux into Context – Towards a Reproducible Example System with Linux, Zephyr & Xen.” You can find his presentation video and PPT  below:

 

Linux Plumbers Conference – ELISA PresentationDownload

Demos on embedded systems using Linux are plentiful, but when it comes to reproducing them, things get complicated. Additionally, on decent embedded systems Linux is only one part of the system and interacts with real-time operating systems and virtualization solutions. This makes reproduction even harder.

Within the Linux Foundation’s ELISA project, we started to create a reproducible example system consisting of Linux, Xen, and Zephyr on real hardware. This is the next step after we achieved a reproducible system with a pure Linux qemu image.

The idea is to have documentation, a continuous integration including testing, which can be picked up by developers to derive and add their own software pieces. In this way they should be able to concentrate on their use case rather than spending effort in creating such a system (unless they explicitly want this). We also show how to build everything from scratch. The assumption is that only in this way it is possible to get a system understanding to replace elements towards their specific use cases.

We had challenges finding good hardware, tools, freely available GPU drivers and more and we are still not at the end. A good system SBOM is also creating additional challenges, although leveraging the Yocto build system has provided some advantages here.

While we are setting up the first hardware with documentation from source to build to deployment and testing on embedded hardware, we aim to have at least two sets of all major system elements like Linux flavor, a choice of virtualization technique, real-time OS and hardware. Only when software elements and hardware can be exchanged, we identify clear interfaces and make a system reproducible and adoptable.

Open Questions are:

  • What will be a good next hardware to extend this PoC scope?
  • Where do open source, security, safety, and compliance come best together?
  • Which alternative real-time operating systems and virtualization should be incorporated?

For more ELISA Project updates, subscribe to @ProjectElisa or our LinkedIn page or our Youtube Channel.