From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8211C4828F for ; Fri, 2 Feb 2024 15:18:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 244816B007B; Fri, 2 Feb 2024 10:18:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F5006B007D; Fri, 2 Feb 2024 10:18:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BCF16B007E; Fri, 2 Feb 2024 10:18:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EDB3E6B007B for ; Fri, 2 Feb 2024 10:18:37 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C01121C198C for ; Fri, 2 Feb 2024 15:18:37 +0000 (UTC) X-FDA: 81747220674.09.C3CEFB4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf11.hostedemail.com (Postfix) with ESMTP id B6D6940017 for ; Fri, 2 Feb 2024 15:18:35 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="JmpdB/Lv"; spf=pass (imf11.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706887115; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2JqPfMaSLWJLphgFuscgLQ69l/wBNvuXEtj3s2i+H5Y=; b=bTAv8eLAFZMAyWDxiALXzHUf150D3e3ai+du5gY1Ue3YWGFMTQGyU8zozHoWHvveNQ5p9e axsr5cFKYE9WUBKS4Can/ArQF7zDkgpTwRuweEqmRwMO8Hw7bjqpx7fFExyR3WwrHqbI8X BKay7OEv2dJBT9yHSmTMafP0c0D/IeI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="JmpdB/Lv"; spf=pass (imf11.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706887115; a=rsa-sha256; cv=none; b=Jd9itS3yUt8Pl12NaUYjdayJ6j5FtWDhzhe4XR1TeDW8GISxuI0x8P77AgMN4MZpPL+UDH kKRoJCmkmc+u/fyII9TtSvGrq99567UqZVsCmStYtxtVYqoPCqrJePQKS1trIDm/6LojsU 1cF3hhUgt8qYzS7RR8yyaO4SFZ3OPS0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 914C162649; Fri, 2 Feb 2024 15:18:34 +0000 (UTC) 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: B6D6940017 X-Rspam-User: X-Stat-Signature: qap9bgp5dwisfe6gfzn9kztuiqmdbyw5 X-Rspamd-Server: rspam01 X-HE-Tag: 1706887115-31644 X-HE-Meta: U2FsdGVkX1+BpUYWlJGtQJ81jY06xfw0Xsa7luUoRRZWHpx834C84kXeLpJ8r/3Nkrm85XCLvm31EUv3mZxiePV0WNn+BAFHJgQOCDA3jTML4fZDxY0bzZcKd6x4O5Yk95RSKLdgmAxSDk/QksY6n3ZS8b4+AVYva0rLKJNOkwbdVKUUqGZgitIhwJ2JgahWW8jGTIM9AAfyl8G0RY6MEBOkBIco7OFH0peDtjY/skGyEZ+7TDrBn68iNf+/rUMv0J8apaFNkmP743aAM+HYTg18ELpjLlnATwjWnAbKgH/wMIfIW8tOEn0eqUvc9V5S6jqh4DQXPI1Thzhd7u+m583lNWTikFlE0oriWsYWB6hMIlw2C+KnaaF60scAxzxakmaE+XQ3nZ/xZT6Jkj2iWCcwVzC2NjuccjsBgQb3vQsxFmnRSZTuvIMubcs7xIZk/JjC5ZbIHl/yG4fJDfN5C3/53lwrhAdZTW+f8jiShFZy2SMzppzJYe15EYa1QmGiwXAW1i05hK+KArD5H4vjtJtBfRDw6yGIV+wSkOfIO71lA5AUbpKDqnKxJksX6MmuaOUUvsM2Z+dfk/KZ6jVjVEJE7tFhEie/d0aP0gyz11jhyrLPGedTBOPq/4lINqJvfX6vH9P5gQhqne2TIBcUBuKblieIMLdjSd9bAD0GVj52Vxd3OXh6RgzDNsuho4WIRHiT4k8A8l6xMQCIN2EsRvOAwECul93V8ghLikg7z5oFdunJ+FkelnvDhEY7Ngvv/JL1tsR1BE8cF9aLPqUyTlb36ewj1e/VFXaAOSYezQ0geeV9GvY43gJaJluYmb4H8ZoS0XcjS6bTQDlGNAye4f/pP5DUQYlszBMG68601ymSS8IyRGSEfO9ALv5JLlC5PlwNjlUi13+6PXQKOhLsPnPPw6iXa5UxMXk+3ctszuYlhzBp9o0fbJK7wzNdUwz7pw70XbMCAmrDkPs61AR 1VhUzcM1 ov2ZvFnLMhu4nzYLKsV+TWRm6mmbxCsx7O94GUUtnrw4lSy1flE6ZkgQDkz7aw4OShwr2yV60J8AAZQNLNjJwaCJooE7XUD7oBYRoa2tIuI6vwirUcwG30AEYXE7bLlEyekk2QORjaSQjKYiNCb53JC64mo77UrRK7pGh9aXBPEz16pjgUuaHfcs3V+kbDtAbUYzFiOWFmzqn/fBVXJA10cZ20poFIgw8bxHQrtWxsN1lu8wntfNjO5hWPd+SuTzfKytTD2I1Zw19VwOdRB067q98aMYsQuSV56pBlL7ErBTFMcQBL5f7QAHgvxsv06+NR/30P7fXwijHxOo6QZMiRhMw1MXh//sg/Lv+VE/JdI/fBnwph5OPO4jsaw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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