Linux memfd Seals: Freeze a Shared Configuration Before Passing It to a Worker

Passing a memfd to an embedded worker does not make its configuration immutable. Another process can retain a writable mapping to the same file. Even F_SEAL_FUTURE_WRITE deliberately permits writes through shared writable mappings that existed before the seal was installed.

For a worker that needs a fixed configuration snapshot, seal the required content and size properties before publication, and verify them on receipt. This guide uses Linux man-pages 6.19 for memfd_create(2) and file seals. The two-process examples are proposed designs; no descriptor transfer or sealing experiment was executed.

Define what must remain fixed

Consider a hypothetical acquisition worker that validates a configuration header, checks a table’s bounds and then repeatedly reads that table. If the producer can change the header or table afterward, the worker’s earlier validation may no longer describe the bytes it uses.

The required contract is stronger than “the receiver opened it read-only.” It must prevent other holders from altering the shared object’s relevant contents and extent. Descriptor access mode and the mutability of the underlying object are separate properties.

A fixed-size configuration snapshot usually needs protection against content writes, shrinking and growth. A checksum can detect a mismatch when recomputed, but it does not itself stop another writer from racing a later read.

Allow sealing at creation

The memfd manual documents MFD_ALLOW_SEALING. Without it, the initial seal set includes F_SEAL_SEAL, which blocks adding other seals. That initial state does not mean the file’s data have been frozen.

Create, size and populate the object under one construction owner. Check each operation and keep the descriptor unpublished until construction and the intended seals succeed. A failed sealing operation must leave the snapshot unavailable to workers, rather than silently degrading to a mutable configuration.

Do not infer identity from the memfd’s debug name. It is a label, not an authenticated configuration version or a unique file identity. Bind the handed-off object to the product’s established control-channel and version protocol.

Distinguish future-write blocking from a frozen snapshot

The seal reference distinguishes F_SEAL_WRITE from F_SEAL_FUTURE_WRITE. The latter blocks subsequent write calls and new shared writable mappings, while existing shared writable mappings can still change the contents.

In a proposed counterexample, producer A maps the file writable, sets the future-write seal and passes a descriptor to worker B. B reads a valid table. A then modifies one entry through its original mapping. B’s read-only mapping can observe changed backing data. The future-write seal is functioning as specified; the snapshot assumption was wrong.

Original counterexample and corrected publication boundary. Existing writers must be eliminated before claiming a fixed snapshot.

Adding F_SEAL_WRITE fails with EBUSY while a writable shared mapping exists. Remove those mappings through their owners before attempting the stronger seal. Do not treat closing one descriptor as equivalent to removing every mapping, and do not pass the object to uncontrolled writers during construction.

Verify a concrete seal policy

For this illustrative fixed configuration, the required mask is:

required = F_SEAL_WRITE | F_SEAL_SHRINK | F_SEAL_GROW;

After successful construction and sealing, the receiver obtains the actual set with F_GET_SEALS. Treat an error as rejection; otherwise require (actual & required) == required before relying on immutability. Validate the object’s size and application format as separate steps.

F_SEAL_SEAL can additionally prevent later changes to the seal set. It does not substitute for any missing content or size seal. Seals are shared properties of the underlying inode, cannot be removed, and affect holders of other descriptors to the same object.

This policy is intentionally a fixed-snapshot policy. A deliberately live shared data feed has different synchronization needs and should not be described as immutable merely because readers cannot create new writers.

Review publication failures explicitly

A proposed fixture should reject an object created without sealing permission, an object carrying only the seal-set lock, and one carrying only the future-write seal. It should also handle the stronger write seal failing because a construction mapping is still present.

For a valid object, record successful seal addition, the receiver’s observed required mask, validated size and configuration generation. Then keep the object’s lifetime valid for as long as the worker retains references to its bytes.

These checks establish the selected mutation restrictions. They do not authenticate the producer, prove the configuration is safe for the instrument or replace bounds checking. The useful result is a publication boundary at which the worker can rely on a stable, separately validated snapshot, instead of trusting a descriptor label or an incomplete seal name.