On Thu, Feb 01, 2024 at 07:24:02PM -0800, Jeff Xu wrote: > On Thu, Feb 1, 2024 at 5:06 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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. There's no rush here, and no deadlines in kernel development. If you don't have a working userspace user for your new feature(s), there is no way we can accept the changes to the kernel (and hint, you don't want us to either...) good luck! greg k-h
