From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C25821872; Fri, 2 Feb 2024 15:18:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706887115; cv=none; b=OOC2+ikKcfKdkdbwzYLtr9ZW0JgjWc9C0PSw8YhjS8kKTrAKnl2sfkTz5UUo7/BMl+nYjJPC7JvOkkeCw50G38DiuZdRQcfMGNCUfgONr9fS8T2lIIiBvQIDjEZShfVmhjiZLgIgufg5wi6sCu2NJmv+8hiKIS53f8ZPZBe+Pq0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706887115; c=relaxed/simple; bh=K7NuQyBVO5NkQ+Fis32NW+0CYtstw9NntLngIcR6Dhs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fJvZqFrtCX8JPxIvzn3dFVyAKMfvBnr0kjAtBR8Qlmz9lhajXpgEkJGYWupVVMwAxNqBP8VYnT0pdvj6CqBENXXyFOOskqDSDDYMVp0yl8ZtE0zYDkwTtyZ0nqOy17sxuELS+3r5aask4t7qMxAbmit/Sxbic5gGi6oZKSRDyAo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=JmpdB/Lv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="JmpdB/Lv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28D5FC433C7; Fri, 2 Feb 2024 15:18:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1706887114; bh=K7NuQyBVO5NkQ+Fis32NW+0CYtstw9NntLngIcR6Dhs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JmpdB/LvHCipua99PImkpjtbcuHksJQW1JRmGtW67QSvsYaOZ8z/seR80R1i7s6VA Qj4ib79qMpbGVgThxF+lzjBH/VWndw55Z5C+dg2nxUG745u7TAvhstd2+ZsNjwZOPZ Uo3s7T7sJwKtBpXJz4H4oW0Qir/mMFk9X+3fuSaE= Date: Fri, 2 Feb 2024 07:18:33 -0800 From: Greg KH To: Jeff Xu Cc: "Liam R. Howlett" , Jonathan Corbet , 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> <20240201204512.ht3e33yj77kkxi4q@revolver> <60731.1706826280@cvs.openbsd.org> <2024020137-hacking-tightwad-a485@gregkh> Precedence: bulk X-Mailing-List: linux-hardening@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Feb 01, 2024 at 07:24:02PM -0800, Jeff Xu wrote: > On Thu, Feb 1, 2024 at 5:06 PM Greg KH 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