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 A127EC47258 for ; Tue, 23 Jan 2024 18:58:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 241A18D0003; Tue, 23 Jan 2024 13:58:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F1E28D0001; Tue, 23 Jan 2024 13:58:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 108248D0003; Tue, 23 Jan 2024 13:58:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 014538D0001 for ; Tue, 23 Jan 2024 13:58:49 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 97975A0A49 for ; Tue, 23 Jan 2024 18:58:49 +0000 (UTC) X-FDA: 81711487578.05.3F90BD5 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf10.hostedemail.com (Postfix) with ESMTP id 69ACFC000A for ; Tue, 23 Jan 2024 18:58:47 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=3HN6C8AJ; dmarc=none; spf=pass (imf10.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706036328; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=cpWjnKjDiAq8IzDesDTjxbv8ODKajI0ABce6SDLa4/A=; b=twxKWIj21KHorX7Hgw5PChw0pA3EJbNy0y8cgHBAyAtR6XnDBOjET7jMx9zuVePunDm/HB 15Eop5ERSo4Q/RbZ9vFA/cTUsEP/Omk4md65+7vuGF8Iju+sYP0cGuMt4qGDm9g2+l7SLh GTA9JsrRo1Sg8lfMOIWixaJmygxRPZs= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=3HN6C8AJ; dmarc=none; spf=pass (imf10.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706036328; a=rsa-sha256; cv=none; b=sQEaVPXQOBNncOVJEWpJnjRWpHxu+0Yo7+R/HHkNk7G3COeRTrqnn2AlgOO9TuxS1Kkj42 APrIDt3eh0Rhgz2iXFaoeBEoarwt6gWpRNWNskIV8oU46ivnKO5534MFhzTjKZ4NI9nGG3 fQqDww6fq/sdl5uErdGKGKeg+f59dG8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=85z1pDLNzf /l+6g12yGP+kL48gcbmAt/Exa7E4EizGU=; h=date:references:in-reply-to: subject:to:from; d=openbsd.org; b=3HN6C8AJTcP6apML6GvYnBtUjVM7yvJM4qGN fv1+L1Wt7+NSn4MNtQp6zwhhyrrCPm7inbeZioIntZNMgauhNHg8glINfZ8Bq7BevPRSNg ezzIyBqUhFDpFmfuuaePpLXwlNHz8pDVc8IGXxBtGszoTQDe6t0jAOaNupiENVkH1uT7DX Ej1vIXax9CpDddiomfw4zlm1DaSX/L+Z97aetWT7U/9Zo9zvquXPXyfRZ8+lt1Oj+9vqov 2ylBate61fs0rb5U2+LKXMd7dtPKSrdVavU1JYms6RQ8kYs4o2InmG9r3PmaOPCIEafFKQ 5XujUoKXxpuyzb/C11Aj8M/TGA== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id f1a5780b; Tue, 23 Jan 2024 11:58:41 -0700 (MST) From: "Theo de Raadt" To: "Liam R. Howlett" , Jeff Xu , 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 Mail-Followup-To: "Liam R. Howlett" , Jeff Xu , 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 v7 0/4] Introduce mseal() In-reply-to: <20240123173320.2xl3wygzbxnrei2c@revolver> References: <20240122152905.2220849-1-jeffxu@chromium.org> <726.1705938579@cvs.openbsd.org> <86181.1705962897@cvs.openbsd.org> <20240123173320.2xl3wygzbxnrei2c@revolver> Comments: In-reply-to "Liam R. Howlett" message dated "Tue, 23 Jan 2024 12:33:20 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jan 2024 11:58:41 -0700 Message-ID: <85359.1706036321@cvs.openbsd.org> X-Rspamd-Queue-Id: 69ACFC000A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 1rai9x477rhzw5m68icmdn6pdb6gastk X-HE-Tag: 1706036327-473280 X-HE-Meta: U2FsdGVkX1+EcJybkjpCr7Js9ddlNmrQnBiEAg4oN/eJQ4cQNy/wB4+ja5O4+RBbDmOOFz52GbHBw3REPED4OlOVQofS1ImURGinROzSBIAxHtnHBAtxukxqcSaLGnrB1+SDF65KcXK5jPBZjjXOYwBii9ECLwxpyR9UiYZ+h4V3B5k/Kz24e8/AlVETA/aAviX1TFNBpk1mXPrdiPcHk6Xf33Oi++G1bvibt6McdMpm0BSnHfKhFnshpxYVcEr6RANht3+2BojWZrKk95fGtW1yTVZbTaEJ+nr3/1hPnD3AfCtVhExwauGI9T/nYrWaRLB/2+NmB5y7i1kdhbQHlbxGizj2Ynnrga+muUj21CHuTzWEEVz5zjC0Y2+8PhR6QUt38vrqLAt0ZQLc5PWnh3B1DEeBe35mUUf3pFoCHncsC5r1S/rYXDjxp3zihedpa2dub4uMm4C2G+1/w3uJlnwjV04tFVxyxJ/JT60DDbqYHmXUYj0+m3saMcWXFtHumaqskTTxBATFJnqe9Ec3jukIIgHsQALQeXpid7gjox8G717acJLo8zPGjJDDrV7hjUNwQTv2uas3qPEuPUI9PG03c5FgjD5Upb7pwcj9dcTPRcgNOsUTk6L/jB7SCtmOl/i1bHDj4pw3zE8M2dCdVCrH0Cta1KXgOHJaem8Ado5TDfP3h6gmAUKQ2zMvjb0pDUcVTV+o9XQgDFBT4SpYv6If8ZuqBjM4dOT/35FmhNmJDs1AWHj3V2+pKBJaLgjiOhHypKauA1t5G6BCa8IuNpHz12jdLnAKbVmMOOBJX+nvbHmA+ywUMJoNumm+pcJ4GCQtXYWXIQcUDPMk0x3au1jlQvphfUopdN+qenzhK9EjfadznQGL6xNrZR68zLGRh7/ZDwWM33YWeSQw1Al5nPvWFyR9R3jPhN2Q1QGtdKwtbVpAfnlccn7LBH9x0x8RASFSHu/pBpSX4SoUgi6 Aur2Yt7L 0+hzN0ct4yzyNMTl2Y9VRgIuhUS2HZJB2mK9AfE8YIYLmJAN91mfAqynBzUup+ldzsjBT0lE1LbfmZoGnOO71iej6deqLNHOGiTcIpUgZlxI5maNbVnr+NQOTB2SIVcwEy61fazbT8MpotrlxBCJ2FuQeEWamitEi1XPbzODbuOvSm1gLIAJhmzxHM4lyliSTqrRhHLPBAD60zXvKjxZvgOTJoK6tFarcI5tqEYjSTlMEa4O84e8xQtoe9D7LxIvel0qmVwQQezxw9QYdRqEQw5ou01jk0yhRntsXi3Ndsd5V971vWUP4dJKjpPl0brZ+bAAhMjE84uMfnwuTeO0QJU4HulKy/WiPdfzNOifQsdlHDVcZsYbB4IvJDEmptmT7YvzmuWAK3TlauK00baf7fEx59qbT4Tdu14se7lsmf8unmi1tWZuL93klHA== 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: Liam R. Howlett wrote: > * Theo de Raadt [240122 17:35]: > > Jeff Xu wrote: > >=20 > > > On Mon, Jan 22, 2024 at 7:49=E2=80=AFAM Theo de Raadt wrote: > > > > > > > > Regarding these pieces > > > > > > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > > > > the map sealed since creation. > > > > > > > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In = my > > > > research I found basically zero circumstances when you userland does > > > > that. The most common circumstance is you create a RW mapping, fil= l it, > > > > and then change to a more restrictve mapping, and lock it. > > > > > > > > There are a few regions in the addressspace that can be locked whil= e RW. > > > > For instance, the stack. But the kernel does that, not userland. I > > > > found regions where the kernel wants to do this to the address spac= e, > > > > but there is no need to export useless functionality to userland. > > > > > > > I have a feeling that most apps that need to use mmap() in their code > > > are likely using RW mappings. Adding sealing to mmap() could stop > > > those mappings from being executable. Of course, those apps would > > > need to change their code. We can't do it for them. > >=20 > > I don't have a feeling about it. > >=20 > > I spent a year engineering a complete system which exercises the maximum > > amount of memory you can lock. > >=20 > > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my > > drafts, and saw it turning into a dangerous anti-pattern. > >=20 > > > Also, I believe adding this to mmap() has no downsides, only > > > performance gain, as Pedro Falcato pointed out in [1]. > > >=20 > > > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=3Dbp_sd+Q0Yif7NJqMu8p__eb= 4yguq0agEcmLH8SDQ@mail.gmail.com/ > >=20 > > Are you joking? You don't have any code doing that today. More feelin= gs? >=20 > The 'no downside" is to combining two calls together; mmap() & mseal(), > at least that is how I read the linked discussion. >=20 > The common case (since there are no users today) of just calling > mmap()/munmap() will have the downside. >=20 > There will be a performance impact once you have can_modify_mm() doing > more than just returning true. Certainly, the impact will be larger > in munmap where multiple VMAs may need to be checked (assuming that's > the plan?). >=20 > This will require a new and earlier walk of the vma tree while holding > the mmap_lock. Since you are checking (potentially multiple) VMAs for > something, I don't think there is a way around holding the lock. >=20 > I'm not saying the cost will be large, but it will be a positive > non-zero number. For future glibc changes, I predict you will have zero cases where you can call mmap+immutable or mprotect+immutable, I say so, because I ended up having none. You always have to fill the memory. (At first glance you might think it works for a new DSO's BSS, but RELRO overlaps it, and since RELRO mprotect happens quite late, the permission locking is quite delayed relative to the allocation). I think chrome also won't lock memory at allocation. I suspect the generic allocator is quite seperate from the code using the allocation, which knows which objects can have their permissions locked and which objects can't. In OpenBSD, the only cases where we could set immutable at the same time as creating the mapping was in execve, for a new process's stack regions, and that is kernel code, not the userland exposed system call APIs. =20 This change could skip adding PROT_MSEAL today, and add it later when there are facts the need. It's the same with MAP_MSEALABLE. I don't get it. So now there are 3 memory types: - cannot be sealed, ever - not yet sealed - sealed What purpose does the first type serve? Please explain the use case. Today, processes have control over their entire address space. What is the purpose of "permissions cannot be locked". Please supply an example. If I am wrong, I'd like to know where I went wrong.