Rust SIG Meeting - 2026-06-09 #29

PLeVasseur · 2026-06-09T14:01:25Z

PLeVasseur
Jun 9, 2026
Collaborator

Hey folks 👋 welcome to our 11th meeting of 2026.

Rust SIG Meeting 2026-06-09

Agenda

Solicitation of notetaker
- Pete LeVasseur
Rust Watercooler Chat Topic: Shared Memory, in Rust, the Memory-Safe Language!? Yes: iceoryx2; Christian Eltzschig, ekxide
Review GitHub repo content and discuss how to enrich it (Pete)
1. Issues
2. Discussions are now active. The SIG previously agreed to take meeting notes there.
Office hours: Rust + Automotive questions — come chat (All)
Discuss upcoming events / news related to Rust & Automotive (All)
Meeting close

Check-in area

We had roughly 15 people present at peak attendance, including those listed below.

Housekeeping

Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
GitHub repo: https://github.com/rust-sig/rust-sig
Eclipse SDV Slack channel: #rust-sig

Tasks / action items

No explicit action items were captured in the source notes.

Meeting Minutes

Shared Memory, in Rust, the Memory-Safe Language!? Yes: iceoryx2; Christian Eltzschig - ekxide

Slides: ekxide_where-rust's-safety-guarantees-stop_shared-memory-concurrency-and-unsafe-boundaries.pdf

Key takeaways

iceoryx2 uses shared memory for true zero-copy inter-process communication: the sender writes directly into shared memory, the receiver reads directly from it, and iceoryx provides the surrounding communication infrastructure.
Rust’s ownership, borrowing, Send / Sync, and tooling improve confidence, but they do not automatically make shared-memory IPC safe.
The central warning of the talk was that “written in Rust” is not a sufficient safety argument.
Unsafe boundaries need design review, tooling, documentation, tests, and ideally reusable audited abstractions.
Miri, Loom, and Kani can increase evidence for safety, but none of them automatically prove that the protocol invariant itself is correct.

Background: iceoryx2

The slide deck introduced iceoryx2 as:

an open-source project hosted by the Eclipse Foundation;
an inter-process communication (IPC) system based on shared memory;
a project kicked off in 2015 that influenced AUTOSAR Adaptive ara::com and ROS 2 APIs;
open source since 2019, with the second generation, iceoryx2, started in 2023;
based on 70+ years of combined experience in high-performance IPC. (Slides p. 3)

The live notes also captured that the original iceoryx work started in the Bosch ecosystem, and that the later rewrite moved to Rust for the reasons discussed below.

How iceoryx2 works

At the simplest level, two or more processes map and access the same shared-memory region.

The sender writes directly into shared memory.
The receiver reads directly from shared memory.
iceoryx provides the surrounding communication infrastructure.
iceoryx handles discovery, message delivery, and memory management.
This is what the slides call true zero-copy communication. (Slides p. 4)

The slide diagram shows Process A / Sender -> Shared Memory <- Process B / Receiver: the shared-memory region is the handoff point, not a copied message buffer owned by a broker.

Why Rust was chosen

iceoryx2 targets safety-critical and high-reliability systems, so reliability and correctness are not optional engineering goals. The slides cited two memory-safety motivations:

Microsoft reports that roughly 70% of CVEs assigned by MSRC are memory-safety issues.
Chromium reports that around 70% of high-severity security bugs are memory-unsafety problems.

The speaker’s framing was not “Why Rust?” but rather: “Why would we stay with C++?” Rust removes large classes of memory-safety and data-race bugs in safe code, whereas C++ leaves developers with the full burden of preventing those classes manually. (Slides p. 5)

Rust safety guarantees: ownership and borrowing

Rust’s ownership model provides a strong baseline:

Every value has a single owner.
Borrowing permits either:
- one mutable reference, or
- any number of immutable references.

Illustrative example from the slides:

let mut v = vec![1, 2, 3, 4, 5];
let first = &v[0];
v.push(6); // violation

The point of the example is that Rust can prevent mutation that could invalidate an outstanding reference. (Slides p. 7)

Rust safety guarantees: `Send` and `Sync`

The speaker emphasized that having formal names for these concepts is already valuable.

Send: ownership of a value can be transferred to another thread.
Sync: a shared reference can be sent to another thread; in practice, this means shared concurrent access by reference is permitted.
C++ has no formal equivalent; the closest common term is “thread-safe.” (Slides p. 8)

Problematic C++ example discussed in the talk, cleaned up for syntax:

auto sample = subscriber.receive();

auto thread = std::thread([sample = std::move(sample)](){
    std::cout << "received " << sample.payload();
});

The slide notes that an iceoryx2 Sample is not Send or Sync. The Rust type system can express that a sample should not be moved to another thread or shared across threads when doing so would violate the protocol. In C++, the API has to rely much more heavily on convention and review. (Slides p. 9)

Rust safety guarantees: tooling like Miri and Loom

The slide deck framed Miri and Loom as important evidence-generating tools, not proof that everything is correct.

Miri helps find undefined behavior in executed unsafe code paths.
Loom explores possible concurrent executions and memory orderings.
Both are powerful, but neither proves that the protocol invariant is correct.

The talk’s answer to “Can we now write lock-free low-level code without fear?” was: No — but with better evidence. (Slides p. 10)

The Seqlock Case Study

Introduction

The seqlock case study focused on a shared-memory data structure with:

one writer;
many readers;
storage in shared memory.

The tempting safety-critical argument is that a crashing writer or reader cannot block another process. The slide immediately questioned that assumption: “or can it?” (Slides p. 12)

The diagrams on slides p. 12–13 show two cells: one write cell and one read cell. The writer copies data into the write cell, readers copy out of the read cell, and the sequence counter determines which cell is currently used for reading versus writing.

Naive implementation

The slide’s simplified shape of the structure was:

struct SequenceLock<T: Send + Copy> {
    sequence_counter: AtomicU64,
    cells: [UnsafeCell<MaybeUninit<T>>; 2],
}

The sequence counter defines the read and write cell.

Writer flow:

Read the sequence counter.
Write data.
Increment the sequence counter.

Reader flow:

Read the sequence counter.
Copy data.
Read the sequence counter again.
If the counter changed, retry from step 1. (Slides p. 14)

Rust implementation sketch

The slides showed an implementation shape along these lines:

fn write(&self, value: T) {
    let current = self.sequence_counter.load(Ordering::Relaxed);
    let write_cell = unsafe { &mut *self.cells[current % 2].get() };

    unsafe {
        copy_non_overlapping(&value, write_cell.as_mut_ptr(), 1);
    }

    self.sequence_counter.fetch_add(1, Ordering::Release);
}

fn read(&self) -> T {
    loop {
        let current = self.sequence_counter.load(Ordering::Acquire);
        let read_cell = unsafe { &mut *self.cells[(current + 1) % 2].get() };
        let mut value = MaybeUninit::uninit();

        unsafe {
            copy_non_overlapping(read_cell.as_ptr(), value.as_mut_ptr(), 1);
        }

        if current == self.sequence_counter.load(Ordering::SeqCst) {
            return unsafe { value.assume_init() };
        }
    }
}

This sketch is useful because it looks plausible, but the rest of the talk examined where the model cracks. (Slides p. 15–16)

Where the model cracks

The speaker asked three review questions before walking through the failure modes:

Would you have spotted the issue?
Do you have tooling in place to avoid it?
Would you know how to test it? (Slides p. 18)

Data races and undefined behavior

The naive implementation uses copy_non_overlapping on both the writer and reader side. Miri detects undefined behavior in this setup.

The key issue is that concurrent reading and writing with copy_non_overlapping is undefined behavior even when the data race is detected and the copied data is never touched. In a safety-critical system, this is not an acceptable implementation detail to wave away.

The slide’s proposed direction was to use atomic bytes for the payload representation:

[AtomicU8; core::mem::size_of::<T>()]

This avoids the plain non-atomic concurrent copy, but it leads into the next problem. (Slides p. 19–20)

Padding and undefined behavior

The slides used a repr(C) example:

#[repr(C)]
struct Data {
    data_1: u8,
    // 7 padding bytes in here
    data_2: u64,
}

Reading padding bytes is undefined behavior. Switching from copy_non_overlapping to an atomic byte-wise copy still does not automatically solve the issue, because byte-wise copying can read padding bytes. Miri still detects undefined behavior.

The proposed solution was a proc macro plus derive that generates a member-wise accessor for byte-wise copy, avoiding padding bytes rather than treating the entire object representation as uniformly valid data. (Slides p. 21–22)

Pointer provenance

The talk then moved to pointer provenance. Thin pointers in Rust and C++ have two conceptual components:

Address: where the data is in memory.
Provenance: where and when the pointer is allowed to access memory.

Undefined behavior depends on both the address and the provenance. A pointer can point to the right numeric address and still be invalid for the intended access if its provenance is wrong. (Slides p. 23)

This becomes especially tricky in shared memory:

For the other process, the object appears “out of thin air.”
Shared memory contains bytes, not automatically Rust values.
A cast such as the following is not obviously a complete safety argument:

let base = shm_base_ptr.add(offset) as *const SeqLock;

The slides explicitly asked: “Is this correct?” The live discussion noted that similar “conjuring” is often necessary when interacting with hardware, writing drivers, or writing operating-system code. The safety argument therefore has to be explicit at the boundary where raw bytes become typed Rust values. (Slides p. 24)

Acquire-release memory ordering

Acquire-release ordering is used to establish a happens-before relationship:

On the writer side, the write to the payload must happen before the sequence counter announces that the write is complete.
On the reader side, loading the sequence counter with acquire semantics must happen before reading the payload.

When a reader observes the value that the writer placed in the sequence_counter, it should also observe the changes in the corresponding write cell. (Slides p. 25)

A view into the past

Acquire-release can still allow a reader to observe a consistent value from the past. The slide gave the scenario:

T = A, seq_count = 1
T = B, seq_count = 2
T = C, seq_count = 3

The question is: what value does T have for a particular reader? Acquire-release can provide consistency, but not necessarily “the newest” value. If the algorithm requires the newest data, it needs additional synchronization outside the basic acquire-release relationship.

The speaker connected this issue to a lock-free flatmap implementation. The captured note was: if a key is visible, do not update; otherwise add the key and value. The solution discussed was a generation counter that changes on every read and write, forcing both sides to synchronize to fresher values. (Slides p. 26)

As-if rule

The live notes captured a related compiler-optimization concern: the compiler is allowed to reorder statements when a single-threaded execution cannot observe the difference. For example, setting A = 5 and B = 6 may be reordered if the single-threaded result is unchanged.

In concurrent code, that freedom can break the intended protocol unless the program uses the right atomic operations and memory orderings. The captured solution was to use atomic acquire-release semantics to constrain the relevant reordering.

What tools can and cannot prove

Miri

Miri is excellent for checking unsafe code for many forms of undefined behavior, but it only checks paths that are executed.

Practical implications from the notes:

Hard-to-exercise paths remain problematic.
Lock-free algorithms can have high-stress interleavings that are hard to reach with normal tests.
Miri does not prove protocol correctness; for example, it does not know the intended semantics of the flatmap. (Slides p. 29)

Loom

Loom systematically tests possible thread interleavings and helps validate memory orderings. The live notes added that Loom can help establish where happens-before relationships are correctly formed, or point out where they are wrong.

Limits:

Loom does not know whether the algorithm’s invariant is sufficient.
It cannot determine, by itself, whether a flatmap invariant such as “there must not be more than one key with this content” is the correct or sufficient safety property.
The notes captured an idea of using “old” syscalls to build a testing framework around concurrent thread interactions. (Slides p. 30)

Beyond testing: verification with Kani?

The slides described Kani as a tool that can check assertions, contracts, panics, overflows, and many undefined-behavior cases. It may be one route for verifying lock-free algorithms, but only against the model and properties supplied to it.

The important slide completion for the original notes’ placeholder is:

The hard part remains: defining the right safety invariant. (Slides p. 31)

Conclusion

The talk concluded with three major points:

Rust is a major improvement for critical systems, and tools like Miri, Kani, and Loom increase confidence in code.
But “written in Rust” is not a sufficient safety argument.
Unsafe boundaries need design reviews, tools, documentation, tests, and ideally reusable audited abstractions.

The concluding open question was whether Rust could have an edition or mode for safety-critical deployments with less undefined behavior, even if that costs performance. (Slides p. 33)

The discussion after the slides noted that explicit annotations could be one route, but they are difficult because the developer must already be aware of the relevant undefined-behavior risk. Miri helps, but it is not perfect.

Q&A notes

Question: How is in-place construction handled? Rust lacks placement new at the moment.

iceoryx2 created its own PlacementDefault trait.
The speaker described a problem with users wanting to send very large payloads, such as 100 MB.
In release builds, some work may be optimized away, but in debug builds the same pattern can lead to stack-overflow behavior.
One issue is that the type has to implement at least Default to avoid ambiguity.
The speaker suggested looking at the iox2 implementation for details.

Question: Could there be a safer Rust mode or edition that costs performance? Since shared memory is used for performance, are there alternatives?

The speaker said they had considered alternatives, but did not see a better option for the target use cases.
A simplified automotive benchmark was described:
- 6 cameras;
- 20 subscribers;
- 30 MB uncompressed image per message.
With ordinary message passing, the system can end up moving more memory than is available in practice, with the notes capturing a figure over 20 GB/s.
Customers see systems break down when the total copied memory bandwidth becomes too large; zero-copy shared memory avoids that class of bottleneck.
More powerful hardware can sometimes help, but for high-volume sensor data the architecture still has to avoid unnecessary copies.

Question: How was the decision made to take iceoryx2 down the Rust route? Were there objections that did not materialize? Any choices you would make differently?

Christian’s initial motivation was curiosity about Rust.
The approach was to write something he already knew well in a new language.
The team had already begun fixing architectural issues in classic iceoryx, including many memory bugs.
iceoryx2 had bugs at the outset too, but they were a different class of bugs.
The speaker described faster development and fewer bug reports as positive outcomes.
Things missed from C++ included generics-related capabilities and specialization.
- One example was doing generics over SeqLock for a constant memory size.
- Specialization remains a gap.
Rust is closing gaps over time, though the speaker would like that progress to be faster.
Rust was described as easy to prototype in, including the use of todo!() to progressively build out functionality.

Question: How did customers react to the prospect of certifying Rust?

The team had previously tried to safety-certify classic iceoryx.
Customers realized there was no straightforward solution for some parts of the C++ approach.
One issue was how to safety-certify generic templates.
The team spent about half a year working with an assessor on the problem.
For Rust, questions around measuring MC/DC came up.
Stronger arguments from avionics were mentioned, such as coverage of test statements at the binary level.
To customers, this is not necessarily presented as “a Rust library”; they may use it from C, C++, or Python.

Question: How have these topics been addressed in the C/C++ implementation? Isn’t the shared-memory problem more about leaving the language model and entering hardware/OS specifics?

The speaker agreed that this is true at a high level.
However, Rust’s unsafe boundaries plus tools such as Miri and Loom provide more evidence and more structure than the C/C++ baseline.
At a certain point, shared memory crosses into the hardware/OS world.
The speaker said they have not yet exhausted what may be solvable with the Rust ecosystem.

Follow-up: Do you assume the peer follows the protocol? What if the other process goes wild or is implemented incorrectly?

The answer was summarized in three categories:

A rogue process opens shared memory and participates in communication when it should not.
- Use POSIX permissions to prevent this.
A process corrupts memory.
- If a subscriber detects corruption, disconnect it and inform the watchdog.
- Apply the same principle for publishers.
Publisher and subscriber access the same memory at the same time.
- This is the “modify after delivery” problem.
- Track memory regions and adjust page tables so the publisher has write access only to the relevant region, while the subscriber has read access. A process crash is the safer outcome than silent corruption.

This allows iceoryx2 to be used in a trust model where the OS is the trusted base.

Follow-up: For synchronization data, don’t you need to ensure the protocol succeeds no matter what?

The speaker said that if a client fails to synchronize correctly, it trips the kernel protocol check and the process crashes.
Safety-critical extensions are part of the open-core model and can be bought/licensed as needed for safety-critical deployments.

Question: Binary-level coverage analysis as a substitute for MC/DC — how is that argument made?

The source note mentions “DO-148C”; this should be verified before publication because the exact standard reference was not confirmed in the slides.
The speaker said both Florian Gilcher of Ferrous Systems and ekxide have used this argument.
The speaker did not have the detailed argument available in the moment.

Question: What about external crates? If you use them, how do you certify them?

The speaker said this shows the strength of the way of working.
The dependency set is kept to a minimum: libc, serde, and maybe one more crate.
Two approaches were described:
1. Create a minimal implementation of the crate with the same or adjusted API surface, forked internally.
2. Preferably, open a channel to upstream projects such as libc.
  - There is a lot of work involved, but the community benefits if funding and certification processes can support shared dependencies.
  - An ASIL D-capable serde or libc implementation would benefit many projects.
Future work: find large corporate sponsors.