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 5C82BC4332F for ; Thu, 14 Dec 2023 01:09:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E87C26B04A3; Wed, 13 Dec 2023 20:09:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E37F66B04A4; Wed, 13 Dec 2023 20:09:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD8B36B04A5; Wed, 13 Dec 2023 20:09:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BB5B46B04A3 for ; Wed, 13 Dec 2023 20:09:42 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 920CA140BB2 for ; Thu, 14 Dec 2023 01:09:42 +0000 (UTC) X-FDA: 81563641404.19.C3DDB89 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf13.hostedemail.com (Postfix) with ESMTP id 3A41920011 for ; Thu, 14 Dec 2023 01:09:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=f8EJnL1p; dmarc=none; spf=pass (imf13.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=1702516181; 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=E8HsOAIis8K7UX70/GaYD9X9pwaXT+XIttZkvbGogmo=; b=3QbfokbtIcombU0jtUk/BxHaSjDP/xzKkLXKYJ2X/7T2OaLkuetre6dJXqSS1dAeH0oJZ1 8FhQpv1zgRGn9wFZE9DlkrBi/PkmQ/WOZa2W9YLpPYMJxvdhSfjxFt/hY2jlDzGfOOyVTi UDnrt42ZWVDxEPyO849cBAN00TXYbx8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=f8EJnL1p; dmarc=none; spf=pass (imf13.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=1702516181; a=rsa-sha256; cv=none; b=wLQAc6vEhSkYhzu/XpiXQuDBNkgNPIM34of15K59ErAzR6bhL2oEglQ7yIjmDw2A4o6trb WatkFm7WKxZGhzDiBIiaF5kMhce6afmu6tj17Mvj3+mpILulu6ZGv1p1c1XJ9XVTzpnza1 rlbt6ISRNdMe6AfIWUro9QZpUdMPVtg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=whGKbpn2mK dixz+7VYNABz/psNG/LtxK3IfpFNItFm0=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=f8EJnL1pM686HWnsDZ2MM+QERZ5fn5hkB jS2UEz9O0HQ3CMCPdqYpqvgemPzK/k3sYnnneBkmxRB2mwcLGksMDxQUepWmAMwQXOZWow UnukNeZTT7/fyuRPG/vc6WY0665nhjTCzO3swQTttAdyYfO+ykooxNcn7hq9Jif7k877Zg NzTQhv5fS8QmQ1kODqjycmd0+HMFk6tqn25KWRfbvwutgEQ8WduyIIyF5VupOqoooaYpMm PcMkj3UvHwRNaSIbk8cWjCxE4kuZUOGfwXj+Pof8/c4Lkak7sNxM8KgYhPRr+6RT7pTSqL cfcNtU11WwqUAXQZzouEGgjK2Ln1A== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 3f9af318; Wed, 13 Dec 2023 18:09:38 -0700 (MST) From: "Theo de Raadt" To: Jeff Xu cc: Linus Torvalds , jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@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 "Wed, 13 Dec 2023 16:35:26 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <45779.1702516178.1@cvs.openbsd.org> Date: Wed, 13 Dec 2023 18:09:38 -0700 Message-ID: <58421.1702516178@cvs.openbsd.org> X-Rspam-User: X-Stat-Signature: 1skhymbqrc3kcktj3ytapkirgdtoebfs X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3A41920011 X-HE-Tag: 1702516180-594579 X-HE-Meta: U2FsdGVkX19STnnVU14YU+vf8KxbHRaVQ2dDSF0GeT2uI5h6N6SO3F5vWP4ETi1Px3Aho4Ds29V7NBVh50yTznLy7NPQOhbw2qo9I0reI75LN3NBACK929PITMRVR43jFGItZ8Ofb2mwW2Tc43uzkfGx/zv73k7Bx++7yVz9m97hMbebaQbiG3AdxVoz/IOjueFx3zQDJewMdkWHsL5abrarFP7f9DlNMA4Q0HUwt3yEhJmTncyYmWMubRlZkpF7BoGNCWmL35L6AVNY+CXntzEAWlmFWcmLNw+VDMHd8KdolNh3zdNXlvlOQF6PaoVonfyf+nGEVfCBAT+CjDzxfaXppLSe4PkjrjhgNVbxDnb4HhZ0Xvsiw3PyQlKFImimgY0NAQmgj6NlVSWUoOs+vqUnpSlCsz1Pxxkzzs1heynum2e2Crl0O6q/TE/BQSWGCeMQniBZHxNaFZCYxiSYOXiu2v38V1gO4dUlknTW9hktNNKYhWtA0R+A9o0QaeIDrrMts3f/TX64VNeftfmMwkpJM5U7k7k2QS9ygizft6Wb9zPlqhWJi0JNkLEizDG1UvqltTSy4lnu3VCxXe/h5v+1Lcho2m9UWEZmTlNIcOhXzf2lae10tSsrzwDCGZcD7xhZF1Cf2X/y5fdASOlLPnJYTslaDWkGjhwrtE0n3exJhc1ex9uzGReT0L7+FD3VUZpg+m+XYs793zTZIl27OoAh+wWrC2nZbkelS9SLdSAzniNoZeWFNHi2LfU181YFU2fMbjKEs3w9bNdLabfDsjCb/YkJ3nhbk9aCpniwe74quhNyVLqkItBU3RgaOMVoNN7AaFH2YKhWAweXeDiK++coqcTLy+4sbGHHoQHkXNWgtIqQmrCEc8c7iiQ+F/lO8pAbFW9YrJ0DZkAOcV1vIxeq5JZP5sua/fxvWtqaLeNjOaiMLAt+KPFwgk69ROQEL56g0geWnunWH+riX6H 4L1bE/Sg tunIbgLI46XvClAV2sERF7IqbaxM5A9mTZkpwTUNZL1QfD1J/OMyMWwcqppC9rP+2i3eJgBoWCVrdirpOZPW4oF10tArNburUWBfIp4Eb8mtqbJirxbPiyohF7IeloXuOrJyPHVyrOCkt5/QqxKHokJ3BijHNmZEPnhgGoAmUVIxh0e2bmg7W7ClCQTJebxpXsFR9mgnGQtIX4AljODnNkIZSYHjzVrJ36yvMMFJ+ISbjhjQ= 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: > > Or when would you *ever* say "seal this area, but mprotect()" is ok. > > > The fact that openBSD allows RW=>RO transaction, as in its man page [2] > > " At present, mprotect(2) may reduce permissions on immutable pages > marked PROT_READ | PROT_WRITE to the less permissive PROT_READ." Let me explain this. We encountered two places that needed this less-permission-transition. Both of these problems were found in either .data or bss, which the kernel makes immutable by default. The OpenBSD kernel makes those regions immutable BY DEFAULT, and there is no way to turn that off. One was in our libc malloc, which after initialization, wants to protect a control data structure from being written in the future. The other was in chrome v8, for the v8_flags variable, this is similarily mprotected to less permission after initialization to avoid tampering (because it's an amazing relative-address located control gadget). We introduced a different mechanism to solve these problem. So we added a new ELF section which annotates objects you need to be MUTABLE. If these are .data or .bss, they are placed in the MUTABLE region annotated with the following Program Header: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align OPENBSD_MUTABLE 0x0e9000 0x00000000000ec000 0x00000000000ec000 0x001000 0x001000 RW 0x1000 associated with this Section Header [20] .openbsd.mutable PROGBITS 00000000000ec000 0e9000 001000 00 WA 0 0 4096 (It is vaguely similar to RELRO). You can place objects there using the a compiler __attribute__((section declaration, like this example from our libc/malloc.c code static union { struct malloc_readonly mopts; u_char _pad[MALLOC_PAGESIZE]; } malloc_readonly __attribute__((aligned(MALLOC_PAGESIZE))) __attribute__((section(".openbsd.mutable"))); During startup the code can set the protection and then the immutability of the object correctly. Since we have no purpose left for this permission reduction semantic upon immutable mappings, we may be deleting that behaviour in the future. I wrote that code, because I needed it to make progress with some difficult pieces of code. But we found a better way.