Re: [PATCH 2/2] mm/memfd: handle GUP references reliably when write-sealing

[David Hildenbrand (Arm)]

On 11/6/26 20:46, David Rheinsberg wrote:
> Hi David

Hi!

> 
> On Tue, Nov 3, 2026, at 7:31 PM, David Hildenbrand (Arm) wrote:
>> We made a big mistake when introducing write-sealing: we should have
>> disallowed *any* file mappings while we are write-sealing. Write-sealing is
>> usually done by a producer that wants to hand-off some data to a consumer.
>> Having the producer have a read-only mapping (private or read-only shared)
>> of the memfd while sealing is rather odd: it couldn't have been used to
>> fill the memfd in the first place.
>>
>> Most identified public users don't do anything like that: they either never
>> map the memfd before write-sealing (using write() instead), or munmap()
>> before write-sealing:
>>
>>  - systemd's journal writes, fwupd, Flatpak, runc, crun and
>>    containers/storage write to the memfd without mmap'ing it, before
>>    sealing it [1,2,3,4,5,6]. The FD consumer will not access the memfd
>>    before sealing.
>>
>>  - dbus-broker, Mutter, Chromium's Android linker, KWin, Weston and glycin
>>    map the memfd file, but unmap it before sealing [7,8,9,10,11,12].
>>    glycin retries sealing while waiting for the loader to unmap.
>>
>>  - go-memfd exposes a shared writable mapping before F_SEAL_WRITE and a
>>    private read-only mapping afterwards. Its API explicitly requires
>>    unmapping the writable mapping before sealing [13].
> 
> When I wrote memfd-sealing, we had this use-case where an application writes a buffer and then shares it both with in-process and out-of-process tasks. Only if out-of-process tasks are actually involved, the buffer is sealed. Otherwise, it is kept unsealed and can be recycled. Hand-off to other processes was optional, rare and asynchronous, so sealing could happen at any time. Yet, we wanted to keep the buffers mapped to avoid costly TLB flushes. Mappings were readonly, but writes were done through syscalls.
> 
> We still do this, but I don't think any of the open-source users picked this up.

Ok. So internally you would have to accept the additional insecurity and enable
the kernel workaround through the parameter. How much of a problem would such a
workaround be in your fleet once you upgrade the kernel?

Not nice, but there is simply not proper way to fix this mess right now in a
better way.

> I did not follow the folio changes, so I am quite unsure whether the implementation was racy from the beginning, or whether new infrastructure introduced the races.
> 
> Can you elaborate why folio ref-counts are unreliable / unstable?

I'll have to point you at the doc of folio_expected_ref_count() where this is
properly documented.

Back when you used page_count() vs. page_mapcount() you probably had no idea
that this is completely racy as we didn't have any such helper to spell it out.

-- 
Cheers,

David