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 A35D4C282DE for ; Thu, 13 Mar 2025 22:50:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E87F2280006; Thu, 13 Mar 2025 18:50:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E110E280001; Thu, 13 Mar 2025 18:50:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8BC3280006; Thu, 13 Mar 2025 18:50:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A5163280001 for ; Thu, 13 Mar 2025 18:50:39 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9C015A837B for ; Thu, 13 Mar 2025 22:50:39 +0000 (UTC) X-FDA: 83218023798.30.3CF5D78 Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) by imf11.hostedemail.com (Postfix) with ESMTP id B8CEB40004 for ; Thu, 13 Mar 2025 22:50:37 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=fmFS9Zqm; spf=pass (imf11.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.46 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=1741906237; 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=cYgKJUYIz7Us1Ip4Rvr02J/jvpPESqI3sDoO+UIGHcA=; b=zcgh/okoqF8Ppqpf0nm6ovAfEH00u6M6/y9s+mGg1ylPqFJx935eTi77/kTCmp3GgCb59A GohgQg7XHs8+dg4jdC+Io+euBdjmXU5NtCEW+zkKBmA6mFK7ANQN9dCJUgzKeUNYNgfZUI Mrz7OAPEhhacT+ElA9zMnZ1NpJa1Hxs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741906237; a=rsa-sha256; cv=none; b=ezKaQ/vJuWli2qFVQ4CUFhJ9NRrwIoEa/Z6fy3S3ntfTQWujFHndKPyHcio6gDXhpjPhj5 rnDR9mhvx15xixa3cpYM86HYpE3IliV70oHLNIeeh5XKc78XTNfct90WLLAF/toG/9dLlc /LNT5L2EovjH9b8exFta5o5D8KWiVoQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=fmFS9Zqm; spf=pass (imf11.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.46 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-72ba84a7a30so119441a34.0 for ; Thu, 13 Mar 2025 15:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1741906236; x=1742511036; 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=cYgKJUYIz7Us1Ip4Rvr02J/jvpPESqI3sDoO+UIGHcA=; b=fmFS9Zqmk8zOVuW/NpRw4AIvrb1X+ZIZS0xAJy/D/E0gAchwT3/Yfy4Xdkhv4Lnq0S WEWYkfv/mi7kCiNqyfqFm7pfrgtROqVnXdCggSVckWdyQAUJu93ZPEMcSVmDhYrIEodU jf3ocuM3Ur2FEXIT+6xk/vPyhFRaahitEoh/s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741906236; x=1742511036; 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=cYgKJUYIz7Us1Ip4Rvr02J/jvpPESqI3sDoO+UIGHcA=; b=b62Ww7vG8R6fr0+CTcEysjcbthxUwoexcHlj5OgKwxjYw31+5kWlx+ATzpqS/OI9pi xnn2dskO+vmzj9hijLyNP9P7mlqYbFJmBfesDZ8XxbBHG4c22YgocoWcuckf+MH1UF1k tgrg1BWJw4bxVWr26HCi1z0W7pZUMgkFlshSDRF5ZRJxGduqifcXeanl+qRpCsorrmJz 11HzdGK9QPlcMcPZlHjOtlFZUDfOAiXT6rjtyLXJgMVoyyeC+IaynKLmqpMqlGE0vEwi hokivxvQSDT9GyXCZQkbj1UGXZt4ReO8m7uFs8jZGriE0OVYdEd7qMLWLnAozxV9tTbG PBNw== X-Forwarded-Encrypted: i=1; AJvYcCWBhu22wNBa4bnvB4iSvngfoFqz36GLVZBJ3YUu34EsqHs/zGeYJmzvblV8qFx7tgvJAaZnRyrFYA==@kvack.org X-Gm-Message-State: AOJu0Ywgj53j5U7g2frojuDIsd6DgQkYA8HLsduX1Ir9FpZucfwJQ2HG ui/AxGGeGAV/ZWgM1yhliLWetH0yxrqW//5jhkTlSBbvhCumm0JWzg4gm8zCcSphdcUyNT5cRVG s9woJAnk5s00Lmn37DGF9CzwbWsnRfdj+XMBX X-Gm-Gg: ASbGnctbxLyaGaEmsZ9TAEeJmsROxDjY9H9WJp2el2vTVzfvfIaquC2lSMeiNdG7uX0 hgipUcgTpToWezjScFFnGU92SNz3LbrpqmGTM/woUgOVRUhN4Sah2WYduLNLs+6v0vIyYBBYZVr DAUhg+YFS+7gQiZTxPy8YZqxmf X-Google-Smtp-Source: AGHT+IF2ZaluKLcKINtDeD+yBJJHOOdfDT/C8ffBzy/1eFICkDIbvTuBMV0m/DAX1vP5ilPahvsc58zp7sWYFgBEcnc= X-Received: by 2002:a05:6871:898b:b0:297:276e:7095 with SMTP id 586e51a60fabf-2c69124deedmr71979fac.11.1741906236616; Thu, 13 Mar 2025 15:50:36 -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> <79b1b6bf-e916-45d4-b20a-0f9041ca36bf@lucifer.local> In-Reply-To: <79b1b6bf-e916-45d4-b20a-0f9041ca36bf@lucifer.local> From: Jeff Xu Date: Thu, 13 Mar 2025 15:50:25 -0700 X-Gm-Features: AQ5f1Jqs1hIETtPSyGk_sCZon4T9X6zdTCjgSDXBMaF8XFl2bJPHN6hU06SYWXE Message-ID: Subject: Re: [RFC PATCH v1 2/2] mseal: allow noop mprotect To: Lorenzo Stoakes Cc: Kees Cook , 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: rspam01 X-Rspamd-Queue-Id: B8CEB40004 X-Stat-Signature: jekm6tsynmiq1meyc9mum7rg6du4cd83 X-HE-Tag: 1741906237-387590 X-HE-Meta: U2FsdGVkX181oF6+CR+LYnm6MyZhhbYg3bYthYdY7ODzi3/xEdfDQXqyCHEvapEXczSQmfXZRH/EMR8/IsfPMN6MwOGIpnOmbSbp5t+9Cs57efmY5dHy+pBqUHR/8rgg32Hn11uXdzjgt7skeufZ2QhWJZTamqH14f4v6diXnY/d2KQ/rGNyjzXhLtyKU+W+49RI6i5IV6zNjbeeA1O/unBO4HRguKHEHuu4qTuWELMLjRHyKMAjjw28BdPrffM0WlGsQzB2VYmDapKwNB6/DOZaQBweI9lOPZXjF//dcY8lBsf9S3e1YC/DHfr0fv27FLqE+uS6v1oER06a+1l/+831QWKqG2SrrU2Ovg0j9ioDeq19Nmn0sTr0Q49rfmag6G8/1Ts3QwXdcEvVeP2dZgxhNKthMbhV0f9UX2QDWcwVRbGleBvZMF3xY1glCUB1jngLYLOOA1Hub3kMGSiAi2sGBAK9h+biIKlTvJ6Aze4bM/gL1SqW/3maVfeH9CFVK3l9M10XZDmZYFlqB8riZH8ixHVznzgS+wwHq7ffnXVcRgUSm7A0HkAxyZqs4wATbj4rDxQau4M/NtEjgP3gmimwOcxLu3cPX6rWyMANZtHul68eO2y5mVQsdj4gGJixD8ExzR8Xq8nHtjyEAMjQsGosS//KtE0mOtG4HBX2ouLvGGUqq5s81Oy3o+UC4Z2Lro4+M8wWT0i1+qpZ5tTnhLtAhgV8i8DWWkn713mqpTzo7FOfyyIfP36BAFxKJYafxOL74fHSTxyQU5zMzrO5O5el20OMEEenE7bI67EJqJ9gs5yVJP14/vphtZl0DDR+wVPVXdAaQ3S9XH6JuwilXQIwduwXpXynBoAFiGkCUt5MzPe0QCpvAH/I5+HsVjl4EayRT7YG2K1YO3yhhksTGKK7aSG94Eh0EpibKeCkoXerDTRTeCSmOc+fNLG6sGoMqFy/SQqHg+E53SLD6Uz xu0T+xlN E0JlO2tZ8g7FEcUQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000014, 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 10:29=E2=80=AFPM Lorenzo Stoakes wrote: > > On Wed, Mar 12, 2025 at 04:29:50PM -0700, Jeff Xu wrote: > > On Wed, Mar 12, 2025 at 9:45=E2=80=AFAM Kees Cook wro= te: > > > > > > 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 fau= lted 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 ti= me > > > through (where no changes are made) it gets rejected. But I think thi= s > > > 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. > > PROCMAP_QUERY ioctl, /proc/$pid/pagemap :) I mean hey - these are somewha= t > diagnostic-y, racey, un-fun interfaces that we'd rather you not use in > anger when mapping stuff - but they do at least exist :) > > (an aside, been playing with PROCMAP_QUERY recently and very cool - we pl= an > to make this useable under RCU lock rather than mmap lock which will make > it _even more_ useful in future... exciting times :) > /proc/pid/maps only has a subset information of vm_flags, e.g. pkeys is not part of it, however pkey_mprotect can update pkey. So the suggestion of checking for the VMAs before calling mprotect won't work for all cases. Besides, the checking then updating pattern also has the perf impact due to an extra syscall. > > > trying to do it again. ( > It's possible, but it seems that it would be relying upon it purely becau= se > in some cases it would be modifying the mapping, right? > > It strikes me as very unlikely that an application would be looking to > modify the attributes of a series of VMAs including ones that have a > security feature enabled which says 'until this is unmapped do not modify > the attributes of this VMA'. > > Yes it's _theoretically_ possible but that'd be quite silly no? > > > > > > > My reply seemed to get truncated at the end here :) So let me ask a= gain - > > > > 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. > > Thanks for the explanation it's appreciated! > > But I feel the drawbacks I mentioned previously and elucidated upon in my > reply to Kees outweigh this theoretical concern. > > If we encounter actual real-world instances of this we can reconsider, > presuming we are ok with the asymmetry vs. other seal-protected calls. We > have this shipped with a uAPI already like this so there's no rush. > Sure. But I honestly think that you are overthinking on this. The security benefit of mseal for pkey_mprotect is that an attacker can't modify the VMA's attributes, and this patch does not compromise on that. Best regards, -Jeff > > > > -Jeff > > > > > Sorry, I didn't have any reply to that part, so I left it off. If Jef= f > > > has a specific case in mind, I'll let him answer that part. :) > > > > > > -Kees > > > > > > -- > > > Kees Cook > > Cheers, Lorenzo