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 0CD78C47258 for ; Sat, 20 Jan 2024 16:59:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 543BF6B0074; Sat, 20 Jan 2024 11:59:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F4776B0075; Sat, 20 Jan 2024 11:59:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E3186B0078; Sat, 20 Jan 2024 11:59:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2D45B6B0074 for ; Sat, 20 Jan 2024 11:59:11 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F0C3BC0806 for ; Sat, 20 Jan 2024 16:59:10 +0000 (UTC) X-FDA: 81700299660.03.30D22E2 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf21.hostedemail.com (Postfix) with ESMTP id 3F54F1C0012 for ; Sat, 20 Jan 2024 16:59:09 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=ZBdxT4sm; spf=pass (imf21.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=1705769949; 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=qx9eQ5fnQoaWQUKfsP8a3kLDK/cEgK1Lql6Lp/Jy1TI=; b=Hu4V/PeAW82eVJ1NxvrlieOy85wTGzNQHM3y1MtjDQ2e01oOTI8mU1pKGK4OfO+6VkvP/H Q2vCDPo73N9fDrXcrMPg8/7SettlL+zC6LQVGW11TSJvDXxDbyxouw6aIeBbb8E9tuuhPN lXUh55GGH9UW0XYf/mV9W366IghHau8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705769949; a=rsa-sha256; cv=none; b=7GosGVa/vNK52I9vvws5jQH95g2//NQeAbCjBwPgWUJ+dlgBaoaCsA6Ug53JyWnCT8jY0i 2TdDT8aaaNajZeX6T7AyGG13Fkpw5w2ca8ju9w5EDoo3WH7H8MoMqgAWv9GyMAfC6glfVt DdGJ6Dq7h600SaFkCeSW7exAdUDyPU4= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=ZBdxT4sm; spf=pass (imf21.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=1oROoR0nKl b6+UFwWsH51B+hCVBgpFqtLuP0ReDclek=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=ZBdxT4smVvYsJtQ1Adk4k08ujFn06ssfD pzMIYPOjC1tKV3j2+bVsOnBxn71Lxc2vl0zUnMnRcHB+Cds96zGYxDU0E4aUXN41+AY2q5 rBMkkB9O5IWT+3RVaYTVl3SG3GtpfVaBsPRgW97s9brjJ5pRhmQX1fkG4PZgvhkIzW4NmU v3UH0nED5kIcWYnfDISQhINcSMbfynFn0WvMENDOiInSGX5ETzZmCKRaUPOUnGVXOeRspz WfpZowfZ5Lo0CY+OhlDlkM8aLZr3AsmioRInyAIBhiT6bk4ptR0pk5mnJTaIwlIJvmVw8H 2+b79CKFwG3aw6ZKdpw/uAe9mTINg== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id cc644406; Sat, 20 Jan 2024 09:59:07 -0700 (MST) From: "Theo de Raadt" To: Linus Torvalds cc: Jeff Xu , =?UTF-8?Q?Stephen_R=C3=B6ttger?= , Jeff Xu , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, willy@infradead.org, gregkh@linuxfoundation.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: [RFC PATCH v3 11/11] mseal:add documentation In-reply-to: References: <20231212231706.2680890-1-jeffxu@chromium.org> <20231212231706.2680890-12-jeffxu@chromium.org> <78111.1705764224@cvs.openbsd.org> Comments: In-reply-to Linus Torvalds message dated "Sat, 20 Jan 2024 08:40:09 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62327.1705769947.1@cvs.openbsd.org> Date: Sat, 20 Jan 2024 09:59:07 -0700 Message-ID: <80897.1705769947@cvs.openbsd.org> X-Stat-Signature: gpnw1t7gm1bqd9xjx6d4fkutgckf6enw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3F54F1C0012 X-Rspam-User: X-HE-Tag: 1705769949-39327 X-HE-Meta: U2FsdGVkX1/UKVDEobmPnoyBl/y6T6fNWaK0nxh1OP5rqrArK/QZlnMP1Zp6m/BXiwyJtq82+bMdVtvjq/chQDshXS7wCxYl6XMzS2m0I6oOygdxK8gePbSI2dgZC5tF0ME5MSxd17TwPvmjdiDLsHGQsYbIVfcLikGng/tcjxb8OMr7r8H+7vzP73Q0JK/YYSku9xPWF4PGjDHH5/H2z/LK26akIaesT/5PTcqd+tk0pOctWSEWFoQTFBulyXkDDfxxbuBAeICSzL3RySk/zDDarejLhnwbp8IzYATamdP+jxJKuIJe+QZLAD59IjajjOGfnaJedtlz3ZyM7As5RTlYcJM/AtzRWCysNizBa9xKcJwVC9vYVicfGgODDXHBBRaL7PMq6gO6InSS9ZM25oiFFL9hK2okEhbS/V4JBSziLuhz8Ja+N+fk4L3LFT28nDZlIRAxr5h/MgwFpspq0XzB/Nm2uDjZa/lMORxMyiSIhGdrXRHc39lWeVpAymvOAQxsvTCtRWNMp4ykpOzfYdcuAxpChGH+MxUf2bVjdb90J4U/5NobvITrFDhWj3lw6SzD0yDZP2I4z2bZkkiB72xSrES6y273iOsaBGOXcUQd6byk0CDb9vMatyCTODJ+gOYyzK6QgXwO25Xayjff4NhVkAdj5QrBcwotFn2gYFgjbZlTndHo5nOqROL/d3LJGrR+c27zTUkSKJE1hVQFMz1I19zjZkoi/Q4ct7cFyU605ZyJR6jI75ICz4QCsBqag+DGr6SepTt6QQ0cDdXDoP/Wou7QobuPPW9iLv1fzFCXBdT8WxFaDPSVKp1e0hFfhkc4ceUbdJ/FX1hIhsOUZ7cN5MrDwBl0/mEXDSkruzoDxXz07PCK7rklX2ZvWUPhnv5nGW7kcwc5odcEIckadf/hCwDFEBRFuSDu12pZfvL5C4XKqPdsvDSrNWfKV23BfqrflGL8jQ5igLAHIW8 yjDxdiDa Xwb7al3oA/BgB1Lm5hs7f0FyDyTr5A7dsmv6RIREqUdZolkAuQLIscskjDW+3CA4I6B4dfESONWPZ804Fcy+VNElhzDyabzafTSP+cvIiJ07oDhzBI2xut4f/IiwZlfqkbcVejotIvLp3aKR41HNQBCMAJkcX2L9/mw5sExE87/4dA+1fwTMQPsZzWXSw1aN/YEp5MLQe5Z8qd/olDyr6+EedK2s5TcOW2H/9f4OotPE5yrrwCqPXihFTKA8nx9t0NirEdif8pc8R1B0mFxRwsGUO8rznBG928Pz+OAUMwJ88zEHn29GWorczhTm4O3H2uop70CkMZk0Qtjk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000040, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Linus Torvalds wrote: > On Sat, 20 Jan 2024 at 07:23, Theo de Raadt wrote: > > > > There is an one large difference remainig between mimmutable() and mseal(), > > which is how other system calls behave. > > > > We return EPERM for failures in all the system calls that fail upon > > immutable memory (since Oct 2022). > > > > You are returning EACESS. > > > > Before it is too late, do you want to reconsider that return value, or > > do you have a justification for the choice? > > I don't think there's any real reason for the difference. > > Jeff - mind changing the EACESS to EPERM, and we'll have something > that is more-or-less compatible between Linux and OpenBSD? (I tried to remember why I chose EPERM, replaying the view from the German castle during kernel compiles...) In mmap, EACCESS already means something. [EACCES] The flag PROT_READ was specified as part of the prot parameter and fd was not open for reading. The flags MAP_SHARED and PROT_WRITE were specified as part of the flags and prot parameters and fd was not open for writing. In mprotect, the situation is similar [EACCES] The process does not have sufficient access to the underlying memory object to provide the requested protection. immutable isn't an aspect of the underlying object, but an aspect of the mapping. Anyways, it is common for one errno value to have multiple causes. But this error-aliasing can make it harder to figure things out when studying a "system call trace" a program, and I strongly believe in keeping systems are simple as possible. For all the memory mapping control operations, EPERM was available and unambiguous.