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 214FAC47258 for ; Sat, 20 Jan 2024 15:23:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 459436B0071; Sat, 20 Jan 2024 10:23:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 407E76B0074; Sat, 20 Jan 2024 10:23:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CFA66B0075; Sat, 20 Jan 2024 10:23:49 -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 1A51D6B0071 for ; Sat, 20 Jan 2024 10:23:49 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BC2BC40890 for ; Sat, 20 Jan 2024 15:23:48 +0000 (UTC) X-FDA: 81700059336.23.436DF96 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf16.hostedemail.com (Postfix) with ESMTP id 221D3180008 for ; Sat, 20 Jan 2024 15:23:45 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="YicnAI/Z"; dmarc=none; spf=pass (imf16.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705764227; 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=jYnFCb0RIw1+W9PqNb07MXH+OinjBXnSkM44TbrsCm4=; b=aw8fuUiRQdHJpjq3s3lqY2ls7VeCAYLbZlRqyK5/eScZFxGD91WJwCML6utZkNRBDvrtXP E6Gq0JUBmHxV024KxuxAyduM7R6EM7sGMtWHwJTp0FhDQxV8PemqUyFQqqptjG8TBEJMly kcIm2kv012VPnPuZ1TpGnpUKJXdwZ/0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="YicnAI/Z"; dmarc=none; spf=pass (imf16.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705764227; a=rsa-sha256; cv=none; b=pWtqin++IiJfsOU7+QEkJp5x0ZraSztJK6gOcq6BxqBaOYMukqPRAbDVLmqKLAW6NK/KrI qwtRztf0cVVxC8JTnCQ3uAhojTBM4s2Pyww82H5tF4oPMgEhG/EzpHmp/+2SwvwRxUrn9Y 4uoJKoeR+OidtNpzHVZd2OTDqojwYUw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=4OWicOUgr4 L9XOpIC8Mj/UCoeLP2NtOXMnYVddveOY0=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=YicnAI/ZhxukTjaldVdclRZFxTLi4itmr tNLKXPemFgAzsDYBZqrDlhF8hKj9fc6mUckUM/iyBV589tt7LViHcOyf2nf6j2zTEslzh4 vG/l8dNmRi+jECNxd2ZsgriACFzDRwUff3t4dg1Cw9QlDOyECEPJenw35PZGGBPCBdB7BZ RGFWT8c7WkpMUT/foI2hTNF+F9uQu4ruA0PAFajE6OYwpa+NShTfzbhxK/ff0YFRxH5Hek AMyJ71GI47E6Gm24f6LQryBH1ut63FSj3cg1mVvHLyfzq81KQL3IaM9V/vGpnw9rKT1fjE otMZ+r4bE51rZdAr2FONDv+DyVVGw== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 77142d56; Sat, 20 Jan 2024 08:23:44 -0700 (MST) From: "Theo de Raadt" To: Jeff Xu cc: Linus Torvalds , =?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> Comments: In-reply-to Jeff Xu message dated "Thu, 14 Dec 2023 14:52:58 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <45028.1705764224.1@cvs.openbsd.org> Date: Sat, 20 Jan 2024 08:23:44 -0700 Message-ID: <78111.1705764224@cvs.openbsd.org> X-Rspamd-Queue-Id: 221D3180008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: qbrpub3p9cw7ac4s9yo1noihow7pj6so X-HE-Tag: 1705764225-798091 X-HE-Meta: U2FsdGVkX19CjTlfFY41gZuyAuCUiztCC0JLZ8icoZdh5zA9h9ZWIcdcxyG5LF6qxcGu1H3wtT2+hmf6nxIVe94Z/RsMAwpvoTtD/pDrAT2vs90xsj/yKvQmFttjPB1icPfW5q2TV8ibRSMbrZTuaIhp06kokBsw2DhTecVdDmkh91VapajuAWiU/zefXuPl2HWRs0yNVDoUPz3aLEPXGXnPefoy9Pgo4WOC6UIwtb1Kth6NRcirFhvmh6AdKTK+AST+TYzp7WS6fSmZVuz/8L6WsYFZEZZ1Cniqu/2bRxc/0ecYN4DUPv41mZ6L4TXo8Kn0HPgEbW0BmxcHz8gSdoXjWrPXEsAlyKXBTc2JQ4R9aO9mQQT6feNzYKtcNzluWNtguEhJtLw6QhIkfzXp4BXm2nKcrniqvViugBxVzO6PRS+4gThNtkjQqxVHkphVRAZ6kS4ETW5LENbRJ6xXgHPTxE9UALeBK6ad6C9g5LBCG9aPhxsnRCSUmnDCKz9iy/I8RLRZe/RX5smZ2m+UgOGmYH2JiI7lcg8y3/5XkK2MB0ITr3f5bGZJ9uJGCIFi/9eAvvOsxpdeVsfAG3xGxUDi9cKHqewi2fBMUB/m+TkG4w+vio1TdbXluIDp1oH6sQBfE3SwgbTP38VZlQySFizUB1kObSFg8B6Ib8ACkDc8lPPT/nkcaSDZXlGhT/gaDi5SkT4RydJWD2n3bYCImAzoJz7jtt1TVLcDBs8ukLm5zn3JRNXKJb1tbdilzOxFOq6a/+BPPKh4Z/yzC+jKRP9VHv09G/i1KgdwJEOP3BVnbe5QWEmCQw9orj5wqnwSrnj8+KT22PsiPmupnpDDcB8EDmZ3w2Gx55Ldrn9tea5zEnYlj90dsOuW+TAwlL4D9h2g9/M3UMNXEf6CawnoHKUymUdCYx8iP+QV3v+kv5W4kdvvIjRbXQ0Tf2o4SmLvob9Qk+IeujSueShIdpa 6EL9uqDH k35c0k97V15Aar3BvueFK5ef9Q/sO+ZQNlGUI6zLgIkMy6X8DWnch6TboGFAsy1Lq8ybQkRIQYpRdkP1fi/weQf2wJHK/etb7ao7+XxKIqNbPG7JmcUWgQ6o3dzRCaV9MozZF9TdMYKiXXMnNfyrztiK9N13NP45Yn4V73+vHTwkyWfQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Some notes about compatibility between mimmutable(2) and mseal(). This morning, the "RW -> R demotion" code in mimmutable(2) was removed. As described previously, that was a development crutch to solved a problem but we found a better way with a new ELF section which is available at compile time with __attribute__((section(".openbsd.mutable"))). Which works great. I am syncronizing the madvise / msync behaviour further, we will be compatible. I have worried about madvise / msync for a long time, and audited vast amounts of the software ecosystem to come to a conclusion we can be more strict, but I never acted upon it. BTW, on OpenBSD and probably other related BSD operating systems, MADV_DONTNEED is non-destructive. However we have a destructive operation called MADV_FREE. msync() MS_INVALIDATE is also destructive. But all of these operations will now be prohibited, to syncronize the error return value situation. 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 think this remains the blocker which would prevent software from doing #define mimmutable(addr, len) mseal(addr, len, 0)