On 2025-08-27, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > On Wed, Aug 27, 2025 at 5:14 PM Aleksa Sarai <cyphar@xxxxxxxxxx> wrote: > > > > On 2025-08-26, Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > > On Tue, Aug 26, 2025 at 11:07:03AM +0200, Christian Brauner wrote: > > > > Nothing has changed in that regard and I'm not interested in stuffing > > > > the VFS APIs full of special-purpose behavior to work around the fact > > > > that this is work that needs to be done in userspace. Change the apps, > > > > stop pushing more and more cruft into the VFS that has no business > > > > there. > > > > > > It would be interesting to know how to patch user space to get the same > > > guarantees... Do you think I would propose a kernel patch otherwise? > > > > You could mmap the script file with MAP_PRIVATE. This is the *actual* > > protection the kernel uses against overwriting binaries (yes, ETXTBSY is > > nice but IIRC there are ways to get around it anyway). > > Wait, really? MAP_PRIVATE prevents writes to the mapping from > affecting the file, but I don't think that writes to the file will > break the MAP_PRIVATE CoW if it's not already broken. Oh I guess you're right -- that's news to me. And from mmap(2): > MAP_PRIVATE > [...] It is unspecified whether changes made to the file after the > mmap() call are visible in the mapped region. But then what is the protection mechanism (in the absence of -ETXTBSY) that stops you from overwriting the live text of a binary by just writing to it? I would need to go trawling through my old scripts to find the reproducer that let you get around -ETXTBSY (I think it involved executable memfds) but I distinctly remember that even if you overwrote the binary you would not see the live process's mapped mm change value. (Ditto for the few kernels when we removed -ETXTBSY.) I found this surprising, but assumed that it was because of MAP_PRIVATE. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Attachment:
signature.asc
Description: PGP signature
