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 E6613C28B28 for ; Wed, 12 Mar 2025 15:28:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C1ED280003; Wed, 12 Mar 2025 11:28:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1722D280001; Wed, 12 Mar 2025 11:28:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 039AA280003; Wed, 12 Mar 2025 11:28:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D9268280001 for ; Wed, 12 Mar 2025 11:28:03 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D3096812D9 for ; Wed, 12 Mar 2025 15:28:03 +0000 (UTC) X-FDA: 83213279646.25.8A13BFA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 1BF5C100012 for ; Wed, 12 Mar 2025 15:28:01 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cu6VBmQz; spf=pass (imf14.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741793282; 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=9SQ6MwmJ19FUCPNwdehMATOlSXF6Gkwsdpfa8c1tTt8=; b=iRoYRqvZW/Nd+PnsavcEG5BV/t9iedeww7LQ0o6YZzjr4HF5r5sj1ievyqjs/1ya/MEjP7 jIwazJz1a+fkJT3yVEGcpjGDbsemKvrHj1oS9GhQBEWOFoqfi100JBlir/ZMp44A6PVIac HIyNSjz8QoLVdhPvEyQf8p1HJgJDWv0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cu6VBmQz; spf=pass (imf14.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741793282; a=rsa-sha256; cv=none; b=BwdSclrR5S8dloidGe1qvLwqTL+gWwbYcbmRMiLP3ZGoBRvOW4eUCUSJ3AQHx3fPRZNfv6 aILjz8iXKjDuRjwgtk63z1VF5aXW3c7uEnm51oQZgwP8vuK05avzMGOJUg0xktM4vFmFJU SIrz0xFEz72EBlI/XuyiMZi2sk0Sts8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7528F5C4DA1; Wed, 12 Mar 2025 15:25:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1AD8C4CEDD; Wed, 12 Mar 2025 15:28:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741793280; bh=knZ+0Ki91XfMnnNBjvRtQYxda8bcVvsvaE8A+MwLFJY=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=cu6VBmQz26ajpPamenktK8g8GX/gSYoIYgTmN5l+RfYdCJzKwBt7BzNIJbL84ItlK Jvl+nOahTBFgn9Ui++4b5xOD4aRvGcFb7GW7QP734hYNxsFkvRyBF0wlZs2Kb33SKC UklngiqgjbOxKFocLsWxCeQ/wrU8F67OzDIQ+X6Szr6EXP+9EB+dVIyPBFbcGdYrBj X6udwysXh1kU/fI1E0R05tiF6xDiWGbv5AMAE1EiGtklHkYzZHfwJ1UL9G3tnW7yrZ 8ZdjlrgSMmdgKqGeChgl5Zxv8Uxisp7LGJX4oZ8hirmU4+Vm8TyeMQW6y9QDNZQURI wAoG3IGVVQuvw== Date: Wed, 12 Mar 2025 08:27:57 -0700 From: Kees Cook To: Lorenzo Stoakes , jeffxu@chromium.org CC: akpm@linux-foundation.org, vbabka@suse.cz, Liam.Howlett@oracle.com, broonie@kernel.org, skhan@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, keescook@chromium.org, pedro.falcato@gmail.com, rdunlap@infradead.org, jannh@google.com Subject: Re: [RFC PATCH v1 2/2] mseal: allow noop mprotect User-Agent: K-9 Mail for Android In-Reply-To: References: <20250312002117.2556240-1-jeffxu@google.com> <20250312002117.2556240-3-jeffxu@google.com> Message-ID: <64B6294F-B059-4744-8548-89D7B519BE72@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 1BF5C100012 X-Rspamd-Server: rspam08 X-Stat-Signature: 4bc3az7ardrzh6phjsu6w5icc4f7rqc1 X-HE-Tag: 1741793281-481501 X-HE-Meta: U2FsdGVkX1+PHyOsMH0NNdBzgYpLgOj3TgmUJ8++KLozZe8j6WQuMgm9zsT7LbIgkGAUcdhTDnJAHm9exVy9EYWQCXdSuS7IHlhFi1XV7uIFtJtcKMZ/+kvEZU5FeSAA9FCjf1TrSS4QjgSRxmj7K+4za8JB/sJ6t5Bu6TGgmoOe1XOb3u6xvpT+3wPHBfN83T9uwbXxpfHyjr78oI0teYcMAtvZSZ1Id39ceD1dsxdnnsZGu4AQrMNZHTlRTDnartZZQt5tzGAZF6o97wufubegtp4B9gyg5pBJhFwHJQWRb3m1S3IaERhBxHPiJcQPsUrn5P7Et6K+glaq8M1MiAP9nfswrf6eonG63PCtBH7v7d1sTW/AjdqOtEIH5XGHi2InECmnOuo0TbnLVtn6edJqAETGf23U1YXie5lmecm2ttRsdkzlNP8XSsoluuayAzAATthPZ/Y0gaZO0imi1nDtLJji4TYkWN5JaIs5b74ZYuYy1s79f+f6YIuQv6FymAJkkB7/4LMXpFicwroeBbW3e4VFnAZwSzP1B2ADUGN+bH2wiSSKVhEw+ZsY3zV9SisDjvqQ2lLsWJ3o3NR+l1ZLso2AsullcXXSkViT0zuQ0Zh3KFV/ZiNwpQAt7v+PLADfK80obU0qqYLMgoHhGH/8l6w0SDJj9/B/6SrMRsForwcpXYyyxMWPvDwn25lC9HD7KJ20fG1pisTo45oeVAPTP3DYZlV1QS3Wrxegz6LHPAjY3Mze+bpfQRWQUmPT61gW2uw9+3+BqizuVHDb97Jpg0lN/D8KNy7bBsppvMfF84KQBjQD1ZBlYADcyP58EHlsQmKdyhMCDX7QEefBjVmozY+2PtLSvfC7FZJtSMgGPAoSfg9+yvAIO/HOVCj1NUl11Yv0QUhGD5v9MgrDcSxbSIuCWSjY52JOWi1BDHkayFZV9uOnNKdJF3vcOri9LS3XXg4/u8G3SSNDwLm Q2uekd2L bUFBtTwuj6ec+JwK39ry8N9FB7C1SU6X+/Vs2DxQUc+fEKv7gmlT/HZX2WrDTHXFXB2OfCY/fejDcMetSo3a1a1zGkHObocu1H9/yy839iyq4uqepIe/7wEt5e1YlQ8tGzk8Igltzl93JcZsI8DuTRDO7Ecb8aXyErE7H3x00+7xVy+pwlthaC7ICI5+BGF7tU1IhPB7nENrHQUxP5MhwdOamDF9uQ9WNgFgHvKA2EuecZSEe1jWV+DssKLBZtPQDKW1ihDRmWIiQnQeHijaczzkrvyR8wIRDbbWc8+8NSd5c4zD+CIY1j8KouBa731pAhdpM84GMbVsVC9k/HC9mvH+042BhBfKi17dwIxmL0yeLCzXIXIKZVYyH053S1DRNbaLw 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 March 12, 2025 6:49:39 AM PDT, Lorenzo Stoakes wrote: >On Wed, Mar 12, 2025 at 12:21:17AM +0000, jeffxu@chromium=2Eorg wrote: >> From: Jeff Xu >> >> Initially, when mseal was introduced in 6=2E10, semantically, when a VM= A >> within the specified address range is sealed, the mprotect will be reje= cted, >> leaving all of VMA unmodified=2E However, adding an extra loop to check= the mseal >> flag for every VMA slows things down a bit, therefore in 6=2E12, this i= ssue was >> solved by removing can_modify_mm and checking each VMA=E2=80=99s mseal = flag directly >> without an extra loop [1]=2E This is a semantic change, i=2Ee=2E partia= l update is >> allowed, VMAs can be updated until a sealed VMA is found=2E >> >> The new semantic also means, we could allow mprotect on a sealed VMA if= the new >> attribute of VMA remains the same as the old one=2E Relaxing this avoid= s unnecessary >> impacts for applications that want to seal a particular mapping=2E Doin= g this also >> has no security impact=2E >> >> [1] https://lore=2Ekernel=2Eorg/all/20240817-mseal-depessimize-v3-0-d8d= 2e037df30@gmail=2Ecom/ >> >> Fixes: 4a2dd02b0916 ("mm/mprotect: replace can_modify_mm with can_modif= y_vma") >> Signed-off-by: Jeff Xu >> --- >> mm/mprotect=2Ec | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/mm/mprotect=2Ec b/mm/mprotect=2Ec >> index 516b1d847e2c=2E=2Ea24d23967aa5 100644 >> --- a/mm/mprotect=2Ec >> +++ b/mm/mprotect=2Ec >> @@ -613,14 +613,14 @@ mprotect_fixup(struct vma_iterator *vmi, struct m= mu_gather *tlb, >> unsigned long charged =3D 0; >> int error; >> >> - if (!can_modify_vma(vma)) >> - return -EPERM; >> - >> if (newflags =3D=3D oldflags) { >> *pprev =3D vma; >> return 0; >> } >> >> + if (!can_modify_vma(vma)) >> + return -EPERM; >> + >> /* >> * Do PROT_NONE PFN permission checks here when we can still >> * bail out without undoing a lot of state=2E This is a rather >> -- >> 2=2E49=2E0=2Erc0=2E332=2Eg42c0ae87b1-goog >> > >Hm I'm not so sure about this, to me a seal means 'don't touch', even if >the touch would be a no-op=2E It's simpler to be totally consistent on th= is >and makes the code easier everywhere=2E > >Because if we start saying 'apply mseal rules, except if we can determine >this to be a no-op' then that implies we might have some inconsistency in >other operations that do not do that, and sometimes a 'no-op' might be >ill-defined etc=2E Does mseal mean "you cannot call mprotect on this VMA" or does it mean "yo= u cannot change this VMA"=2E I've always considered it the latter since the= entry point to making VMA changes doesn't matter (mmap, mprotect, etc) it'= s the VMA that can't change=2E Even the internal function name is "can_modi= fy", and if the flags aren't changing then it's not a modification=2E I think it's more ergonomic to check for _changes_=2E -Kees --=20 Kees Cook