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 2040EC4828E for ; Fri, 2 Feb 2024 21:20:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C83C6B00AE; Fri, 2 Feb 2024 16:20:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 979226B00AF; Fri, 2 Feb 2024 16:20:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8673C6B00B0; Fri, 2 Feb 2024 16:20:42 -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 769DD6B00AE for ; Fri, 2 Feb 2024 16:20:42 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 465CAC019C for ; Fri, 2 Feb 2024 21:20:42 +0000 (UTC) X-FDA: 81748133124.11.374C132 Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com [209.85.160.43]) by imf17.hostedemail.com (Postfix) with ESMTP id 6E61940011 for ; Fri, 2 Feb 2024 21:20:40 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Dch5gqSJ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.43 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706908840; a=rsa-sha256; cv=none; b=YEVOa11zRbrNFqQS84ISaaFGP7GYT4hF1+OYji2pAB608fgiJbwAteogB7gM41T7Oy+OOV nPU4wyfxPluxnBZ4vKbC2rl6sLaPlHaAvDkOcKZud2DCNfHzgLe0/rfti49UpcjS+4tXAV U/0ieZlK8LkXDTioABhsQMXX5gZDcr4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Dch5gqSJ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.43 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=1706908840; 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=92wvK0QB22DZGV3tUKA8OrcYGB+w2iD/0d4E9vYXy90=; b=LgitSNGQ3K2/wdJs1cHw5ki0zGyIBYfej8tENg7lXL8C9jKcA/n1avaWztdrU4nS/FRDt+ tQg3MoNhCv/1jc34Wj2HZWr29FBD7tncMzTGW3xaVpCS2Wks5o2FoGFVF/0ZQvT97ob1dq pwdh1XdEY1qdXTmJ+Rt+1sOzrRZqfws= Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-20503dc09adso1582857fac.2 for ; Fri, 02 Feb 2024 13:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706908839; x=1707513639; 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=92wvK0QB22DZGV3tUKA8OrcYGB+w2iD/0d4E9vYXy90=; b=Dch5gqSJJTrMABHwP/lxdZl2zkgj7hEA2Yby47CIl9NYM+Xbb89JRK8tk2rqc1h2og 6h5Lyu1gvWxLaTN/l13Hc3HIb0mKT25tgFGA/H75k65Q/ZXKip9YLeDfnRj9Frm87EB3 uNYc/sSeFvhSIUsSFQRYtslMhLSMj5SC2/Vt0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706908839; x=1707513639; 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=92wvK0QB22DZGV3tUKA8OrcYGB+w2iD/0d4E9vYXy90=; b=DiEjfcSqsLK5DKPEw6oUWtMN6lQ4x1OIR1DBObfYgcvUiONIN5l3zv6Cln5p3S5FD5 /R8QImmr8JOqCRcJnnAVwzv/nLDXjS3TxBspn60lBvlRoKfWNIFyQ+488yIUYRgGKgBu hln+kHIEGem0CVuDVoVhXwV5HWUI/2mi0uunpkwmK/95LOPfbI8cwQDI1wc5ghtpSyw8 B3+Dz3SadCPEkJXVAivdBro7x5N5TExKUsLAUj/xmUnn0Qy9cF8b0mnJQJ8W99HBENqr 72Oiqw/Bozbt7LOlDvLgbRG60mvNeVfQQ1Rg4WURFfgxY9/g3Mi7EeX/DneulPUSjPeR 35Ww== X-Gm-Message-State: AOJu0YwVE8cpWt2I1JmJhEBRV+2V5iYyNTJCQ5nO28WqipGBw5lRuTId WlO68qxjLA7r3aEdeDXM2h7+RjJ5XxntpDnfuIOc4IqHdxbEYy72rvdfTfLEli9Khocno7nnYnN +32vSZtx/gvMM5opJoG8EmXB8cjW8Vnp/7dsE X-Google-Smtp-Source: AGHT+IEHFQyrtYpxn0tuAlfC9rwX/+nRhQdpjBGjKESQj1UnpUByy5Y6kofBq7OGl00pybgPooaYvuinpoC8QXzQhJg= X-Received: by 2002:a05:6870:7024:b0:214:9ecd:56e8 with SMTP id u36-20020a056870702400b002149ecd56e8mr932493oae.33.1706908839487; Fri, 02 Feb 2024 13:20:39 -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: Jeff Xu Date: Fri, 2 Feb 2024 13:20:27 -0800 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: Pedro Falcato 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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6E61940011 X-Stat-Signature: 7judmcfajcixg4ko499unmxw8xyjgd14 X-HE-Tag: 1706908840-27072 X-HE-Meta: U2FsdGVkX18naa17DsrnLlmuPMU+E9kveJXB1DWrohuBUhSOOLskIm7MoUT8PlpFA8uBUO7JFOstf4sYNLUc4Gfbm0qLoAuqS38XsuqUJ8Py1hnAuNj6xbZI48P5IyM6wAhWSVvZCxL8Bdma90jJe7CkwkWTEETbGXHAJwfLx58Ly5X47QuH4Dvi+22vHSbjATfsPG8dRZCq50rJXyLQYNpj002towq5hZUL6aoUuwgvXc8Q+GR2NEb06EbQ1BfzwwxVPSDHKXVI0kOLB+TA1/8EcR9csL99IWLV2Kl2TjpwOGA+Io8zYxfPUarDNERvYLP51CE1NW7T4VSuyKcQSAO54HFqmVEsPPmj2QAHx55kI2zX5M6HcNaZoCd+I54HKQ1AUBq50l4x9fJxbT+Ppsma+hv7B2AanLM3IXvMUv4F8crysgRbZKcVHy2ahIvXgS5sFe97e4GafHOA3ZAccptAtAFsqGd1lsHPYFofYGhIgTc4Q+i1tcQODL6XCmwgK3r7fEC1BxjGtww6CpoI0Tlr2Tq3SK+Ig9KQiFxPzdgDKrirWFBS3yB/30UQ4o8lmdAKVlD7vLM1OPjHILvdwbKCYh60Ai3usJGIEM7+MGQyYosAiiwlxAJxQQRrgrmYEwBvgVlVY8V+jyy6p9p0+NwJC4R3z+xIcSPqsHMJPexy/0C3GC+ENjKDVaOPHmCASEoKSXH2iRQu8iQzr8eAq7tWKb5JjQkWogwhP1S8+983aokxSJWfv99AI/ZxkQe/rJRtV8Bi6U+Y+oCB9fCO/HJRn4VliV5VacR8szMUUwB/CyF5qeOamB/K4lsx04fiXFOciBBBxx+BZoQgaM35+B0wNrRY/RMK+gWaFIeneC04JmiyLmyOVTHgIjCCUzQZLxfA4ffz6pyc+u0hecViN0uw7BAhUZnySbPOukohFBIhCLgKO967NYWzdMvlDL5VFouUJ812PYYifWi51Yj hpUds6jD AJ5syuurSJBDuMe1UQoyuT+hl5lkaOzn7Nc1x3M5yojeYbwmNwx418Q+0aWuZP580IdMjFhhxh+n0EoRC1d5M5SLjhxQxQdx9S1fwNmuNpwYJfYmqHM/sLG52rIqfB5H2ZzN+WXY+OzOa5UMWS/hmqXq7cK8URedWfGprDPDLS//R5cO8NKPhOQzlssBCgv21it7Qe3otFoomJ34lUdKjeUBK1fS5Yo3zU+c3TgtPiIYkZEBX4j38d+cuNRWJyiKPzt4zMyDa7uTRBnIX0dw2fUJtxSrc8DhVSlwGTgPg0+x8W/L1ciFA/7KASW7w2+rae1ZZzBG3w7jYTwTsEr2ritl9QT9Okvqq0DjW8qlWa0mMJaPA4ZAKmhl2QYE6tzV89vCeLsJHxPE/T95YQ1pv1uWK0lMp2BT+IuHlFAwOOSk5riCIzVYAXGp3PtvLdR6jxp+2 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 10:52=E2=80=AFAM Pedro Falcato wrote: > > On Fri, Feb 2, 2024 at 5:59=E2=80=AFPM Jeff Xu wrot= e: > > > > 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 i= s > > > > easier for dev to seal a piece of data belonging to another compone= nt. > > > > 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 immedi= ately > > > visible to the programmer, and the lesson is clear: > > > > > > you can only seal objects which you gaurantee never get recyc= led. > > > > > > 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 docue= mnts > > > 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). > I think I have heard enough complaints about MAP_SEALABLE from Linux developers and Linus in the last two days to convince myself that it is a bad idea :) For the last time, I was trying to limit the scope of mseal() limited to two known cases. And MAP_SEALABLE is a reversible decision, a system ctrl can turn it off, or we can obsolete it in future. (this was mentioned in the document of V8). I will rest my case. Obviously from the feedback, it is loud and clear that we want to be able to seal all the memory. > 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. > > -- > Pedro