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 EAB42C4828F for ; Fri, 2 Feb 2024 18:52:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F8D26B007E; Fri, 2 Feb 2024 13:52:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A87A6B0081; Fri, 2 Feb 2024 13:52:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 449596B0082; Fri, 2 Feb 2024 13:52:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 31A736B007E for ; Fri, 2 Feb 2024 13:52:08 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 04B04A0FF6 for ; Fri, 2 Feb 2024 18:52:07 +0000 (UTC) X-FDA: 81747758736.16.D1CECB0 Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) by imf26.hostedemail.com (Postfix) with ESMTP id A249C140016 for ; Fri, 2 Feb 2024 18:52:05 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fTd6cWII; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706899925; 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=OzAQr1ap8fenb+jIdc4mT63hDIxdhoa2yYpMaLdZczw=; b=dthdG+hLHICNXKwFoG5mzIxIM2AYrK68/X9RMTYLaz5X0VnICb7KiPbbQZgnf6v5GCrAAh 3ymXzOl9eTDZVqra8G1nsWXSAAMcsrqW9arheubNH4aNKXXCPYK2DyulhiyJUuOBP+P41i eHFoZqIFFIJcSn9RpGMsT1Tq52WoPPs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fTd6cWII; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706899925; a=rsa-sha256; cv=none; b=CgsgObJMRmax7UQInY5d7Adevc1INpwG7YtsSLhV367aCh4lkAXRTmLpk9N/Aykwp3i44j DIFMIHY0vQo1ogC64JH3rN58SZzlHTbnfbuYNE5/bN32Iz6KRAxtgB7oxdDNjIuGghHEIq kaBLvzosqVuOBmi+WMyv2P89BcV0xqA= Received: by mail-vs1-f46.google.com with SMTP id ada2fe7eead31-467ed334c40so1048138137.0 for ; Fri, 02 Feb 2024 10:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706899925; x=1707504725; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OzAQr1ap8fenb+jIdc4mT63hDIxdhoa2yYpMaLdZczw=; b=fTd6cWIIFWr0cv2EOKtlKD9xGbR5ElGSXQOnK5fXR9pB+dtWoZmcg/Bf4NLhbbneJP dBg+1HgDfXI1XqrFlUNAsDZL+n8YxL/Ey6Y5TJU5+0LW9WAsuVRkQCWngASd1CI/WwLE QzTt0P5Ei7XAUZbfvbbmyGQwvnBf7l1ZPsgIMNwUUfOlM7YlNzCW+qdUkZLId/nbYB4n mBsxAB1vT8RcUJfPMSIQUCjpiiiorzuQ+7mctCzxmpot2tb++PGlQEHLVh3Cudrmk7/Z JOA2pi6jTa+vGCBIO5jhzty4P52pfAaDSRoZLsE/sHIRTqTu/Bs6Cdr6w9KDoxKl55MY lsKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706899925; x=1707504725; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OzAQr1ap8fenb+jIdc4mT63hDIxdhoa2yYpMaLdZczw=; b=Vu6YLb/U+I5zJ+d4N5N1fAbPboBBcqGHQmmCG4uNGIOurW5oN2SPVxq6Hg9EkCQUdu HRqtEx2NPj+x2s42mkX8ib0yTfthAqK6cmGND2wQm5crzCCRn8bUirGIN7vjhhMK6vnQ O3vaRlfu5LApcIqedIs5TrVNOJf+Xlr8BFcTdxztWCiDTQ+UHg9jFS1GTOkIyc/u1GEz y9EkAQvUsPL3DnrGY/WJSGvjl5mEK+p+B0WQm+Dh6qO76+ge0Ia4GWkg3afqAeI7HbX/ MMZsb+nna4e+SA6gRhWT30xKiFe36mLl8XYlYW37aCMeTsX4dPZ8pXkQEqW+znMi5KvK j5Nw== X-Gm-Message-State: AOJu0YwEiRyvSxJ4v/MOmDJTddoD4g2RWn0uGAZfsA9ddgKVWc7QPc6W SR9yhvxdWVXeQSRyt8/U271pRRqqF0SyZV+O3+6ntzwocCN8yyZwX2SVKG5l/RU6EfT7mARh/jW 2pjZtSQInWFYJV33KTzLxjWwrATY= X-Google-Smtp-Source: AGHT+IHpATLtM6UhFbndhKBf6EqvX2JU7kTp41znPx/PGymZrFwm9VYWH5L8GWXzPE4x5Ra7T6WPp/G2KIs4iBjH3LM= X-Received: by 2002:a05:6102:3167:b0:46d:647:67da with SMTP id l7-20020a056102316700b0046d064767damr2063513vsm.13.1706899924579; Fri, 02 Feb 2024 10:52:04 -0800 (PST) MIME-Version: 1.0 References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <58408.1706828083@cvs.openbsd.org> <8744.1706846710@cvs.openbsd.org> <29248.1706850035@cvs.openbsd.org> In-Reply-To: From: Pedro Falcato Date: Fri, 2 Feb 2024 18:51:53 +0000 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: Jeff Xu Cc: Theo de Raadt , Jeff Xu , Linus Torvalds , "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, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, dave.hansen@intel.com, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 7d3r9roo8gk8s41e34fpd6iepc4ifwmt X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A249C140016 X-HE-Tag: 1706899925-859788 X-HE-Meta: U2FsdGVkX1+erSkRZqt1VGJpsrLg0kgFkDXk19qL2aJTPkO4jWQw3KrZBS1NvWpzEz2i0NprBCcHN7rZCkqBGsl+reWMHiEDsWbyPw3zku4IyhsVPMNVr8r7WM5MVtSTyhkOcMIRwuPH0sydawbxpaiMhOYJxYfbCgPI49KBkfM4Y6cbzlwZJq1rLOkm05wba9fVwHsT9gcYGNyBZ8KyNRBXt3OVjLRJepm6Wp4vS5227U3TAaYVisD0vtHq0Stv4yO4wmpee5Pxzxt8Q1xOVTloeh3LaBA5b7GVEF+AxTZgNIBbrw2mM+O99ggvhc7w50pv0mHjmtNDqKJwc4iMkdHiBree4tz69K6MSP8Ze4fxgl/qGghQ29mcGpK+1DHCKzbHbJ5YzLqlXzkqKTUVrbg3yS8lZlesBNgphOHaNPjhzln0QiNaiOAkIGi35ftYUrdGVS0oxbijgR9uOePBs5pD0rxA3AWC4TDl2ZPRvsWgihNN+tZ7XFTPLtcgSU7d1mHa9l8eC54/oA4vwcF4LUdZiMjApUw5D1+2eY64yRQnXTH+YVWDTr8Z6YpLI7D3Us/mP1HDSVNfYYickovUn/72kh6YUxOkIDzCVUDMUE4pqnNO6vE+RFyXrr4QR+TBi+7BU6GPpF8347DtQCpJFopIlvalCAPOvEVwgU4wZ35S7qeyNLJ1hWgxV4Orxwd2cylQ9QHp6blD9tDcLBQY4ZfvovlR+TWeCehnpKT4bwx4ddWsidLzZ8z4UZ0Vnhn/4g5qSUBJdPy0r7FoX5rHmN3gBtJ1ULkAJYDAa2X/qSTjcwA9E7nGf85a8iVQdvj7e/t23NF74IN8Ybk9ya0DB7PmkGlxugPiGs5aSb9YUCBpV5Q05kbZZFlmljTlcfI4bQBULPfXvvyodZ71WDpuLtQqeCl6uhc1fVP/fEwXsWIlgWjx7ti3r45fC7GkiActipPl0runTZxu94W6Vnd WYNkZA8A 8V3/9NBWgd9UYBgUhJky1heu/ksQVTTX6Y+lWz0BoxjhGU0tYsSbz5zoScci61utB3TiUxZUFz1Ivn61+R6Ff/nfYM1rXPM8JX/gUiPi/AHSXJhHzTmAUzlj8tB7qOFet1Gxz1aSWj7BQR7yEXkTJ+49YUoHSuPar7u9T0/0E1lcYXa669buKeN1XMGDw/F4jJXpaVCOpN6AZf9Uf1jYjHhYpHz3n0o24SsMy4eak+/qlL1H9DXCSc1QyCqhm6WbO2yqA2A2Zcgn7mnvlCsCrlmyDjLcOoF4Tgtv88l8MReVNcW6DISlBIiNqutxWp7Pvh0V9lz49GY7ScYScArGPbhEz8u0TKxk6f0cZ2DrYrUWIPNf3pQleTov7rDFnmFesLdTKDCjZJpmQGAzxXsIviURjTZX589lD9Yg3SkQsssn0EbHd3uvCyj0N8ehg+J3D3LDiGC4hG0yQC3StraFdegITELrTRLO4Eu9W6HM9hNNUGG6HBFOgq3qJBg== 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 Fri, Feb 2, 2024 at 5:59=E2=80=AFPM Jeff Xu wrote: > > On Thu, Feb 1, 2024 at 9:00=E2=80=AFPM Theo de Raadt wrote: > > > > Jeff Xu wrote: > > > > > Even without free. > > > I personally do not like the heap getting sealed like that. > > > > > > Component A. > > > p=3Dmalloc(4096); > > > writing something to p. > > > > > > Compohave nent B: > > > mprotect(p,4096, RO) > > > mseal(p,4096) > > > > > > This will split the heap VMA, and prevent the heap from shrinking, if > > > this is in a frequent code path, then it might hurt the process's > > > memory usage. > > > > > > The existing code is more likely to use malloc than mmap(), so it is > > > easier for dev to seal a piece of data belonging to another component= . > > > I hope this pattern is not wide-spreading. > > > > > > The ideal way will be just changing the library A to use mmap. > > > > I think you are lacking some test programs to see how it actually > > behaves; the effect is worse than you think, and the impact is immediat= ely > > visible to the programmer, and the lesson is clear: > > > > you can only seal objects which you gaurantee never get recycle= d. > > > > Pushing a sealed object back into reuse is a disasterous bug. > > > > Noone should call this interface, unless they understand that. > > > > I'll say again, you don't have a test program for various allocators to > > understand how it behaves. The failure modes described in your docuemn= ts > > are not correct. > > > I understand what you mean: I will add that part to the document: > Try to recycle a sealed memory is disastrous, e.g. > p=3Dmalloc(4096); > mprotect(p,4096,RO) > mseal(p,4096) > free(p); > > My point is: > I think sealing an object from the heap is a bad pattern in general, > even dev doesn't free it. That was one of the reasons for the sealable > flag, I hope saying this doesn't be perceived as looking for excuses. The point you're missing is that adding MAP_SEALABLE reduces composability. With MAP_SEALABLE, everything that mmaps some part of the address space that may ever be sealed will need to be modified to know about MAP_SEALABLE. Say you did the same thing for mprotect. MAP_PROTECT would control the mprotectability of the map. You'd stop: p =3D malloc(4096); mprotect(p, 4096, PROT_READ); free(p); ! But you'd need to change every spot that mmap()'s something to know about and use MAP_PROTECT: all "producers" of mmap memory would need to know about the consumers doing mprotect(). So now either all mmap() callers mindlessly add MAP_PROTECT out of fear the consumers do mprotect (and you gain nothing from MAP_PROTECT), or the mmap() callers need to know the consumers call mprotect(), and thus you introduce a huge layering violation (and you actually lose from having MAP_PROTECT). Hopefully you can map the above to MAP_SEALABLE. Or to any other m*() operation. For example, if chrome runs on an older glibc that does not know about MAP_SEALABLE, it will not be able to mseal() its own shared libraries' .text (even if, yes, that should ideally be left to ld.so). IMO, UNIX API design has historically mostly been "play stupid games, win stupid prizes", which is e.g: why things like close(STDOUT_FILENO) work. If you close stdout (and don't dup/reopen something to stdout) and printf(), things will break, and you get to keep both pieces. There's no O_CLOSEABLE, just as there's no O_DUPABLE. --=20 Pedro