Naming things - mimmutable vs mseal

Posted Jan 20, 2024 8:12 UTC (Sat) by fredrik (subscriber, #232)
Parent article: mseal() gets closer

Naming things is hard, but I'm curious how it works in this case, and wonder if someone can shed some light on it?

AFAIU the mseal API has now evolved to become semantically very similar to mimutable in OpenBSD, right? Especially if OpenBSD were to remove the ability to reduce the permissions on a sealed region, and we ignore the currently unused flags argument for mseal.

So, assuming they are semantically the same at this point, is there any advantage to change the name of mseal to mimmutable now?

AFAIU, once a new user space API is committed to mainline and released, the name and semantics are more or less set in stone due to Linus' pledge to kernel API stability, right? I.e renaming it is only possible before it goes in.

Which leaves my question, does it make sense to do so from some point of view, say technically or to indicate to users that they do the same thing?

I can imagine that one argument against adopting the OpenBSD name would be that if the semantics of the API in Linux were to diverge from OpenBSD at some point in the future, retaining the original name from OpenBSD would muddle the water at that point. OTOH, userspace API:s are expected to semantically stable too, so perhaps that isn't possible anyway.

What other pros and cons are there to having the same or different names, assuming the API is semantically equal?

Now, it may very well be that the authors of mseal think that their name simply is a better choice to convey its purpose. And I assume that no libc standards committee was involved in picking the name mimmutable for OpenBSD. Basically the only reason mimmutable would have precedence over mseal is that OpenBSD picked that name before any implementation appeared in the Linux kernel.

PS. I really do not intend to start a heated bikeshedding debate with these questions. So if anyone else feel an irresistible urge to do so, please raise another thread for that. Thanks! And do consider that the editors of LWN probably would be very happy if you abstained entirely. :)

to post comments

Naming things - mimmutable vs mseal

Posted Jan 20, 2024 15:58 UTC (Sat) by Karellen (subscriber, #67644) [Link] (1 responses)

Is it worth considering that whatever libc API is used to wrap the syscall, does not necessarily need to use the same name as the syscall? Or, libc could present multiple wrappers for the same syscall - including adding a BSD-like mimmutable() that calls mseal() under the hood? (e.g. AIUI glibc open() actually calls openat(2) on Linux these days, ignoring Linux's native open(2) syscall altogether.)

Of course, glibc devs may be opposed to this for any number of perfectly valid reasons, but that doesn't mean the option isn't there. Or, if not glibc, then another libc might want to.

Naming things - mimmutable vs mseal

Posted Jan 20, 2024 20:03 UTC (Sat) by dezgeg (guest, #92243) [Link]

setuid() is one good example where the Linux syscall has different semantics than the libc setuid(). The syscall version only applies to the current thread which is not POSIX compatible. It's then libc which does setuid() for each thread of the process to match POSIX.