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 B45AFC48286 for ; Thu, 1 Feb 2024 23:43:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2A946B0074; Thu, 1 Feb 2024 18:43:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CB12C6B0075; Thu, 1 Feb 2024 18:43:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B519E6B007B; Thu, 1 Feb 2024 18:43:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A19EF6B0074 for ; Thu, 1 Feb 2024 18:43:27 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 76CC4C0DFA for ; Thu, 1 Feb 2024 23:43:27 +0000 (UTC) X-FDA: 81744864054.22.C4C3EFA Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf07.hostedemail.com (Postfix) with ESMTP id 77A9C40005 for ; Thu, 1 Feb 2024 23:43:25 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=UuduZe5F; spf=pass (imf07.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706831006; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BrCqM3oK76caVW6oXU8Dk0Ve0k4o+MMeImrpFsl6swI=; b=E6OBJezaKIgv9Av0R//fJ9n65Jnh8CjdNEgn2tC2WbUQAR2LTYllcRoChAkpYc6PXaKMgV qoQPXm4liZ7TcPjYL3uV2788TcqIkCs0vMTZz6aQdYFsB/B5YEqPLVoH8FfaYbzQAuwKh1 nhCV499S45A/MLE4SflECljrbVsxx8I= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=UuduZe5F; spf=pass (imf07.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706831006; a=rsa-sha256; cv=none; b=0NBflk9pG0h0OxaYVp17y3O3FHoGEGl+19F5T/M9q4DxIJh9Eil7g1RPCPYtJDWBG8O04e 8qoAqKoQMfeBbADpkNU3kQarC3Qgcx2Xdfy6rN5TTu6N1PatA1pixgM+sMJjlcspuSZLVL g+OZJH+87WCr/Pj+EWxogRl+JeavPLE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=E/EuFP/XXc sHH/ajGIWHXjQc4oFNk7hnv3UOw4l6RiM=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=UuduZe5F+g7Sb4UNMNnMGju7lX3vLVV9T SdhKcs9Z/5wsx6/8QjyATQ+zVRTEVWJdStFfTfsrBtP22IuF2hsOYAkbttWo1zYJaeNa1H D6naShPls+8kar87xWt9d2fOkPnqBF9AQAfKZKSKOhcIkilznr1jlnH+w7fzS+LIl8dttt ICJwHJZKyMe1dWiKrFy9s+/IUyd3XP9rmMF8omt2kROOv8mAhY0AF0p+Qk7RPRU0g5NO2n ts2xcmrrw7aFcNqsRZqx/onC9hdZPIjly+rXOfiy2Tih5vNNAS5kJzBJMGFXUNwcM51f4O rg13pwCVW7Q5S/Y4H7M5PTgjN7Cxw== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id fb45d291; Thu, 1 Feb 2024 16:43:17 -0700 (MST) From: "Theo de Raadt" To: Linus Torvalds cc: Jeff Xu , "Liam R. Howlett" , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.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 In-reply-to: References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <58408.1706828083@cvs.openbsd.org> Comments: In-reply-to Linus Torvalds message dated "Thu, 01 Feb 2024 15:15:27 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25907.1706830997.1@cvs.openbsd.org> Date: Thu, 01 Feb 2024 16:43:17 -0700 Message-ID: <99920.1706830997@cvs.openbsd.org> X-Rspamd-Queue-Id: 77A9C40005 X-Rspam-User: X-Stat-Signature: bdpgzgmbubm4t635q8ufrzp9d1jxe7uy X-Rspamd-Server: rspam01 X-HE-Tag: 1706831005-643268 X-HE-Meta: U2FsdGVkX19uTAEsFL1VJM86RFpNRthSsNMdUhMvTwVXjL3oJbs636J0IEUwrAqB5Ib1T1PcahkikNm9f8dXyGfVnmHh6/ChrNItuS5wwNMFFTIADtsmiZRA5yX3sLcK0+3mJwEdT1RlUxieCT7sJnsaGrofpf1LqPpkyFc0HryNwYBAmjqI72eWgCJYmqHMEmPBWzLddTRt9rVd6FNaSy/5QDrW2WMZb1CFMV+Zfj4vFEqPN0z+aKTLFpUVvLyQynzcaUvjvmwWESstAUGO6K4x46Fv/CbmV3b1x1IhfhwpuM1cEIQ6RDBej2YldU2XWdtx0XgTKTvPqga6zh8p0boJpE+hzunjC0wLUMDrcRSYM7nYdhlSk3U3Mjy8UOkQLQR9adD/JDNPHqtAIZNBK10sEzmAkUy25s04M3oDKmECE+ZBq36KED8A8u2P/pU03B+uzCmbhrgv19xE6rKixMdpHqmA4veQ0HHLIjuzXILMtuEf+PTM2qk5fxWiwe97bW0jSPYFHoMUxzSLNOyuE2XchDVc1B/JFVioSp9lOOUTktEalVJSXX50iHKK+8jEnQegIjwFHZq4rnsM0x0UjVMxCUW3jx1gUVL3qMVqimVYLbw4TZX7KoSp5LFzpghHJHlfgbB5ZFhB0Tus7jlQLp5nn+kwS0LTeoSZwBlghVdBN4mpvQFYEVztH7ZQk/FsiA0fowFgV29Lvb2A3VPnnqo1SUTUiwuRjKSE1YIfAm1Bv1HkUK5ZT0Rz3OIznk+nj0LytKtVOV7Mdd0widy77rU2AbUz2cSchoVYae94IqS+x8Pt4Rn7jsJoWIgoP0MmLWjm7sgej49ny6cbgW5sARSJfo3JM0be8LS7jCD2w2wzmPHeSdwa5zKO/UhgL+A0tkuuiY0A7zWxXT5psTJBgw== 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: Linus Torvalds wrote: > So yes, to my mind > > mprotect(addr, len, PROT_READ); > mseal(addr, len, 0); > > should basically give identical results to > > mprotect(addr, len, PROT_READ | PROT_SEAL); > > and using PROT_SEAL at mmap() time is similarly the same obvious > notion of "map this, and then seal that mapping". I think that isn't easy to do. Let's expand it to show error checking. if (mprotect(addr, len, PROT_READ) == -1) react to the errno value if (mseal(addr, len, 0) == -1) react to the errno value and if (mprotect(addr, len, PROT_READ | PROT_SEAL) == -1) react to the errno value For current mprotect(), the errno values are mostly related to range issues with the parameters. After sealing a region, mprotect() also has the new errno EPERM. But what is the return value supposed to be from "PROT_READ | PROT_SEAL" over various sub-region types? Say I have a region 3 pages long. One page is unmapped, one page is regular, and one page is sealed. Re-arrange those 3 pages in all 6 permutations. Try them all. Does the returned errno change, based upon the order? Does it do part of the operation, or all of the operation? If the sealed page is first, the regular page is second, and the unmapped page is 3rd, does it return an error or return 0? Does it change the permission on the 3rd page? If it returns an error, has it changed any permissions? I don't think the diff follows the principle of if an error is returned --> we know nothing was changed. if success is returned --> we know all the requests were satisfied > The reason for having "mseal()" as a separate call at all from the > PROT_SEAL bit is that it does allow possible future expansion (while > PROT_SEAL is just a single bit, and it won't change semantics) but > also so that you can do whatever prep-work in stages if you want to, > and then just go "now we seal it all". How about you add basic mseal() that is maximum compatible with mimmutable(), and then we can all talk about whether PROT_SEAL makes sense once there are applications that demand it, and can prove they need it?