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 C3EEAC47258 for ; Fri, 2 Feb 2024 04:54:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41D3D6B0074; Thu, 1 Feb 2024 23:54:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CD136B0075; Thu, 1 Feb 2024 23:54:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 294626B0078; Thu, 1 Feb 2024 23:54:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 193F36B0074 for ; Thu, 1 Feb 2024 23:54:44 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DF506A055F for ; Fri, 2 Feb 2024 04:54:43 +0000 (UTC) X-FDA: 81745648446.06.E3E7FED Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) by imf21.hostedemail.com (Postfix) with ESMTP id 2EEE91C000B for ; Fri, 2 Feb 2024 04:54:41 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZbRD5BTF; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf21.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.45 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=1706849682; 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=1jPypSiuNIqXZVdy7vjTfUkB5jafh5E5WelADJcP20Y=; b=08+O/4z8aYABNFkI8zisqFd4lH+tK/9hGBxQHPI3gA+ib8MITwJDEXhM/c04foF2b/+bYK I2u51T7zh/43aZPe0HVDhi4xcsnQCRzV06bA8DfYI20RKpASNSHHHF656sNsptjeRbokpd ou4n9OdcHMNaEyruiOZZWBjc+8BSCV0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZbRD5BTF; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf21.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706849682; a=rsa-sha256; cv=none; b=udZphPtobGLiLTk6RtWgbeZmOjJDOIjDBAMZNRijXVETQLvcptiJXCy5ev7sfd3takQ8yG If2Md1XYcfXeNtYAh4fOAYA8zapT7SyP6He+iialcu5jDqdn+JqQIjdMOenad0LfXlvI3w mSe27e3EIzBu6AoAiw4eFio7X4WudWY= Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-206689895bfso1134870fac.1 for ; Thu, 01 Feb 2024 20:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706849681; x=1707454481; 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=1jPypSiuNIqXZVdy7vjTfUkB5jafh5E5WelADJcP20Y=; b=ZbRD5BTFhrZutHBxbvDVaXKw7FbIJ5zGqRj5Zf+HuJsoZrix9YPdHfHIMqnD2Mvduh VBiQEIzTN4nf3wJgk6S8M7Jc2RNnRng2psYTtn04dG+dGhnxmETNCXSdoxEanK0qRw02 tXWMVTJCobHZ8GaAyhex2xuxhQeunhptg1xbs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706849681; x=1707454481; 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=1jPypSiuNIqXZVdy7vjTfUkB5jafh5E5WelADJcP20Y=; b=oyDh/G1g362J5rgZMwlpD0Y7xh6rI2TlsHtU7c+GyXaLj4W+0SC9V6cxL+mz8iHJ/l 17ajX+o2S5+JTZrW3J9puS5aDWtAZLogxJZZ7x+C/go1pmwt3K6zbGiM1f2Uuo8ESog1 6r2woNwCcLWHO88cNoZYUfVvTn8zuVUt7naKaw39gvD6+1b+NKcPgdfQpXMdLDZq6uaT SHGvRWwfknKu/yrksIWqzW0tO377H0OZEqtXd82qgaZN4T97gEfgtefV/K4LF0fj+WKI cYkZy0KkMTtU3Ug272sjmNFRaohDicIVzncWQKb69JOiN2DfnvPcA7tBCJlfqEZvqUYU /lQQ== X-Gm-Message-State: AOJu0Yx6rhNzRnWHsy1wr6gX/STi2zxY0OLZINSWVURQSK9hglNL3Llx XSuwliV3BtAneW32f2IFFS5as7IV4Sm71vZ1WpoM/x2imjKmRD1QMeUkrdf+AyNIomWB1lCoqmi czZu1hrOLRBEEq5rhfFuxtSNCUh6LvqHLMybA X-Google-Smtp-Source: AGHT+IETMLjCNrTRYoa0VeDG6wd6AFck2DJoBNuvFjOIwCUuNl9PVphg7/W5mrUeXG09syiT5/uFJ0c6tpug37IVmNo= X-Received: by 2002:a05:6870:82a9:b0:219:1a50:2973 with SMTP id q41-20020a05687082a900b002191a502973mr663108oae.27.1706849681226; Thu, 01 Feb 2024 20:54:41 -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> In-Reply-To: <8744.1706846710@cvs.openbsd.org> From: Jeff Xu Date: Thu, 1 Feb 2024 20:54:28 -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: 2EEE91C000B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: a85fi7xbnj5g68u1hzjyssjp7mzj9194 X-HE-Tag: 1706849681-357873 X-HE-Meta: U2FsdGVkX1/G/qkYrwfHLHF7Chm6zCW1L8QbqqdlBRare3oW7Z7R02OXXpVunTTIr0WNNDS/JLJHnjiMEQB1gh1iRDtaiKBnhk5nUtXuEXTlR98AflyVtVZvIoIstqmY4Ah7iwvCmNktJwwdzk5RHcoZjwEUBpBganGO74oP3oiX+SR5dkycKpzAlNKK6RXaSVQ/dOXcQN6pDXum3GDE8ZKBVXKZIugiCqxd8Nc/D0hSneZSCHt3pzRnYuqhTVzPvq8PW9UvAZy2p/u6zGLPXmX5lJtY7Qr8vAP4+UxPu1/Bnye1FFD9HsQQl/lr0RXosRc3RC6phOKjeMPRqb88BWAL4IDyvDJ0+g/joEAJmaVmgSCa+e2Mrpqwe3S9vahof2vwCxGL1oXk6QHaq8uQwaMImX5nKjPQfV4ReJyaWb38xWlqKfJnyKQ6UwhC3Qmnrqh05YmDdWfFrsu827ArB6lWc4lvLofosMclCeJU5aBqwFlF0M+q2d9e17GhO5dRk8W/JuH/bXP9AXBNeSY79yNOvnG7quRwL0UhDlpI2lv+vW8W6XZ0CxWmxxiML0o2wgdkcpyaq0k3R7v62GGS2J8jhhI9ucFwjfUh3csFirBlKR/KHCez6FV7UxXYt3cY/MtXcXlxaXUfqPci7KWAmO3L/Yo7Q9EwsxsjuaXs6TQfRiZ4FcCHksuOPzQgxmz/ZevYHGmiVfJvSfIlrF//N0M7UR+y2jt+oQvXAh4neh7ihfjxAuMJZpyoOgpGgWz0Usoeo5E3TRgbFHyMBnAYCJqIrL0+PxT4HgLsc1bwNAwMTOrb02d6nftBbVRdVn8q8Fndh8Xp0uL/nwsRjecVOkZ9VrUUjsIjCknHxhwBSHVVZeP3wA8/r4vpQD6so0l2K7IYLI+7SS5eHEss+/NwT87Nq2if3EPssFW2YHqR8Rq94WRpALm7b1VjaeiwMJfFIWjRgrSajLhUyfZbRWi nCXMFZvh BmIKAwYT7PX2N6l1lXqptneMSHJ8g9MaQ4hSiBNxASedAOu8TNeKf75VUJLZW9ooBp/ifnZUSU8DquSL2fGuCcnVHusqLC3l4wBpMkrmEscFzlDR1Cb8sVj/1MRQQ2MpONecfPFMYzAKAdhqUGGdcNgGKGxJNhGfnniV1/B0OemLqEs/wQdHbepNIeHVgSfUGPUdaB8BsoDuwC4hgv6JZ8W47hY8VQTtdFhoOKclrKkG1tyfTscKmrrOflz8kT1RlI0knwGYActleKnK1lH9VWcn9Ckxlc6Vua5HquSi359tJbtxEBiLhImfzVEQpA57fGhx8JF29mts3RTdjuL6hNbOQWZvYgYnxoG4B0wjG2wmuVfNY4BnOEjOII7PvZENzBhwd 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 8:05=E2=80=AFPM Theo de Raadt = wrote: > > 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 =3D 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 =3D 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 =3D 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 c= orrectly. > > mseal() / mimmutable() add *no new expectation* to a careful programmer, > because they expected to only use it on memory that they *promise will ne= ver > 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 becaus= e > 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. > 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.