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 4B1F4C47258 for ; Fri, 2 Feb 2024 04:10:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB8486B007B; Thu, 1 Feb 2024 23:10:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C66DC6B007D; Thu, 1 Feb 2024 23:10:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B55426B007E; Thu, 1 Feb 2024 23:10:41 -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 A3BEF6B007B for ; Thu, 1 Feb 2024 23:10:41 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 77596120420 for ; Fri, 2 Feb 2024 04:10:41 +0000 (UTC) X-FDA: 81745537482.17.9061954 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf19.hostedemail.com (Postfix) with ESMTP id B57341A0003 for ; Fri, 2 Feb 2024 04:10:39 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=4e7qlbpO; spf=pass (imf19.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=1706847039; 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=kSITbD8ozIyc1Nqfx+llGwFD42gv8fxNsyi2mLV7JnY=; b=bFYglo1MmjMaT+UTUPFb8B5zMY2UzQgThPuo5GiSxLjbVMdjz+h0G1Vrj62+VcgFn6h5Bx 2E9BkNlpBLvVke/d9OuNVqmUwM1FPylDBYTRDf8TMC+3Q6cbgr/0j+iTeW7HiOfci+BQKQ lWN381LylTDr/Glibd1kvVTP9ZlIGV0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=4e7qlbpO; spf=pass (imf19.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=1706847039; a=rsa-sha256; cv=none; b=pUgWwzrDxCjTbPNmmKikQZX6TsEBiFgcTGzauaA1JuUZynBv0o/Vk3gaCLi9Fwn7eZUoUS vbzb9T8QSVqKMfG9LqtV95OtsOe2/+0Mlx8kW8WeQBMzSboXuIW1qsqMRSozcAaf6JKgda EBGkmbVMr9gTNBsgeKIeodjFeA8kROc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=t8TOoWGr0m cyEMEUUA9Zr9vcjWer6I2JFmiElhVMlm4=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=4e7qlbpOvso68la6pAFV9vdLZCsRaFhZd H6mFWFXZCl7o3iu6kzblO8V+HFKqFVZxUjCMBXuu8IwswO5pGQ5/Ri44vGpmfdAWncYdVM JXnBwNuYWJK+Ar5ZehqDJW7bhv+874OLtBw9DGHw26DVmjeJXXCBVLJOGXR/2/oqj6dsZ1 m/mz/1+KQtRFnhMAiB37fr2a5CbRrUZcGJ2s7WYLKZvpVW3SySmXWgJ4Xib1V200/ClE/x d349ddfnnu981rqmjLUW1/SU91pCMN80x3pvsbRqcraJTh3dC0ma2JsuIVyKy8ZZ4SLarl kRi70QVJo0Zygt0A3hP2aE44CMnlA== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 6f32be00; Thu, 1 Feb 2024 21:10:38 -0700 (MST) From: "Theo de Raadt" To: Jeff Xu cc: Eric Biggers , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.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 2/4] mseal: add mseal syscall In-reply-to: References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131175027.3287009-3-jeffxu@chromium.org> <20240201231151.GA41472@sol.localdomain> <96087.1706846050@cvs.openbsd.org> Comments: In-reply-to Jeff Xu message dated "Thu, 01 Feb 2024 20:03:45 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 01 Feb 2024 21:10:38 -0700 Message-ID: <72434.1706847038@cvs.openbsd.org> X-Rspamd-Queue-Id: B57341A0003 X-Rspam-User: X-Stat-Signature: phashgzidio93tsbtnk7shjgdz6uaw9i X-Rspamd-Server: rspam01 X-HE-Tag: 1706847039-806304 X-HE-Meta: U2FsdGVkX1/KTPlT3Cpt1g4VjZz8+rx38SLtQINaig5V86ZkIPrjviDM1/ZlEhGorcLp25QS5OY7GF5RGzRB9htj5NaCO9oiaiz8/PRsgzdSiE1B2Sd26SEKIJ/U3tO7hWsVj6i3RmKrwewarxSXVnIrAhI0hA0qxBj0BZ5Nyz2gSMBx6Oal+Mn63Pa4CHRgM5zTp4YMT0gXza70mmYd11/s7ohGRflnnjmyYPHuo7vvaaXF94jyaG9ykrpZ1IU5p0LMpTYMa/otL6eoO40NDrwO93HUQo6Am6/QMe9VVAco76RuVtfrh3155xwq83WfCqvhR8ZQupIX5jxl9TyT8oFqPw1K0JKBfI/hSiEjwBGG3ngUXJQsAh9IKdFT4MrW42ZWkvl1HqI7Slikp9S8tlfSwoYA+T60HclIq1euegL/r0ZGjgrnbpUhgiw+45CKxBkRDEHQgQIFojOvkbCIaXAqYDv9ifcr4FA0DTqgjEI5bo90anHYgXGXIB7jjFL3d/nVcJP8ExPIhRnKqfti7doTmGYlhdLH7Fp2226KROMSiW97A8RVXIdjeAB/dLyRHaZnJGgzGxA/ex1ZIz6OlQNvVr0epkOXjaPeFRlfDuufMeKYpvYQNJfWviN74kYUC6BwnEdzV5RdvkhQmNvArzvB4vB5e+AX0M1HV9wKh1CG78gVryAZML8JWoe9GglyDBORAbe1wc+UsEiBP/cP3Zs3Kn+KcYvAmtzt9DoekCMO4CfFgUIdSbTDq66H/++UomTv0B5lLMLnRYfzQcEjW44eBB3pia3VOJaHOcyExjxUXhdsQO4HP4uyS48kognbA8sd6RDBF5bf44btq/DpKUUNQA20Tun2M+KwHnOvaiQOPfsB9Pjlrg2JJe6AYdszYujuJKWuTTB+HvJj/tEogXN5mD4jSEiUVcMytaIkM3RpCsq/fdKxCrwSE+dVOSplE6Oc6XWXhmmLTNWK6fo uKFpSi5M q1HGOr1sdS4n6Wrdlk/EbUhYOHMKTYmY+Nz/Xqr91Chw/F4yaPBNOyou6LSk6CyzLsf8rxjNhgCDAAORqIPwMw24JRbxu5UCPLlM/hIHrHUzEpVTajjGhjA7b+Ten/7rBXSXhsWgan8ffFP8FpnGdYs1XDbmHmPnmaRxmV4/JSwRf8QM/tczzdmFUewfkqpU0s8WMAMK4N5ttr6UTb3Ut7ApzUshQCWaI+YmQhMcDdlbt6WJtBQCIf8b79v0AwWqVzywS8KTR8sn8o1RDEu8WDtsl5ElAVygJg/s0jT44K17I38thF4g8iLsMJYaI/QNRv6kiH6qwMGzybZVVOs1vkssxw9A2lch8aJ8eqv8F/4ZGYL10Tkf+wmNHJr5tY/8z5+Kj 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: Jeff Xu wrote: > On Thu, Feb 1, 2024 at 7:54=E2=80=AFPM Theo de Raadt wrote: > > > > Jeff Xu wrote: > > > > > On Thu, Feb 1, 2024 at 3:11=E2=80=AFPM Eric Biggers wrote: > > > > > > > > On Wed, Jan 31, 2024 at 05:50:24PM +0000, jeffxu@chromium.org wrote: > > > > > [PATCH v8 2/4] mseal: add mseal syscall > > > > [...] > > > > > +/* > > > > > + * The PROT_SEAL defines memory sealing in the prot argument of = mmap(). > > > > > + */ > > > > > +#define PROT_SEAL 0x04000000 /* _BITUL(26) */ > > > > > + > > > > > /* 0x01 - 0x03 are defined in linux/mman.h */ > > > > > #define MAP_TYPE 0x0f /* Mask for type of mapping= */ > > > > > #define MAP_FIXED 0x10 /* Interpret addr exactly */ > > > > > @@ -33,6 +38,9 @@ > > > > > #define MAP_UNINITIALIZED 0x4000000 /* For anonymous mmap, memo= ry could be > > > > > * uninitialized */ > > > > > > > > > > +/* map is sealable */ > > > > > +#define MAP_SEALABLE 0x8000000 /* _BITUL(27) */ > > > > > > > > IMO this patch is misleading, as it claims to just be adding a new = syscall, but > > > > it actually adds three new UAPIs, only one of which is the new sysc= all. The > > > > other two new UAPIs are new flags to the mmap syscall. > > > > > > > The description does include all three. I could update the patch titl= e. > > > > > > > Based on recent discussions, it seems the usefulness of the new mma= p flags has > > > > not yet been established. Note also that there are only a limited = number of > > > > mmap flags remaining, so we should be careful about allocating them. > > > > > > > > Therefore, why not start by just adding the mseal syscall, without = the new mmap > > > > flags alongside it? > > > > > > > > I'll also note that the existing PROT_* flags seem to be convention= ally used for > > > > the CPU page protections, as opposed to kernel-specific properties = of the VMA > > > > object. As such, PROT_SEAL feels a bit out of place anyway. If it= 's added at > > > > all it perhaps should be a MAP_* flag, not PROT_*. I'm not sure th= is aspect has > > > > been properly discussed yet, seeing as the patchset is presented as= just adding > > > > sys_mseal(). Some reviewers may not have noticed or considered the= new flags. > > > > > > > MAP_ flags is more used for type of mapping, such as MAP_FIXED_NOREPL= ACE. > > > > > > The PROT_SEAL might make more sense because sealing the protection bit > > > is the main functionality of the sealing at this moment. > > > > Jeff, please show a piece of software that needs to do PROT_SEAL as > > mprotect() or mmap() argument. > > > I didn't propose mprotect(). >=20 > for mmap() here is a potential use case: >=20 > fs/binfmt_elf.c > if (current->personality & MMAP_PAGE_ZERO) { > /* Why this, you ask??? Well SVr4 maps page 0 as read-on= ly, > and some applications "depend" upon this behavior. > Since we do not have the power to recompile these, we > emulate the SVr4 behavior. Sigh. */ >=20 > error =3D vm_mmap(NULL, 0, PAGE_SIZE, > PROT_READ | PROT_EXEC, <-- add PROT_SEAL > MAP_FIXED | MAP_PRIVATE, 0); > } >=20 > I don't see the benefit of RWX page 0, which might make a null > pointers error to become executable for some code. And this is a lot faster than doing the operation as a second step? But anyways, that's kernel code. It is not userland exposed API used by programs. The question is the damage you create by adding API exposed to userland (since this is Linux: forever). I should be the first person thrilled to see Linux make API/ABI mistakes they have to support forever, but I can't be that person.