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 0CAC5C48291 for ; Fri, 2 Feb 2024 17:59:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 778906B0074; Fri, 2 Feb 2024 12:59:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 728856B0075; Fri, 2 Feb 2024 12:59:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F0E66B007B; Fri, 2 Feb 2024 12:59:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4F1156B0074 for ; Fri, 2 Feb 2024 12:59:09 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2019FA26E6 for ; Fri, 2 Feb 2024 17:59:09 +0000 (UTC) X-FDA: 81747625218.04.B150BB7 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by imf13.hostedemail.com (Postfix) with ESMTP id 6CE0D20011 for ; Fri, 2 Feb 2024 17:59:06 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=iLwF8vKX; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.51 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706896746; 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=V3MyFHdGuJXKIHAocH1cP+k+k6xBW4irfqW7F3umGsY=; b=QRxQlPo/zQ8I+Z6oSK/d2MKRE88RlFeChgG+5zQtnTgNeT9MZaIg91U9m7eyIwTC7LWLEF YoIOetevlGuLLWv4Ozn3OgyAE8ZToEMSIy8BFFDIyb4c4bx7UUOWyXl13eU+5qe/y6NcyY /XBM+Ojvxm1xwWm9P+YCVIe5z0x11Xo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=iLwF8vKX; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.51 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706896746; a=rsa-sha256; cv=none; b=HdiiPm/dqaW+j3usq/X6GsPYYh+S4gsegsYsTSI2pb3ur8dJSyB0YAA3HFZL4h8+B1wVmM BT5cX3JXw5fMVf4d+p9P+0+d7NnIx4224xfCK/5YAgGB+gBrVCTDzLZ79pf1qc59FW40nz pdcUFSDGLnIHwnTzGGJt8JpZHIwu20k= Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-6e12d0af927so1664283a34.0 for ; Fri, 02 Feb 2024 09:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706896745; x=1707501545; 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=V3MyFHdGuJXKIHAocH1cP+k+k6xBW4irfqW7F3umGsY=; b=iLwF8vKXrWgxUyISMv7XR+MuBvP2VvYapuU8HHY0wcRhpivYpSXvUhNHijCe7W/kda iCyryYB2aPT0KOgINXaDuT03s8X7b0uuq1jmEXNSdwhwEsLGloadwbHQUI6/U1HYdEqj ZH2XxqswWLrYz42Y8nvDnBP0XGgmZEzxOqvrE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706896745; x=1707501545; 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=V3MyFHdGuJXKIHAocH1cP+k+k6xBW4irfqW7F3umGsY=; b=KtTl4COUdfQYG5ExnRPus7Phqw8YRJnJ+qRASnBLQjqKI3YbNxumUaMW1mXoLpFhoV dZccpfqJU9dQu6sbGyu2ISDFe3Ut+Goj8vqX5ehUQjtCGo86NFGByP4PEUl3QIPbVFL6 P4SN1RgJlGIAsudc7PSFPMpsfHIq3gFQWqllWkMTnlKn3Lwcacz82WRL4MkQiMBZYRPf wtNfcQC0FCyQtdcJFbBYUXLVVXR9th2Z/KkpK2VeJXH3a6sNy1cegB9pZzbOjhd3bwOX nW2/cW4DqtspYa7Xbfnu4piCzf1gsMnj4CcVYR3yPSqfxfYfzBOgdA+kMT0bOnT87QSh otkg== X-Gm-Message-State: AOJu0Yw+1AL/jkM9jCeHw0RvC/52uqrwbOvVO2GCoz2GbYDQ2x6F2MsW og7iiCIm9i1vvh97pGUc7C7S7ptz5V8oPPDm/iyD5rfFJbr12yGHnF6o1RwT0UI0uvXOTyh2AK2 WV8QWagfJ554wxdCSnUmnveeBx+Aa7zhK6LH6 X-Google-Smtp-Source: AGHT+IGpU/xeyR4Cac3EmRCRvgJs1LUHcLu+M+2J4+z8SyoU1mY+7pncKYINef4x09GNaY4SUrFEJxNBeJFX0e+aASY= X-Received: by 2002:a05:6870:200b:b0:218:eff8:3161 with SMTP id o11-20020a056870200b00b00218eff83161mr487923oab.39.1706896745307; Fri, 02 Feb 2024 09:59:05 -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: <29248.1706850035@cvs.openbsd.org> From: Jeff Xu Date: Fri, 2 Feb 2024 09:58:53 -0800 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: Theo de Raadt Cc: 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, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6CE0D20011 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: dd1bpxkapqtik1rzqg9qeent7naqexh3 X-HE-Tag: 1706896746-759066 X-HE-Meta: U2FsdGVkX1+jIZitbNubX+7nfow1COiemzHtHDHWjLLaYWTPK25l1T1RcC2MBEpeZ3mIu1wVYqxYdfdwnS0D/jKJkRlyrZOYZylvD11sbDTD+RaB//RD19o1w+J6RY71bft05al9VFWWu0IU2bf05k8dYlXtnuSJ8h47NCAwohkzrdAZGp2HJk5t3Y5Ac+rd5YlyrUGuvHY2lYuZnrncpPXfKMo49qxKWbV30XhOmK17mK69BpGoiEaSaV/HrMCpTxVTm6dDisUJa0olIMy5vmgpXaqfqgFLhZ9/EtYmCeRp67aRj6I6sc9a9gEPsJgtdAKKNfJkXfZ1vAdMnyL2bPnGdSomBJE7zH0j2/GrHivwNhpo/s9vVqDTBE5pjRW6VtWXa7jn2opUmTNBBJReFHn3AKQeB6GmvgnPcGo9HWz5lE7kxgQofkjeXwpyr/w97OYPrntAdzzkPCK7xb3yBTTP2Itp7e6duHpvNu57uy0oH/OqXnEfn1X72iWqP+alcrZYGdpHgxphMQXR98/x+M7BGJ6a0+w1yaRO7sU1wActwFBeI7E92aDS+C7yZLZZtVPOR+gbuGixOzyIhrQVbVuiTybIQ7ERhEnfV46Uy5iZebjPLqL1zx8+rC5H5Ie9hki9nAYKq+xvHfBTzxjizNERCICINRqoeoN4DS0hNqzYuTeCjEBSg2r4XYmzJDIr9PaAETM4gONWnlZdF6rMRezolZ7lvRp8oyqh3Rlsl7SMLFpGjGTIyYCZXNHRFeLFr5O1wWwFRDxHrJT7ganAQtn8GgCd01oMRmU7e6q546J3TKKH3dA9jeIxYOtDQRkX1PmuKaeYpIZnzwvE5roToEQGYFNIAVzK0KKuz70pWDmY5TQEwttJcOYNVJRW2VuIpKrRVf1z3lZxethQLJWcXrbcIOOycKgNsIMEY8IOyRx/cFZtEvea/EbblEt1B8UaQQYJO8OLDWCHESQnb12 Mhph0UvE MwVMeE9NkB1zzMyw9Aqymx6xay83P8C1fxjYLHD9RoCaj8lQqVrO2gJYxTDP2MbtmKBTCgaKuRZVbH2y4pujx//bBVGMzfR8FAqcrSx5eKvKipnv/Lldb/J955dPp4ZkgiIRbaTo1XDv60HNqRWxiQT6cT2Ruuf1y6g3VeO5pNB/LSiJ9XN6rhpKnLk+USsc3WgvYUPtZppH9szON2n+Keb+VBLu5EOefLNMxoObYw+EBDDULNlqyCP9ZFH7v8MOXDC6Ebvi80FaeBijwA0EYUycd/z3J+4NlPvqsn9gegmGgk1ZH4fWz+A7YZzMBVll+MpeLxMgTV3nZg5Qr+DmcRBmPgPxIPS6BGiyoExSW6Nlyd11Hku0+0BT/D/iWgTlkMPRz/oMPISms2QHsIxnsD7PnMLZnkuh5iY10 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 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. > > > > Component 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 immediatel= y > visible to the programmer, and the lesson is clear: > > you can only seal objects which you gaurantee never get recycled. > > 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 docuemnts > 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. >