Received-SPF: pass (google.com: domain of linux-kernel+bounces-50006-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 2 Feb 2024 07:18:33 -0800
From: Greg KH <gregkh@linuxfoundation.org>
To: Jeff Xu <jeffxu@chromium.org>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Jonathan Corbet <corbet@lwn.net>, akpm@linux-foundation.org,
	keescook@chromium.org, jannh@google.com, sroettger@google.com,
	willy@infradead.org, torvalds@linux-foundation.org,
	usama.anjum@collabora.com, rdunlap@infradead.org, jeffxu@google.com,
	jorgelo@chromium.org, groeck@chromium.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v8 0/4] Introduce mseal
Message-ID: <2024020227-suing-ooze-d555@gregkh>
References: <20240131175027.3287009-1-jeffxu@chromium.org>
 <20240131193411.opisg5yoyxkwoyil@revolver>
 <CABi2SkXOX4SRMs0y8FYccoj+XrEiPCJk2seqT+sgO7Na7NWwLg@mail.gmail.com>
 <20240201204512.ht3e33yj77kkxi4q@revolver>
 <60731.1706826280@cvs.openbsd.org>
 <2024020137-hacking-tightwad-a485@gregkh>
 <CABi2SkVb1goM95FT5v2K18NHbaLitLpK6fL+wE6Y47z8yvW0Nw@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABi2SkVb1goM95FT5v2K18NHbaLitLpK6fL+wE6Y47z8yvW0Nw@mail.gmail.com>

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@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.

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