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 104D6C47258 for ; Fri, 2 Feb 2024 04:05:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97D546B0085; Thu, 1 Feb 2024 23:05:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 905666B0087; Thu, 1 Feb 2024 23:05:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A6646B0088; Thu, 1 Feb 2024 23:05:13 -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 608206B0085 for ; Thu, 1 Feb 2024 23:05:13 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 32C4CA04D5 for ; Fri, 2 Feb 2024 04:05:13 +0000 (UTC) X-FDA: 81745523706.15.D5E2377 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf24.hostedemail.com (Postfix) with ESMTP id 3D85018001D for ; Fri, 2 Feb 2024 04:05:11 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=rRkd3Y9t; spf=pass (imf24.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=1706846711; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T2MDUlqz2PimsWAMLHvh+xWznF4huF+JDDEEA0rlt00=; b=EEp9pE7qSp18w6BoCqxNMEGjoHcXFjfeytTYJNWGGZsVsBMKlo7/Ha8eNRivC/OevGDiIk SIvTAPCq3AF9thk9yUh12QlsJhL11kYm7ByY7r41+pqdJeZwsLRi0GvGTjs11TdxjXK3mJ b4sJ1Igfwpsx7Xm6XOqOQuvRUFv/SGo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706846711; a=rsa-sha256; cv=none; b=plM7lF5M8PAmwYhBVHFkBzR5gqygz85A0b4wwpo4dsBwC75DDn5gYWWhgv1lcVUc70oFOQ nk+1j3xn7erTFlskrkItdDqnJ5VKKs7c64rlHgVwFvK5QvVE8/MsYEfskn68QsWTGgFbR7 Bv/eeRFICy600VrG+nHsZMaOgAA+V1E= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=rRkd3Y9t; spf=pass (imf24.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=NNLcYCuc4B F/659D3HxJb+VQHj1+QX8RRAYRfMCjV08=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=rRkd3Y9tCaT99HAOzulVgYIo663rTR0TJ HOrCKvy1wvCo9kQ+VIuoYTuLARxRSwx0FNcS834C5NKE6XhczFPzhxJWbYtiCCCK4o44xQ WYENp4Ro9L5NOlkFoBwFe/MNm6LMRxaQuf9ds27DuUGE6knsEcFGCgb/ZbA60s6scfYD5u b9YJpdlnmv3LxZGFuio1O8F9hp+cqkUZhslMryt1sfmvGhC2OJEd2vwpiZJAycQexyJcvo yw4t24gxBgj2ZJDaZ6Q1JsNnReiVPFff1skgGdcz105x8f3SyERpwV7kjrBqb+velzGYDI tdBDE/yrWOidAHQk5Kqz3YmL3UFAQ== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 92cf0eba; Thu, 1 Feb 2024 21:05:10 -0700 (MST) From: "Theo de Raadt" To: Jeff Xu cc: Linus Torvalds , Jeff Xu , "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 Subject: Re: [PATCH v8 0/4] Introduce mseal In-reply-to: References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <58408.1706828083@cvs.openbsd.org> Comments: In-reply-to Jeff Xu message dated "Thu, 01 Feb 2024 19:20:08 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64877.1706846710.1@cvs.openbsd.org> Date: Thu, 01 Feb 2024 21:05:10 -0700 Message-ID: <8744.1706846710@cvs.openbsd.org> X-Rspamd-Queue-Id: 3D85018001D X-Rspam-User: X-Stat-Signature: sc3g1956d7w7t5rmxs3fd77xigt4usp3 X-Rspamd-Server: rspam03 X-HE-Tag: 1706846711-114907 X-HE-Meta: U2FsdGVkX19kjDTgJzUNYm6vmTcMAyvMWQJcUqfMW4jntuhl9vG59m8J6kFPff3PYRqhBqELXxE5QXKPE2anzX8FavU0MUtbdN620qH9qpj5Z50UHbDIhQhfnglIhbg0Q4k/80+xdnR8+9xYznRcp0IGFnfXl9NHTBrAKb+c7MWajnIVH4vKhnAlh4D+uXbQh+4d6SDY+kovCI9psvDmppL6evBtyYEJeZv7lEa6wGnDnME3wsvFsPSWGOxe4idnnBLJLUWBiU0F6xyBPAzIrHHm6Vcrb2alEXN3BPhsSbit/YA+vg4rr6k4lAR9Oeczy+owp6P08OcuSWPKJVrZ/P6O9LDnUR7NXqeshRy92natX8qWiYE+bSBk6if25vxmuzWPJASfjewA97X7Zm8UVCw5uVsIOLwabJEnNccwHuh/vjUI/utQesPzzvcJGHngKwgZygp6UTf2IK+LJYvCRZD24oXQKLl/YwpQfmxfuGivB9SBnZJrF1XxUabXoDeQ9oQsFyWmCHdpjnMXigoOdTtaLoi4vKHkRDNnG2efQhWJMa5ZHk1YqDABwGETj1cFfV4CaBRECaN626CX808MW/uQi/lDHCmRFLk2DRNFyALg3ICJPH6HUwiLnjgNjy+TW1Q/ENq+x5RA00+h+ZgTrlcoS+Dxjl4QUjxEvdHD1rvnzhVBxzqO79NLmIsdBmU1G1pen7qBv6RlGFxKBoRn37oFKMTMngPP+LyyCSi2rH5ZWrTWSKZX0gK0ebQu3W/tK1mTyIOSVJVS2ebUkMOoBmF+0XMoN+0GA8FPHJDYenzgTyj+EFgfoBiMOcJjWyLwnfotflQ6GtQdE6p/I0+I+7MzPE6eQ5pxZGIHyjEgWpYOG1hBAXkX2g1+vEs8Vt9jawlLgu8m4T9XG0lZ4KSk05jSJzFqKPUM/CIrrqwmUN1BfvoXOzynQplTkV4cW+ZkYaLLA+puacvNpJAx225 rQZnoCfa mA1RMkMBZyNRs/I2BAjEgUuonYMJ+G7rZRa2jwaqA+WKkX6DSBsxKXuWPihwYu95QafscF1X+tJ4tBByaOQSbCYQGhs2rvwkK93St5QZ9vqLdG+wVuBUIyvOOrbEe94GtxKwGdJIwR1IAJquSQQaok8wyR6AYo7Pa23OvkAa8TNzeTTCUFR+5+9YCkDsqYrcZ60BbByNYU2cae+h2XCqjM+1TWXf7/rjvZAOIFjvp0LAXvg0= 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: > To me, the most important thing is to deliver a feature that's easy to > use and works well. I don't want users to mess things up, so if I'm > the one giving them the tools, I'm going to make sure they have all > the information they need and that there are safeguards in place. > > e.g. considering the following user case: > 1> a security sensitive data is allocated from heap, using malloc, > from the software component A, and filled with information. > 2> software component B then uses mprotect to change it to RO, and > seal it using mseal(). p = malloc(80); mprotect(p & ~4095, 4096, PROT_NONE); free(p); Will you save such a developer also? No. Since the same problem you describe already exists with mprotect() what does mseal() even have to do with your proposal? What about this? p = malloc(80); munmap(p & ~4095, 4096); free(p); And since it is not sealed, how about madvise operations on a proper non-malloc memory allocation? Well, the process smashes it's own memory. And why is it not sealed? You make it harder to seal memory! How about this? p = malloc(80); bzero(p, 100000; Yes it is a buffer overflow. But this is all the same class of software problem: Memory belongs to processes, which belongs to the program, which is coded by the programmer, who has to learn to be careful and handle the memory correctly. mseal() / mimmutable() add *no new expectation* to a careful programmer, because they expected to only use it on memory that they *promise will never be de-allocated or re-permissioned*. What you are proposing is not a "mitigation", it entirely cripples the proposed subsystem because you are afraid of it; because you have cloned a memory subsystem primitive you don't fully understand; and this is because you've not seen a complete operating system using it. When was the last time you developed outside of Chrome? This is systems programming. The kernel supports all the programs, not just the one holy program from god.