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 2712DC28B2E for ; Wed, 12 Mar 2025 23:30:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5297A280002; Wed, 12 Mar 2025 19:30:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D8D6280001; Wed, 12 Mar 2025 19:30:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35346280002; Wed, 12 Mar 2025 19:30:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1A1E8280001 for ; Wed, 12 Mar 2025 19:30:03 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D578D57331 for ; Wed, 12 Mar 2025 23:30:04 +0000 (UTC) X-FDA: 83214494328.16.5264297 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by imf30.hostedemail.com (Postfix) with ESMTP id ED6C08000D for ; Wed, 12 Mar 2025 23:30:02 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=K1b83GjD; spf=pass (imf30.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.41 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741822203; 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=2epRF2yIZ4WoKvdTuk66kXn9icmipQ0jsgIlyAwLUYE=; b=r2DglVgPErQnrdNXSgdfwysep/nIyEXYvwFTkWwng8lHWVMVfIvA39T9bcWz+GCbzYK65W GpfbfrJY2TjHbtQHsAryDGy+gn+dDGF/YyCQVAj34h2Iy0mkZN7Qvl5F1I6jsv+Vm/IhoF chmwcl/zrz5QFVtyuMBqMBKKhRzYNo8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=K1b83GjD; spf=pass (imf30.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.41 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741822203; a=rsa-sha256; cv=none; b=IKISplo9Qr5YppkcnrxFbG6tEuSKdqBRJvRRMOEA2uof+SFQqnUwmMXIBFrtR6SPh0itpK 0EaYn0q4JrhTjOtyWWvWtJV+dYwCE8mPJfxIsaTQT67yq0jT6Kgm5jBjBD0v0zW6Vb40+x NUQ/Tsz2z2iD2Ph8QpNIhYS3iQLBIO0= Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-7231e216a06so37542a34.2 for ; Wed, 12 Mar 2025 16:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1741822202; x=1742427002; 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=2epRF2yIZ4WoKvdTuk66kXn9icmipQ0jsgIlyAwLUYE=; b=K1b83GjDMaEpMXfqp87JB04KIY4F/6mqxxyFGO0s8UEO89s/gU6xPfIDurKP1qxUJz KmaIwLajHuhGSRjQ55pGzOerIbsZjYCkHdxgwv60mCrMnoLCkveHYNmIGvNrm6snqV7Y Oqf7tKWLnNlYapZ/xOWCLpnGOn+FInTNu+PM4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741822202; x=1742427002; 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=2epRF2yIZ4WoKvdTuk66kXn9icmipQ0jsgIlyAwLUYE=; b=q6xEPEU4oGA+A6eupKmy9FghDny4aro/UnsYzhsQmGagZZimu2MjBRoSMIBxVXwIwl 8IC0aAms9HXPkH4MTsn3rNO0o+r1QMryw/0xEjl45Fc+PCoojfMbkQJSvsK82JA3wL0s bZyKfWA4MuOsQ8U7hE7RqQvqx4Ty4CZTAjHyR2S6VoN8BPVGimN9GXXrVEaxiCjRu55y wFvuJdf3k3R1HarNSHgK4hSPZyg2LeUqsxC9qvBqQZoDONyMp3f2goVFQETGk8I//JsB pTk13bothu/npUaR/BtR5PiV/whOViHyiqXQWu4CGYxeNrKchIhaRiS/U+i8dkP669mC zhKg== X-Forwarded-Encrypted: i=1; AJvYcCUTznc8wrojinVawOnTkL5Nw0mGXhFKe/nKhlblbTM5C8tQn5f3Rp+Aklzi7gE2zBCJ3oLRJ/61Dw==@kvack.org X-Gm-Message-State: AOJu0YwBae2vEUO6q9/ncM5jYxWTp3F/cQ2kJqkPizllEnQRA2aOTSaB etTtY+ylMxPdiYzfnNTsaWwniho1+m3GIkNoODvF3Kb59wbSyhVI5wrjjbwH4A8RB+y2pJdRc30 dzdD/D2gSeTLal8TWdl+Ua0U0jEdHDYlpo2oF X-Gm-Gg: ASbGncv2d8KGSOr4nOyeGFhtKL7/sNcXralV+QC5NdkkxjKOfxYZzQifLNSWP1juj+m pRmi+gK2BnXO8e3oCHD74W2qNpx3U8zZfClXuQWdLGWlhsGSCrZgTA/3fZwMFHIizZoPMrglYdG hW4f+NHvqKAIwbUpPSOa1Q69+x X-Google-Smtp-Source: AGHT+IF3KK2zPAe3DQbz1LO5JCsOn/xBbba1NwUWwZbYJy3s2T7qPHVL8YcMfh75jIyOKbZ08RS1xlD+8DXPHeL6Fb8= X-Received: by 2002:a4a:db95:0:b0:600:24f9:21fc with SMTP id 006d021491bc7-601c24cff19mr1200447eaf.2.1741822201807; Wed, 12 Mar 2025 16:30:01 -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> <9b3a3ac6-a947-4be2-98b3-c35c195d87ab@lucifer.local> <202503120931.3BD7A36445@keescook> In-Reply-To: <202503120931.3BD7A36445@keescook> From: Jeff Xu Date: Wed, 12 Mar 2025 16:29:50 -0700 X-Gm-Features: AQ5f1JqOVPfwUnKOxqrdAsJKAmIgChV5YiCTfryTQdRd23HMgTcMUTwhsepcUGA Message-ID: Subject: Re: [RFC PATCH v1 2/2] mseal: allow noop mprotect To: Kees Cook Cc: Lorenzo Stoakes , 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, pedro.falcato@gmail.com, rdunlap@infradead.org, jannh@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: ED6C08000D X-Stat-Signature: u476pdi9edjy3jygygwaqypzahhud7xz X-HE-Tag: 1741822202-437803 X-HE-Meta: U2FsdGVkX1+8Gc+OwiWUTAmZA5whjDpzUaDPsRJXCUMtuKhwgW62ppuliezSrF5DPGKuXjrDIvOIQ3p2kWcKQR/Xk2SLguaRCfhsc1QkXmQNnSEezUVvCgnreseapnQRhB6TmRUBRtTOR7PU8ONFcpG4MwoWVW67uLkCinALf2fl6pTDyGuzBpxikbe/nNmWElmopQWW8dXhLuidWHec+ZuZjjT+u5/voMn6iYUYncJQOBQXdKUyOdWbYliCDc+DDCYzwZ87XkC1h0wX2rqOrcSAM+R7Q6cTyTNA7NVjBQqCV0++a+H417jczGqJaB3NxyyYoZbkU1zhQxQUzf4V5Rx2Gp7BplHh1HnnN4auhjLxXfKx6FZwMqi3ZqmLALuVmowO8gP62y3lxyD3ccwC5k6TJX4Oiep1KT9jDfmo0ljf1BIfoXaHVZgWjYC+lXUE7zDpuH4qocYEMmQRludJoLEYIjgNbXZlQX7RfaTzueI4eLtGjM2/Cqavm2VJ4GU0F7tjxywAfwwn/uow3uQALOI46P4UlRaMiyST/2DwmnMRD7krPdUKo2GGSWYVDnZU10BOVvgQ0p8HO49bRBFmqxg5UHyBTvPGjx2/Wl8L8KCkyQtVc2el01gXhJ4WAYbb4OWqk+KCSaj0q/erlc9q51mEEB3UHLeFBN43IGpnt9g9YBqbmQuTJhTZg34TZotg4C3zufSSXNj/pD0Rwdn9MT32id6bxObOuLaMIbU1/Vgq6IWcNEMAi9uaXEAvF+v09WnbN91kwC+yqzIyaBTeeRiuK7RcuIRxuEjcDRY3iiBsLqoy+ipRU65ZotiKIn6pR40IEm96UStAjZQWkFesmScLXoFXBKA+ECXgQkaBKA7E2xPx1DjwFY3vRoScsT+aZOyyPaGqaJ6tmGhYZebwRlm8yIKRL9XiQKxYcfhAAPh93IkaScakhrWRzwbKRDUX1l4FIi93bcx4N3LU53c o9lyVupm WbVxGzQsDNhRpSpm40Lrl7v2ey/ZTU23A/2YbzR0LBRJxhlsKAMpQqW5FkFF8uSb06moQk2H8m2tMm+WE0zL/cYwmBCcBaJf264tAi75H2cn8EERGc4n2dAbAhtoRpq/d+7JDqPimMjk7PRf90pCsdMUUJSZLAeNkMOSvGt1q9ySBckArWLS7WvkikVzsEthIIRcGTtZag6fs+IpMWYYvd+Eh/HC5MYaMyvknfCXuybAxzUV7Dbsm761HawT7Tp1iDEQG4e/CqUxuI8cjPo/auDPfoxrS1mt65LVGo7+R0rY2hxo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003241, 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 9:45=E2=80=AFAM Kees Cook wrote: > > On Wed, Mar 12, 2025 at 03:50:40PM +0000, Lorenzo Stoakes wrote: > > What about madvise() with MADV_DONTNEED on a r/o VMA that's not faulted= in? > > That's a no-op right? But it's not permitted. > Madvise's semantics are about behavior, while mprotect is about attributes. To me: madvise is like "make this VMA do that" while mprotect is about "update this VMA's attributes to a new value". It is more difficult to determine if a behavior is no-op, so I don't intend to apply the same no-op concept to madvise(). > Hmm, yes, that's a good example. Thank you! > > > So now we have an inconsistency between the two calls. > > Yeah, I see your concern now. > > > I don't know what you mean by 'ergonomic'? > > I was thinking about idempotent-ness. Like, some library setting up a > memory region, it can't call its setup routine twice if the second time > through (where no changes are made) it gets rejected. But I think this > is likely just a userspace problem: check for the VMAs before blindly > trying to do it again. (This is strictly an imagined situation.) > Yes. We also don't have a system call to query the "mprotect" attributes, so it is understandable that userspace can rely on idempotents of the mprotect. > > My reply seemed to get truncated at the end here :) So let me ask again= - > > do you have a practical case in mind for this? > I noticed there were idempotent mprotects last year while working on applying mseal on stack in Android. I assume this might not be the only instance since mprotect gets called a lot in general. Blocking this won't improve security, it could actually hinder the adoption of mseal, i.e. force apps to make code change. -Jeff > Sorry, I didn't have any reply to that part, so I left it off. If Jeff > has a specific case in mind, I'll let him answer that part. :) > > -Kees > > -- > Kees Cook