On Thu, Feb 1, 2024 at 5:06 PM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Feb 01, 2024 at 03:24:40PM -0700, Theo de Raadt wrote:
As an outsider, Linux development is really strange:
Two sub-features are being pushed very hard, and the primary developer doesn't have code which uses either of them. And once it goes in, it cannot be changed.
It's very different from my world, where the absolutely minimal interface was written to apply to a whole operating system plus 10,000+ applications, and then took months of testing before it was approved for inclusion. And if it was subtly wrong, we would be able to change it.
No, it's this "feature" submission that is strange to think that we don't need that. We do need, and will require, an actual working userspace something to use it, otherwise as you say, there's no way to actually know if it works properly or not and we can't change it once we accept it.
So along those lines, Jeff, do you have a pointer to the Chrome patches, or glibc patches, that use this new interface that proves that it actually works? Those would be great to see to at least verify it's been tested in a real-world situation and actually works for your use case.
The MAP_SEALABLE is raised because of other concerns not related to libc.
The patch Stephan developed was based on V1 of the patch, IIRC, which is really ancient, and it is not based on MAP_SEALABLE, which is a more recent development entirely from me.
I don't see unresolvable problems with glibc though, E.g. For the elf case (binfmt_elf.c), there are two places I need to add MAP_SEALABLE, then the memory to user space is marked with sealable. There might be cases where glibc needs to add MAP_SEALABLE it uses mmap(FIXED) to split the memory.
If the decision of MAP_SELABLE depends on the glibc case being able to use it, we can develop such a patch, but it will take a while, say a few weeks to months, due to vacation, work load, etc.
Best Regards, -Jeff
thanks,
greg k-h