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 4193CC28B28 for ; Wed, 12 Mar 2025 15:48:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4137C280008; Wed, 12 Mar 2025 11:48:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 39C40280006; Wed, 12 Mar 2025 11:48:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 217E3280008; Wed, 12 Mar 2025 11:48:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 00DEE280006 for ; Wed, 12 Mar 2025 11:48:44 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 47922141151 for ; Wed, 12 Mar 2025 15:48:45 +0000 (UTC) X-FDA: 83213331810.27.7588F64 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf13.hostedemail.com (Postfix) with ESMTP id 6C43920019 for ; Wed, 12 Mar 2025 15:48:43 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Y2hnTU5V; spf=pass (imf13.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741794523; 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=CA0E1+QIouT26J6b1C6kkNeaBYQ2U15SMRJrDpKVBNE=; b=U0hZ+ei2tRFt31Ght9ePh/hmZncRnB8VKkas3IH/LJeY98Mj9FD9F7n98ovQu8mah+9d+8 jEonm/Om0JaxhzWiHcoyrwEmpjxE1pfl1Yuy1Jac1k9wiVguy3yDCDkBF+no+EwCY0EZOR o9xH/gCTY0QCMvGNACjdZsj+4FnUs/E= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Y2hnTU5V; spf=pass (imf13.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741794523; a=rsa-sha256; cv=none; b=RIdiihKVkljaqTbSHgrp4uYpAV8hatkQ8HfzQ7zMEU+cvn+pYjKEIVObUc4k3XPerwflVp 9eXlMchO3/fdhXlVI15Pi2LA0ZFivFNzfTvt0BeJWR314ihYucEgIUi/LZMPwFGE0HPVoG 4JIBDX4S4v3dZfv1Mm18Gj4j7AR2cdA= Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-523fa0df55dso893922e0c.1 for ; Wed, 12 Mar 2025 08:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741794522; x=1742399322; 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=CA0E1+QIouT26J6b1C6kkNeaBYQ2U15SMRJrDpKVBNE=; b=Y2hnTU5VlAzDtpkY5qFyt+aPUOAGO20FIEPuD8grXJEJi9mv50704wMrdNxfm7akIV 0LsknCQ2gQFfv273D+el4SIIh1oMG6NGfuW5gsf7p3w0wtsdd5XmRBpbDQvNiRinVdUz iQJfPZwvCaTMLGTQb0xFjHRIbfdNWcKExBA2CY4aSZEFf4bHOd+G8nQzU2Atga05FA+F 5rvB3+/uegV27bhI0dNMD6UXFbp+Z2QTjlID898l95RNuGaWxvGcdW0cQ6O4UIZ5w3Al c58/1wV+bHnmg+if8JsQQ248rWcNOaVRH3RwGWTbi3ieyH3MPGK3mAqtlbzMsjutared rZ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741794522; x=1742399322; 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=CA0E1+QIouT26J6b1C6kkNeaBYQ2U15SMRJrDpKVBNE=; b=wdjNO5q16D/EmhzthXFCl2zla/hqCftqk4BRfJUgYXCeuMreO3v3jnDqeNocX65bfn J83A9uMTf0pcJRuDDK3cdkJ1YpedgCjEpfOAWVOVg2yOpzCbTQPY8r6BXZScHj55qtWg myf5/Fxbo4ajyBqCVxa7ejjplfF9yZMyp+tchhSydWrAHE0akMuGsohJSzsM9WEHEZ+V olpddVeWw60KEltJOYaAVyVI1lJhsoiN78UIcm4k380K8F01ZqCX6lvI+gejiwsIrBPo UIVRqrNu3JbmhfBJoTfIX2km3xLcbyL6YNK+8ZW6qORpcXvZbLf7IiuTkAFRz2CoJU7H a0Gw== X-Forwarded-Encrypted: i=1; AJvYcCXJcNhIcuM3qtdCA51LeA3k8Sa5X6fUiasfnbk+8xWqa+JgT7ltXTIp8QWuW2ab2bVZNr0WMeQ8Gw==@kvack.org X-Gm-Message-State: AOJu0YwIRwaBqerWCOxVOAZ5GXdpsbr4utYW+Pgtu4r6efHXkWFQIA5+ eDhfr+MWAQZ/Gm8tgzHxiVdwppy+Cwxi/0x5N5FlADbpWkT4zww1X43aj11pN2yhcvJjxTWD+Hk BC62zLEHXX2mYnDdZc9WFHi7Kc4c= X-Gm-Gg: ASbGncveFY/Y7MWj1TgPB3oNSluEf7wsOHz91hol8uLUfC87tEvnIR26gJCtt0IXm48 NQIxC53WREmPADTZypfL3VZkZxaIYeNL6Nly62X7X5eDTHGWcvqW13PWXpnDIu/CrrriSCRcYzu cXSWBt+Lpi+FCDizWo7p99W27M5lZXk6p5Aov2pKpjmvaHmiXSzNswbKn06Q== X-Google-Smtp-Source: AGHT+IGgNahbxSbQna4G9Ni14R4KFZmtH4JnIZG+uLUGeQ1P4zqoNf+g/NrxbLm5rDHx4iRs96GD9OYdN2cqb4BzjTg= X-Received: by 2002:a05:6122:3c43:b0:518:8753:34b0 with SMTP id 71dfb90a1353d-52437de5a95mr97996e0c.4.1741794522420; Wed, 12 Mar 2025 08:48:42 -0700 (PDT) MIME-Version: 1.0 References: <20250312002117.2556240-1-jeffxu@google.com> <20250312002117.2556240-3-jeffxu@google.com> <64B6294F-B059-4744-8548-89D7B519BE72@kernel.org> In-Reply-To: <64B6294F-B059-4744-8548-89D7B519BE72@kernel.org> From: Pedro Falcato Date: Wed, 12 Mar 2025 15:48:31 +0000 X-Gm-Features: AQ5f1JrWH_NUnvOlBfCLeU2iGn4bsAsglh4RBB13Bl-yre5HPY3wUm8KqBRNwZk Message-ID: Subject: Re: [RFC PATCH v1 2/2] mseal: allow noop mprotect To: Kees Cook Cc: Lorenzo Stoakes , jeffxu@chromium.org, 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, rdunlap@infradead.org, jannh@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 6C43920019 X-Rspamd-Server: rspam08 X-Stat-Signature: yzg56zf8drfx1k7kaby6ef4bce43pjt1 X-HE-Tag: 1741794523-389651 X-HE-Meta: U2FsdGVkX1+zNPSEm4gX4w75d5FA7NRVAs49l/Ckk48EnAaHSpBPW/ZEGts/TJHSvEAtd3gffnnk2BQWI1n1OSu4YeIKvPXQlWPJ9Qin+7G6IDOZmrTlLSxiiBLdfMv2M+eNWK4Qf76cFc19i9TZgZP1FHbhAVIIDSq414ri21BclPMB61rLAUUNLOb4+qoRc7zC2o9pVKZUrORGtgD4PmmDhzD82i4y+K4/9GZYeZRIK1SNyQ7qLnu3HtfcItA5xK6MnQjAQrRErUeDhxbkidYo6/nvpn0rIr28LKuEe4wNycqcGjI6mEXsKufNUQ9Q/sT++q3xy2/tNN7T2b6KhJkpAk84IPeFmzMz4f8hR3x5SVJ6eWVygGvTARglt2M+70Dd4ymxtGOgqwrmHxcBE65NTS0TJriB9yBf+iBVjrM1drsawPfLGNfVqRj3V/kv+XQg19RIr1YN/QycZP0tkFdj9rmhSdAo0Mj4CVL/jUlNyOy9DXHXCT1yyNEt4vwYewaBxme0vzcp5TvWjREYVwASDP2Y8iCWD4/nEhJbuh+H7Frp8K1FF0hsuwUbEy972x3KHH//bkz78skDW4hznnAiWmlhU9uapmHnj6fJyhtZN5O5Xr/cdtJhUkW6lWoOWo7PgZth/IkSc/TGgViBm9Z8Ryvc+36uAccpcQTV30E/L3p2QfLAMqcxWpxfqPbr6QFvhGYCHtACNb2Lb8hoCIB/0/9b60efC0ojBzxgdDxo54bxorW98RwFsY/4SIq3PrYZ/J+kmRoWEHUE89NepOghlxCzsvl6xAnp271OhVu/IdcJbxzHY+zlxbNffuKwaGLTGH7tvGRNn3SSpoMtuPcbkJnqovDQJNcha94+RFuDyEccVn1D1rD5j/Z3RpJ8RPOCcAMcpSdYF6tMtVR+wLjGw9kZ5N4xCbgqlzpEWUmuyCryz+QBqEdx1hbfIw9TRCQYV419IblBpzyBgvU nuTu1/hR zWBqe5FmhlfmrAcKk7q/zriMWQWMUa5UlWTkm0yr7XVNfwB3kVp3im00xOvcMQx/SVnE86FIY6Q3IQtHxcikOYI7kAaxUkTk+z31C0yx9wTA63wk6sFTvNq50C8eY1VDrwdYwn36XtheOJ5VvB6j6J9P1fQBm2QpMxtjXSX6DN/PuTYDKfmB4M/0IyuY8Djk1uxe7sLO12SDW6A2HxOaeVTJZe6f0iOGyxYsKIYn7jwwUVEqUqKGmIusCXYVcnXX6e7IgPezY23JCoFy+qaHSBABAjpiHmuwNyxvUd+GKoD/J01X8MQYPbai3sN2sd+EZUm7QOQ2mzgSKjDqdy9KVTXHCS4W+9De8izZYGA2Eesaw3RWchqSUDLEcorOceUB76kc/rYVL0ReDlzXo9E74fleJki98IVsN8CNReCbcOIMYKCusk180OKlA85sVsNVHBRE2 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, 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, Mar 12, 2025 at 3:28=E2=80=AFPM Kees Cook wrote: > > > > On March 12, 2025 6:49:39 AM PDT, Lorenzo Stoakes wrote: > >On Wed, Mar 12, 2025 at 12:21:17AM +0000, jeffxu@chromium.org wrote: > >> From: Jeff Xu > >> > >> Initially, when mseal was introduced in 6.10, semantically, when a VMA > >> within the specified address range is sealed, the mprotect will be rej= ected, > >> leaving all of VMA unmodified. However, adding an extra loop to check = the mseal > >> flag for every VMA slows things down a bit, therefore in 6.12, this is= sue was > >> solved by removing can_modify_mm and checking each VMA=E2=80=99s mseal= flag directly > >> without an extra loop [1]. This is a semantic change, i.e. partial upd= ate is > >> allowed, VMAs can be updated until a sealed VMA is found. > >> > >> The new semantic also means, we could allow mprotect on a sealed VMA i= f the new > >> attribute of VMA remains the same as the old one. Relaxing this avoids= unnecessary > >> impacts for applications that want to seal a particular mapping. Doing= this also > >> has no security impact. > >> > >> [1] https://lore.kernel.org/all/20240817-mseal-depessimize-v3-0-d8d2e0= 37df30@gmail.com/ > >> > >> Fixes: 4a2dd02b0916 ("mm/mprotect: replace can_modify_mm with can_modi= fy_vma") > >> Signed-off-by: Jeff Xu > >> --- > >> mm/mprotect.c | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/mm/mprotect.c b/mm/mprotect.c > >> index 516b1d847e2c..a24d23967aa5 100644 > >> --- a/mm/mprotect.c > >> +++ b/mm/mprotect.c > >> @@ -613,14 +613,14 @@ mprotect_fixup(struct vma_iterator *vmi, struct = mmu_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. This is a rather > >> -- > >> 2.49.0.rc0.332.g42c0ae87b1-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. It's simpler to be totally consistent on thi= s > >and makes the code easier everywhere. > > > >Because if we start saying 'apply mseal rules, except if we can determin= e > >this to be a no-op' then that implies we might have some inconsistency i= n > >other operations that do not do that, and sometimes a 'no-op' might be > >ill-defined etc. > > Does mseal mean "you cannot call mprotect on this VMA" or does it mean "y= ou cannot change this VMA". 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. Even the internal function name is "can_modify"= , and if the flags aren't changing then it's not a modification. > > I think it's more ergonomic to check for _changes_. I think this is a slippery slope because some changes are not trivial to deal with e.g int fd =3D open("somefile") void *ptr =3D mmap(0, 4096, PROT_READ, MAP_SHARED, fd, 0); mmap(ptr, 4096, PROT_READ, MAP_FIXED | MAP_SHARED, fd, 0); soooo on one hand, I don't really have grounds to say this patch is incorrect. On the other hand, I'd like to see either a particular problem or a consistent criteria we can apply to all VMA-related situations. --=20 Pedro