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 BD80CC4828D for ; Thu, 1 Feb 2024 22:24:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 17A7C6B0075; Thu, 1 Feb 2024 17:24:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 12BD86B0078; Thu, 1 Feb 2024 17:24:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F34566B007B; Thu, 1 Feb 2024 17:24:43 -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 DE23E6B0075 for ; Thu, 1 Feb 2024 17:24:43 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4ADE640498 for ; Thu, 1 Feb 2024 22:24:43 +0000 (UTC) X-FDA: 81744665646.14.EEDFC28 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf02.hostedemail.com (Postfix) with ESMTP id 596E080018 for ; Thu, 1 Feb 2024 22:24:41 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="mQtvNz/2"; spf=pass (imf02.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=1706826281; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cul71sfMOTVRfkPdXuilbGcf+msfprTWkvxbXRCM2mE=; b=rJAOTnQrXTy6bCkiHwUJNlkU6CRPyFomH0w/SpghG8UbV5345bZbOLXLIBwu3JBhthuv1q TUUN4dIKh2gB1FZ4RHCh/CSuiGNv793tpzLoabtNkzaFe3uN7/HtP1V8Zhv514OiBX0+xa iFWrjnWitL15YVq6H1thbUqPDBaCyCc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706826281; a=rsa-sha256; cv=none; b=0J0lhjl1leuyexRy8nseqEfOn6LLX5z4Y9As7QVgUjcauAB50hYjrDZkUAv6vlQrPy+xtp mbq6LHwCiybBQtDBdVP/7u5wrfczXUOOf4E+3KzkHsndwNxLE8WCGe7XTqZobSSyMg09Xm 0cFQyZfqmSJdRUenK0oULNhCXwgmVkg= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="mQtvNz/2"; spf=pass (imf02.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=V+pgcDkLpt PWj1ZsXMjO/YpMP2pXDVV5rTLspffLxF0=; h=date:references:in-reply-to: subject:to:from; d=openbsd.org; b=mQtvNz/2l4bObNXPQCEXRYkfvH+3kuXrFbmQ 5ccm3cu6lDooMGrgLBn1n2RoQ/QYXvQOUNcLRqrZ1kWyTib3gOGK7YIOBFvIxj+aEJ2Can NzFcAvwgTKE5s2p15GrjKIZSJ5E83Qw4JU2rm21yzOxjmlYmkAW7Vw82dIzpUc8IJ2Mn+N zNbdkKOgBXPLJirZSmKXDwXvoKqt5rpDUHQQ7Q9PX8zVxzrTKL1QzXP4xl2DC0D5KuGUke IwafprPJe305G7qvBX7SCXPSP2/jXehf8l2taZ6+A2C7tIOAj8YjRxhVXYXwUELwobIUL6 AbgXvaGSEL3HyNiF7p9jTivZtg== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 90ae0d7d; Thu, 1 Feb 2024 15:24:40 -0700 (MST) From: "Theo de Raadt" To: "Liam R. Howlett" , Jeff Xu , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, rdunlap@infradead.org, jeffxu@google.com, 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 Mail-Followup-To: "Liam R. Howlett" , Jeff Xu , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, rdunlap@infradead.org, jeffxu@google.com, 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: <20240201204512.ht3e33yj77kkxi4q@revolver> References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> Comments: In-reply-to "Liam R. Howlett" message dated "Thu, 01 Feb 2024 15:45:12 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <85538.1706826280.1@cvs.openbsd.org> Date: Thu, 01 Feb 2024 15:24:40 -0700 Message-ID: <60731.1706826280@cvs.openbsd.org> X-Stat-Signature: qzxjmp7rp6q53b6wzpjg41tbhdtwnmse X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 596E080018 X-Rspam-User: X-HE-Tag: 1706826281-649569 X-HE-Meta: U2FsdGVkX19WCIRVt6GUhX2+HzcRt9hfb5YwT3SNW6Vv9iLlT6kicEJgwaRRNKkN1DarCp0SJLOiS/Dqel9W7FxppfCte5EgcEtief8TPump99XGbpoN7XHKuZ4Db0wzegCsBCZxHvamSEm1ypp+IuQfgfES3a8hplTV9HErTzhhOhL7oXVf1zOX8kZRdtgvLTRUg21PXdH9Rj9Xa6Hq4eV+RIod3jj4BjE81GEirHr4bKAL4eEP2EmlDPRvRV0RwW0SC0ucmYCePDvPd1b0mMqb4xcrMtc++3J2N7zX7QxbYpXl9zEu8VSwC4xfqRc3Ls2FRI+EULe61nO/cvkRSGPGW5uGPwqCGB0IKHRaXgfH9Mmw+VGSBlgI1HKsks0ljoQ7b5WWLoX2szqAWMG8PEPcECfI8pAeGHmBb2d5OUwTH+RqvakXeOf7uXgkfWRUyv6EJK7PmXFtHP/xdBkAwL2Ar2cV/vA5whp4TSy4RGFeyLBVCuwYM8YjgcE9U7lE736apt63wmrlIX47uZMvhHlMS+9HXrEDS38voUAINQQ9GT7qkTiLkWsnWgxhYeD8bja2gDTFhZv+xKC/0dbOHvaAhHobx35oX/J/d5dFpJxpgyB6Qzx1sK0QxoZmmC9yXJL0sRUo+qppOGrH6sjLrjiI99TkeIYEfSFL5oeFaxQO0wvK+GhxXKW1eOVYojnP1W/2JLJa2wB1Sa2ISaUiaCyWDsuVThwddiNtXY/1tEZvQHmvjXjRkKrRQNCxkrNnx0u8uLq4omiQKNiWmNXTf77hOMHcpPXhXRxcoo/SEM6O7+nnhyfwqgSpjDBOsyJl+GIPii4SvMu2+6O8PfRc15CsQj6AWGcRSs8iNI/CstCAHsye32sxWNVjrTgxaH6/hHXBByOuRLbzz44DmfmVcmoBnjPSo/F53+XU93HzGjrUzynd5Xzn2gmZ+t9nr5QsuTRIVkCG5VLl3JBtJgj 1JQLlvXz ueCV5q05sM1vQaFZpv95gt+btweHAptf0fe/91oz/9ThZcIudgEQY/R0JdKm7M90KKZl+ej+m3MjACkC5AOLmvHj13F0MMx+qaJ9rXaQfgeY9aBT+QieVgQY7AwN4jHFnTGhB3VUI3H+T+n/6gmROouTkubTyD2Sg9LHarfg7nMuQd2wvejSsxHWnMv83IvAtbme0gEcj9DjS1mfZVLpIko8HQw== 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: There is another problem with adding PROT_SEAL to the mprotect() call. What are the precise semantics? If one reviews how mprotect() behaves, it is quickly clear that it is very sloppy specification. We spent quite a bit of effort making our manual page as clear as possible to the most it gaurantees, in the standard, and in all the various Unix: Not all implementations will guarantee protection on a page basis; the granularity of protection changes may be as large as an entire region. Nor will all implementations guarantee to give exactly the requested permissions; more permissions may be granted than requested by prot. However, if PROT_WRITE was not specified then the page will not be writable. Anything else is different. That is the specification in case of PROT_READ, PROT_WRITE, and PROT_EXEC. What happens if you add additional PROT_* flags? Does mprotect still behave just as sloppy (as specified)? Or it now return an error partway through an operation? When it returns the error, does it skip doing the work on the remaining region? Or does it skip doing any protection operation at all? (That means the code has to do two passes over the region; first one checks if it may proceed, second pass performs the change. I think I've reat PROT_SEAL was supposed to try to do things as one pass; is that actually possible without requiring a second pass in the kernel? To wit, do these two sequences have _exactly_ the same behaviour in all cases that we can think of - unmapped sub-regions - sealed sub-regions - and who knows what else mprotect() may encounter a) mprotect(addr, len, PROT_READ); mseal(addr, len, 0); b) mprotect(addr, len, PROT_READ | PROT_SEAL); Are they the same, or are they different? Here's what I think: mprotect() behaves quite differently if you add the PROT_SEAL flag, but I can't quite tell precisely what happens because I don't understand the linux vm system enough. (As an outsider, I have glanced at the new PROT_MTE flag changes; that one seem to just "set a flag where possible", rather than performing an action which could result in an error, and seems to not have this problem). As an outsider, Linux development is really strange: Two sub-features are being pushed very hard, and the primary developer doesn't have code which uses either of them. And once it goes in, it cannot be changed. It's very different from my world, where the absolutely minimal interface was written to apply to a whole operating system plus 10,000+ applications, and then took months of testing before it was approved for inclusion. And if it was subtly wrong, we would be able to change it.