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 8768DC4332F for ; Thu, 14 Dec 2023 01:32:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63BC78D0087; Wed, 13 Dec 2023 20:32:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D2228D0083; Wed, 13 Dec 2023 20:32:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C47A8D0087; Wed, 13 Dec 2023 20:32:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EBC488D0083 for ; Wed, 13 Dec 2023 20:32:01 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C0398403DB for ; Thu, 14 Dec 2023 01:32:01 +0000 (UTC) X-FDA: 81563697642.26.89BB9FC Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf16.hostedemail.com (Postfix) with ESMTP id AEC12180014 for ; Thu, 14 Dec 2023 01:31:59 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=W0XE3kgH; spf=pass (imf16.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702517519; 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=8Bu41HfL0rPJ5dM5yXqa7CgHUFFdONYm5ZwaUE4WWVI=; b=oCONf0JDzPtdhC9GkTjXZyUOh2AI0CvYSnFu07wX6b+av5u4y3AgKSwTsfChOjEh9EdoFW W4EqpFPTiHHd+70w1ILtRMVJOBDf23Cj821ZqBUKLzPZ2pqS83D9713rWzxLCrfK4+QQJS JcVJzZW/Dei5IfzXr56yM5iuLdLnZLA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702517519; a=rsa-sha256; cv=none; b=ZK7ve6SSnsoL1kIFr1u4BVFTLfZhmAFyAzjrAfTruxYnKThF1wxN8a9bKJyaGvDxnjuCht C31cFzHQiUXXM3fsvOB/9bFeym1/ISO3FSUGZtnfKEBwfTOxMSjm6ZhbRMXlFmP4jrSEQL ZFc6NUyFub8PSRrkVIZiGZ830jxSJVI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=W0XE3kgH; spf=pass (imf16.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-a1f5cb80a91so865257866b.3 for ; Wed, 13 Dec 2023 17:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1702517518; x=1703122318; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8Bu41HfL0rPJ5dM5yXqa7CgHUFFdONYm5ZwaUE4WWVI=; b=W0XE3kgHMFjaFt4bhlhUbnvd/4Tc3aJw5/1jqdk1gYu4fD3IyyHJQC686bZ9h2JzgC e87Hxck8wPZbIQQXQgLT/slJxLphIlGzn3BsMZ0i63lgq281YPqLjem4Y11UBeU/mNFF d2BxXXGtW9X6QfghUakY8z7Y4z1fCjqCwr5p4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702517518; x=1703122318; h=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=8Bu41HfL0rPJ5dM5yXqa7CgHUFFdONYm5ZwaUE4WWVI=; b=uqJiDKmeJYZSO/FrkxPyNzY6QJxui+Q0R7tSvS0uPnWNiMsT4tDD9P0/ks8QTUXeK2 7gmMy+4ZFSWw8WI1kDIB657FO2y4zuTR11AiSPwHlOnGe3eYSMa/jel9b8jfFMoUVHwW L63nFmpB/rnCCMyuUM0n168DNJ7PI/ZscKVI1+4yExoX0ALmoNneFjTf8aw8x32illsk xt4LmGx+OkP+nW15mmR5UPYD6ByJDZI9/qh9+Lhu+jmlhMgc1ge4igr8kIn3RpspjzDb Jg1l/Nqe35CNhiBQiJFP8twKkQMwuNfZyyyjSL26+WxrdQnHY8Ev4UdNqUuDuVpgez0L RVFg== X-Gm-Message-State: AOJu0Yyxjfdos8L+LEfb5axRn0W0AgGZGQ1ZMdooNkHB43OPmFXiFxDl VujgAgKTZzuabkuhyley7c9jdjddWHXX846Iztl2Ad3S X-Google-Smtp-Source: AGHT+IEWTIRebP/1wCksTZqh1504XZll08NJEhwsb2kN6it+z1YmeumCzkHQsFgflK3IuFroRldTOw== X-Received: by 2002:a17:906:142:b0:a23:f37:d175 with SMTP id 2-20020a170906014200b00a230f37d175mr16810ejh.0.1702517518113; Wed, 13 Dec 2023 17:31:58 -0800 (PST) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com. [209.85.208.43]) by smtp.gmail.com with ESMTPSA id tf7-20020a1709078d8700b00a23024ae6e8sm1518427ejc.126.2023.12.13.17.31.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Dec 2023 17:31:57 -0800 (PST) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-55114c073b8so5636711a12.1 for ; Wed, 13 Dec 2023 17:31:57 -0800 (PST) X-Received: by 2002:a50:d592:0:b0:54c:4837:7d1e with SMTP id v18-20020a50d592000000b0054c48377d1emr3150337edi.93.1702517516946; Wed, 13 Dec 2023 17:31:56 -0800 (PST) MIME-Version: 1.0 References: <20231212231706.2680890-1-jeffxu@chromium.org> <20231212231706.2680890-12-jeffxu@chromium.org> In-Reply-To: From: Linus Torvalds Date: Wed, 13 Dec 2023 17:31:39 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v3 11/11] mseal:add documentation To: Jeff Xu Cc: 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, deraadt@openbsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: AEC12180014 X-Rspam-User: X-Stat-Signature: adfj65mr8zbuy31i69am3c6bk81h1yqx X-Rspamd-Server: rspam03 X-HE-Tag: 1702517519-750122 X-HE-Meta: U2FsdGVkX19UlagNr48RZrfKy1ULPYjO9gTNsUwuhATCIeMtWljQd1MS3rmkXczViCpxOYlIS24KtVmtp1jYVftGhKYNNi3IMS2r3Veffj2FfAwRP2i1tRB0APT2rm/b9LhqnsZPJCh5CtVbQcVkMAungZHDpSkzNe+NysrngZX/ME7om0rW13a8zyqWm8uQE1UZMz7533Q0hgf1CQUo7rDboausL83/wa4oj9lveNTVk4hxq9xVozuXSnV6YYkS0pw53w+JRDn+Vgh9PxMsZbYleFEvJXr2aKEU7Jz+ysLoEcqhjnqwZW6Ymee1tmdDMh0ZgW2+Lf1/i2x4eFA/LU6nfjCxJsm+9IO+mlq6OKbHJYG9e+wN24p7QxaYCCRbHwZK8Bjdm9CsOls/y0Yd+o8PXUvCEigsO5oobNs6vo+++xnMS80ZcT0nV/cPXIu6+XUbrd3M3ujrz7/+ijuwjnjWseMzScLu2T6cPxpPgfBCorHo1m3kOactzV+/taUu9WpjpRp39FvgJrbmEgnC6QfEv1/g9A/lQwhcHguJg9ap8GbbdB6V9g0Z2MRjyFPk6RlF7AouwYfl9jGrwrZTIvq/oHFlzUweG9KAu8J1pbEeVk2Rl8GGIYeY1kzJZPPP9OwJLvz8GbScIpMaU/r6FEle0Ig5bhbi3kdlyl9hxaCN9/RPg/ZpkWeybvsWMU7yK7Dek3Y+uqpLhHVnVqiHvW/1uphl9/3buSr031CROrFQYXC/vkjh59NtLxXT7DWGB1lqhdWHmx7CMPpdBuJR6YiZZOaxQP5q/PrV2S7qFb9CGXq7z27JfUJrby7N/c1EWWfJdeThPwodcJwGN1XU4ulWyC0KC+RL4DzUIXIHyu3lHAMUzhh0PI2JD2dpx18PItl1VVCQKrx77SqFmKMKB19gBBgfhrBBngIU3eI5luVMwbrkXrIQ7x6NwmPPDO56rX4SttArFJym+oyCJAJ 9LwQi6+r TowiroaNqLHfGKbetb/4EJF78njfEJpjZKuUazVLgPziEYZtPYX0mx/pMT7+0ex01xMcq6Lfs4D2Zjkjq+x8qWZsVIzywVVY/EWhqPn1UlxVl7dnfwojTz3gsx5/D1hb3CcxLurX6MNqbk5VpPX7U11I422zRT2Lk64g7oWUORWEqlUneckh7nOkf8K2zlVdjAqyiEGLK1zvG94voK1coRJHqB78O4f3ctw3xKYCrs4QlVdjTnzZsBJ2nqyI132i1sPIhyhL2Z+u0BtWjqm7uFFLM4LVQeB+3w9qtXQpF2ZPDwEpGBkDUKBRL5nfoI2ek8+XMygWwXj1bIsQ5kNIFReVfscHFCS0h8zUqVSa6UE+lPEYEeX/7zElJiWlHhENhGqX7d0Fl19d2aErHvNCUypHoymzBb1YaKnC9oMDEugbGZVNv874es7tmKP6otrD9jOxK/wLLpXPbExANWzaH8GymorPHns1q2sqDKEGsfSXivPRQ3DKfiN6V1NRAXnp2vJhw/ZwbPNqNL7Bsni1IdokTRMsOOYx142o0wmWETzY8Hbv0YWNKgoCp+N+qthq6aQMBoUc06pV8CqceY8hDE4s5Pw== 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 Wed, 13 Dec 2023 at 16:36, Jeff Xu wrote: > > > > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is ok"? > > > The MADV_DONTNEED is OK for file-backed mapping. Right. It makes no semantic difference. So there's no point to it. My point was that you added this magic flag for "not ok for RO anon mapping". It's such a *completely* random flag, that I go "that's just crazy random - make sealing _always_ disallow that case". So what I object to in this series is basically random small details that should just eb part of the basic act of sealing. I think sealing should just mean "you can't do any operations that have semantic meaning for the mapping, because it is SEALED". So I think sealing should automatically mean "can't do MADV_DONTNEED on anon memory", because that's basically equivalent to a munmap/remap operation. I also think that sealing should just automatically mean "can't do mprotect any more". And yes, the OpenBSD semantics of "immutable" apparently allowed reducing permissions, but even the openbsd man-page seems to think that was a bug, so we should just not allow it. And the openbsd case seems to be because of how they made certain things immutable by default, which is different from what this mseal() thing is. End result: I'd really like to make the thing conceptually simpler, rather than add all those random (*very* random in case of MADV_DONTNEED) special cases. Is there any actual practical example of why you'd want a half-sealed thing? And no, I didn't read the pdf that was attached. If it can't just be explained in plain language, it's not an explanation. I'd love for "sealed" to be just a single bit in the vm_flags things that we already have. Not a config option. Not some complicated thing that is hard to explain. A simple "I have set up this mapping, you can't change it any more". And if it cannot be that kind of thing, I want to have clear and obvious examples of why it can't be that simple thing. Not a pdf file that describes some google-chrome design. Something down-to-earth and practical (and not a "we might want this in the future" thing either). IOW, what is wrong with "THIS VMA SETUP CANNOT BE CHANGED ANY MORE"? Nothing less, but also nothing more. No random odd bits that need explaining. Linus