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 BDFC8C4332F for ; Thu, 14 Dec 2023 20:14:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 364748D00E5; Thu, 14 Dec 2023 15:14:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 314478D00C7; Thu, 14 Dec 2023 15:14:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1982F8D00E5; Thu, 14 Dec 2023 15:14:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 04FC28D00C7 for ; Thu, 14 Dec 2023 15:14:32 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C0C3CA0D08 for ; Thu, 14 Dec 2023 20:14:31 +0000 (UTC) X-FDA: 81566526342.02.0131913 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf22.hostedemail.com (Postfix) with ESMTP id A95D7C0007 for ; Thu, 14 Dec 2023 20:14:29 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Muc+f+m+; dmarc=none; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.182 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702584869; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BzpbUH5EkrEm9i3H+vtEmgiPJGsbQVnri/dVuua/oQA=; b=0i5NO3TUiRRNN331bLovBqTLGFC0DErFVHfzU904JRFv4R1w/pt9wwF+TMJw2nYue4d4wP I5E9JvVrIY4VOv+Ev9RR0Z6m5jjTdlYpVicam/c0znNrP9bDOug+fr4Kye0cvTPPF1L8Oi is1fS9zT5KC32pZyUaPPt+ldSt5l/U4= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Muc+f+m+; dmarc=none; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.182 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702584869; a=rsa-sha256; cv=none; b=JKzY5S8gR93xxfCwcwyk/n8qJWmFsSMBVe2Qo7z8/oKE/fpK/+fjxTfI7FOSVg9NxfIp+0 vy5FtQAK600W3s/TLX2gnQ720tXOVLIZZIGoOcivmmvl7nS7zd3iDzldXMLELahAH0O6FM 0CIJYPRUwUL/7TZhiDQl6/Jb2KMNAjc= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2c9f559b82cso98461161fa.0 for ; Thu, 14 Dec 2023 12:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1702584867; x=1703189667; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BzpbUH5EkrEm9i3H+vtEmgiPJGsbQVnri/dVuua/oQA=; b=Muc+f+m+7Or6cM6TCkPtwHJ02kQhg5tFE47spy6WNbTPrntae4q8a/FcnTnDQK1Qz3 5vS+lWpYMReCzKfD4kc0xMvYYKgLP5YNW9sx1bOzOQBr9L0HBlUKLDzqJdMifiQls95b snj2mAhQXwZZWCR4Th7caN/8CBgVpgnOjhgmI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702584867; x=1703189667; h=content-transfer-encoding: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=BzpbUH5EkrEm9i3H+vtEmgiPJGsbQVnri/dVuua/oQA=; b=QkWkUmYEQCXxxjEGD8YH7rSge0mfs/iErj6+NR+LolO4NnWwfvFyKk1lSxZ2EMoCh7 TA7v3WHNFLyjJXMuPSMqggI0g/ffw6xZ4XA1o5J3shJYmGZiXRmqCLC+Q51n8fVs7ymT Q+4z6VWr7RwegBefNwdOzMXR2HSqopbDPpE055ejMcrJDz+4qPUDYVKyul9MuWrJuoXC 93cOPJmXd3LbAMPb9jGVKSPNs6BYEqyappSs+QMrDjZAweDZtTvBX5YxENgtYagLvS9F S2KEG5ktX6L63N1eYWwVZS0X/JCBHtb+cQ/Hd7/c86p87SdNyH7BjR2cHIol++saxF+V vCtw== X-Gm-Message-State: AOJu0YxRT7iM5QCAP4MG1E2afJiNzSCQfdJC7YwBi9m9IkEDYSXHvu5T oieHxW/R++B49j2MqPyLirxPRr9y8rXYlmFfruNJQ0HK X-Google-Smtp-Source: AGHT+IGkYxNd16ScFeF3lxLPSW7Fy7LmkAMTAg96s3/rjg/xem/iRVXxmGWxPp1HYX21vWa63a5C7w== X-Received: by 2002:a05:651c:1547:b0:2cc:2075:2f0c with SMTP id y7-20020a05651c154700b002cc20752f0cmr3853130ljp.60.1702584867467; Thu, 14 Dec 2023 12:14:27 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id a40-20020a05651c212800b002ca0a4cd97dsm2213926ljq.125.2023.12.14.12.14.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Dec 2023 12:14:26 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-50e0d1f9fe6so3561619e87.1 for ; Thu, 14 Dec 2023 12:14:26 -0800 (PST) X-Received: by 2002:a2e:b80d:0:b0:2cc:3f14:405d with SMTP id u13-20020a2eb80d000000b002cc3f14405dmr1108832ljo.102.1702584866181; Thu, 14 Dec 2023 12:14:26 -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: Thu, 14 Dec 2023 12:14:09 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v3 11/11] mseal:add documentation To: =?UTF-8?Q?Stephen_R=C3=B6ttger?= Cc: Jeff Xu , jeffxu@chromium.org, 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, deraadt@openbsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A95D7C0007 X-Stat-Signature: ofzzuqua74ttnwy7367w441dxtxm4pua X-Rspam-User: X-HE-Tag: 1702584869-467245 X-HE-Meta: U2FsdGVkX1/GflA73qB6BJCgwQ5PhSLcFmDpU4CmgYuO282TJ4R3h3jX0gEoqFbx00QLuKAY3+1d7p+8palVoABn50aoG6w2c9BMNX+F+dTyY7FFrUwJOHhjsy2e+U1mJVB6j8d73vZ81jFWJg+oPOXIRNpo58yNXrwdcJQk7OfoyiRu25owsIho1gj5njLtUOSu37evVHtX3PJIqGsnLSHO/2A95mgYKDZBN0OaEEwpR4ufkadkpQENuE4M/A2xC6fhf3M2BIiELivdDtTJ9Jkxj8R4RLc3NPGQv0zYqTyVVI6xp+89rSouOXjZXxObeaZ0EoTAB71bfmPNWDYAau5FwxVGvwAY2q5owGza2liKgY+37sp6gjj576OIixrQCMA1aIYX1cLCkJ/X49/Uv3dWMqEdN92mk9Wv7Bn9o4wdkRJBvGRrynTlETJwf10DZVtORQxXatxa3MiBxWaQQxXHTq954b7l92y6ZFqP4aF/uh9F6GKQUPOvy4BvOW8rzZ7ac78cK+XaihFv97j9w0QFycxDVVL1YUCB8BWtAn89C7tsBjiJKL+J2FgwqyNLU6KMeFgwizIKFnhOe/oEJLrT3Ds3jGq8kib4ZAry4XkwP6tTdmIU8B0WTvlVINpPWPwcK/X4tFjUBGOaxJqpYR3YOUTZNK1f+NB+CaWZkB/+KGtupJVBrMzbCCE6iijSQdalPypLnpxjZyeTONtyBmnrlTeUg2TDA6VdOmZmvnqonc56rTkecX1WcTs9HphwJTxyuWMk/vWojIhr9i8PRfBI5e6KTXsQZoOq4nZVVPWV0pCyLHjTaRc97tUwgsJfVwCfzm6+h1rXjQHI7j6Ucx4dDdEdwzl1Ma/bHG5yhV5HowwqhMvH9pSzJynKkOQdizwRuqf2QH4+PQKWCDu78PKKeJicR7en4qkHqKR2pjpE+8HkguwPaeGSYKBVap7jT8N+1FFTKq5urNkeOVD 6edUKpgB it5tiekuJEFU3+QTF3M4Ri8osCs93snhKRGbX5FsAO6XgLyV7Wb7Isy3syl0bZFmuLHk5Vhhh8FI1dVep5P9Pp1HHrp3JnmiXKo5E9Uzf7FXbOPfVia9c6hiH2KoysfXj91eo/EvOn4H9wQ3l2qwmg0DvzhcguFyypv2N+miTCVpuu1xu8I/wlsqdGkost9tcQgftfgboZe7ncvUNAGirJeiYk+vCoB1ukAmCAESHW/kHaXmI9LetODceEiaC6o1Om7Sqy8h8QjpgY+wGTR0eIb7Xp5de390CdAjcBRIDLnFRxMrHFIeSiNlnmfUB+IRuRl5sy2/pJirX9jGwUinT3UVDFFibU5oMi7/BtBDclt0R2JUKDR1LOovHz6qcu2ucTPJufV2Ot52PMxazdDM/4NhXL+0h41NYzBX+1JIVyVJeyZAcDy6BYbrh7OAwgiytr7SbThDaXTWeZ/szG4M/bNBEQMlyRwMs3av1P9bGnkDugEPiX80/xAND5MKPDj/li1TsL6bJMG2sxnSs66OxQbEPYcHwcLOxQ3VlwIpoaW0KJVZB+0D/sUOmjA+bB4qM7BwhN7jiffqquPHF7GJn1/YBBg== 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 Thu, 14 Dec 2023 at 10:07, Stephen R=C3=B6ttger w= rote: > > AIUI, the madvise(DONTNEED) should effectively only change the content of > anonymous pages, i.e. it's similar to a memset(0) in that case. That's wh= y we > added this special case: if you want to madvise(DONTNEED) an anonymous pa= ge, > you should have write permissions to the page. Hmm. I actually would be happier if we just made that change in general. Maybe even without sealing, but I agree that it *definitely* makes sense in general as a sealing thing. IOW, just saying "madvise(DONTNEED) needs write permissions to an anonymous mapping when se= aled" makes 100% sense to me. Having a separate _flag_ to give sensible semantics is just odd. IOW, what I really want is exactly that "sensible semantics, not random fla= gs". Particularly for new system calls with fairly specialized use, I think it's very important that the semantics are sensible on a conceptual level, and that we do not add system calls that are based on "random implementation issue of the day". Yes, yes, then as we have to maintain things long-term, and we hit some compatibility issue, at *THAT* point we'll end up facing nasty "we had an implementation that had these semantics in practice, so now we're stuck with it", but when introducing a new system call, let's try really hard to start off from those kinds of random things. Wouldn't it be lovely if we can just come up with a sane set of "this is what it means to seal a vma", and enumerate those, and make those sane conceptual rules be the initial definition. By all means have a "flags" argument for future cases when we figure out there was something wrong or the notion needed to be extended, but if we already *start* with random extensions, I feel there's something wrong with the whole concept. So I would really wish for the first version of mseal(start, len, flags); to have "flags=3D0" be the one and only case we actually handle initially, and only add a single PROT_SEAL flag to mmap() that says "create this mapping already pre-sealed". Strive very hard to make sealing be a single VM_SEALED flag in the vma->vm_flags that we already have, just admit that none of this matters on 32-bit architectures, so that VM_SEALED can just use one of the high flags that we have several free of (and that pkeys already depends on), and make this a standard feature with no #ifdef's. Can chrome live with that? And what would the required semantics be? I'll start the list: - you can't unmap or remap in any way (including over-mapping) - you can't change protections (but with architecture support like pkey, you can obviously change the protections indirectly with PKRU etc) - you can't do VM operations that change data without the area being writable (so the DONTNEED case - maybe there are others) - anything else? Wouldn't it be lovely to have just a single notion of sealing that is well-documented and makes sense, and doesn't require people to worry about odd special cases? And yes, we'd have the 'flags' argument for future special cases, and hope really hard that it's never needed. Linus