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 67BFAC021AA for ; Wed, 19 Feb 2025 18:52:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2B2728025C; Wed, 19 Feb 2025 13:52:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CDB6A28025B; Wed, 19 Feb 2025 13:52:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7BB928025C; Wed, 19 Feb 2025 13:52:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9C68E28025B for ; Wed, 19 Feb 2025 13:52:19 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4F8B41C7228 for ; Wed, 19 Feb 2025 18:52:19 +0000 (UTC) X-FDA: 83137589598.30.B495068 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf10.hostedemail.com (Postfix) with ESMTP id 66E09C000F for ; Wed, 19 Feb 2025 18:52:17 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lNvAC5Nv; spf=pass (imf10.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739991137; 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=wcD2OY6TqU0MtXZVRtiMEPyv+P7BaI1CEM+zQ7fXeKU=; b=sB86IRBY2kmpg7J0fsik+kWzuVZn2JNgxNCZC7GlRup7cdDqhZPIgBx7h+w/tmUWjYkwlx vy9F3okQNbhp+AYEW0EkNDvC0oqfOlxx/fo6XcDO56LthHIclLSoGs97QDDz7HCkSiRa3Q 4MQIHNCjPjxSP03rdV6yDKzj3WPHDfI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lNvAC5Nv; spf=pass (imf10.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739991137; a=rsa-sha256; cv=none; b=st4w4RMvMhwa4Pizj0LPG+0tXOElJmFQzZPqOyusP3+Z8XH7a6Md9GveDZO+GXH4mg2yXI X5gmoLeBY05ONPmCKrl7lgc8Pwm+3+LFh0fpuWY1TBCs1T4OoRFoBoY5CH8ZgAbXxpAmF2 UlapzTJoHhE1k++i9WuD57ONUrIJS3c= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-22117c396baso14275ad.1 for ; Wed, 19 Feb 2025 10:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739991136; x=1740595936; 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=wcD2OY6TqU0MtXZVRtiMEPyv+P7BaI1CEM+zQ7fXeKU=; b=lNvAC5Nv/npxnfyT15QRB3Z/A6nHEsSX3vZwvtJf4hdJJr8QSJOb40+f2LTz37OvLQ zS4hlobPSv0fksBaNnhtmsar9bXa9dJ9SjeCWvKBYfW+DH5jZdPj2vRfrEsNerGfv+PS ZStn7E+9bPTWC9AHPQgL3EdfyrhDQZeFbSvSIh1MJWpMS20N680xtyyGK0nnoF9cWqfk f4KWHsOWJGjHz4v9o5WIdVJnJgJnLGOAJsXyc5L4zraeSy9uP0BM3LNpN4ZIbrNo+yY9 HTvH5wH4B6W5QH2Bi4IrCkVzxX9MKkIcCj1jDn6GKgauqPmp8+06/RuAwJeG/TvjN6U4 VfGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739991136; x=1740595936; 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=wcD2OY6TqU0MtXZVRtiMEPyv+P7BaI1CEM+zQ7fXeKU=; b=Sk13EIUp9TWI/lLMwrS1UnVzFX2bRSlQ5hAGrC6R5wsnuIr+NEvtXVyjH7vkOuWDIw +IDBTlQ48iMXB/T6VTinhVU6YC12c85mywYuaQcyOLLf5Hs5b91cEm8N1bvH+8CN/a08 DPmggnOKautEV1OTtaozAJHKHhfRtlTLD0VLE4wxXaGV+41RbszdIKoVzRN7uKZZR7S5 r55gs6fhAbGWldeFxKT6a2/6HQLf8KeRb9jDjfwMjM5qVWh4KX8T8afXOWGgWWpsjtjk 8uhbi+lvlQHcUybezIDgWiPSvTs8ckHcsWSeKkhKOquav1t+oj3zd/mr+fLfBjQ9GL/f bQrg== X-Forwarded-Encrypted: i=1; AJvYcCXbeuVy8Xd+7/AkeAlc7FIdsyOmgMD1xentHYn1fqg2XYCK1Zhoiyt/MQAMaNB6CuvPiGg2hcq2lw==@kvack.org X-Gm-Message-State: AOJu0Yx0Fuc58yz/G+pdH9kRXxz7pMVvIfcCzNmFT5HhS0ryETPF5yGV EvAq8+R4hFBBo2MqcOw0+sy7j+0OOT/vZUrdmdzadfRZZXPJk2MNPBN1SqCduGNrcnj29eux27d EfZyvSc8+B2eN5Q++R51+p8lVXCfVIWkQp/n1 X-Gm-Gg: ASbGncvb8uythCSk3AEPRHt+kl8DcVGAkVyRD8IWpfHZmgRNHEGPt8wefXQRbEpaSB3 nVr3sRs2rXZIUN8TPo0LnFDMhhqAYh3THjResDteVDY3934NvQHHdiZu4kWkYN31aSgSRMHCnTk +RGRGmGqafx6eoBj17CzgwMGHieXs= X-Google-Smtp-Source: AGHT+IHllOv/cA5pCN8NUTdnTUDAc13ch3qVkhVXnm87gBSv+gZjArMZqsuk6ANBMTbf+u7AL6UCc15z80Q4w3bHvEg= X-Received: by 2002:a17:903:234a:b0:216:607d:c867 with SMTP id d9443c01a7336-2218e124af4mr16865ad.29.1739991136034; Wed, 19 Feb 2025 10:52:16 -0800 (PST) MIME-Version: 1.0 References: <45297010-a0a4-4a42-84e8-6f4764eab3b3@lucifer.local> <41af4ffb-0383-4d00-9639-0bf16e1f5f37@redhat.com> In-Reply-To: From: Kalesh Singh Date: Wed, 19 Feb 2025 10:52:04 -0800 X-Gm-Features: AWEUYZlgAIPWYOaVEJVknMRVD_9aoQXv-WWi6eAsmm_A9LcKB1_-iA2G2pXLn74 Message-ID: Subject: Re: [PATCH 0/4] mm: permit guard regions for file-backed/shmem mappings To: Lorenzo Stoakes Cc: David Hildenbrand , Andrew Morton , Suren Baghdasaryan , "Liam R . Howlett" , Matthew Wilcox , Vlastimil Babka , "Paul E . McKenney" , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shuah Khan , linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org, John Hubbard , Juan Yescas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 66E09C000F X-Stat-Signature: wewyqrjc9481ihkwm86hh4pmxwxz78uw X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1739991137-217044 X-HE-Meta: U2FsdGVkX193ECBXenRUNjJtHCcry/rqf9suHz4xFtTKauTlNXLJTLCmRV+vBLKXYXL9zP+lC76DrwelmN4zVitVpwwEQitDY0/1lGr35aD2MDOgBFxXVYuJTRekgxMIpjVmUdEwjSexxA8ES9HM2PJjhH6pyothSVffNLMzUlaXs5+WKp/YV1NdzM/YePm0i0QqjN1+Sd+dlLk7FldFMzPJSy3laP+6GTCVq2rbpgFuLDgmarrKD3Q3Yd57Mgly2vtR2cbr1w/eF7TdnNXu+I/amKEa7NHtKEHDWrOQTLIU8OogYVeD4omgSpXu6o1bYuRC80xMANxoV19EboTtwrwX2C1Cm0K/x6FaU13e9E8fHEu7/8ci0imT64C7gwe1+oap3TXzk7vV/cjyzaAEKdnCMlFrPa1KaXUJebeBOZ8xkyWaOXA14VIM47Qjw6sMpaXk12uy3i1HtwiaA9ObofBuszcNK7W69syybDmVKSo/7CPIiU/8F6Krh1aHwhOnFaIXaoP5o5w2rgXPVrmrNPnIo1/qzgdJB+Hf64TCeNX/ttQTcPzJmjegA3crhIhw9exuuxxlx7nBtY0Fp/MhbSRrCteGBC1Ul5YNJ+I7dWDy+G11fXFxW2hnnchjlZWQrDOFz3C1RUy+3bApqqDmGbWQEElhRmBQHvXSFUW7qW6eUsQQsqSRIASesDQgbbEadAUe2C8BlMBjn/sv1ftM1G1EAnRQvOFECPveLJJ7qdc0v7pPwcyNx8ni04ph8eWX+snS3wa9IWAE/Gw9yPyxVUNCeYBp6VcCnfOrASj/SICsn2WhNS+os+U1SJyNhc2qRwaebmmz2D8akh9f+1/YMQENbv/ojz1nmj9zLSswLdxXtlHttOOnwXWVmh3GgnGnkDCsToZUnjlOJbpo4DGill44hpbxLUeyyriSueBU4kn7xkJRSQkchbW+s/uSGvBvDV/KuelXD8OfAGC/gXL bj4tLgsW +bgNwmUwA59H3G/2Uq0VPc3mM3rBhKPkmoZBEchN4FlEO9ywOgjI7oX1RIHNzbBnhIO84KmatJKoEeXfnjlQCs53Cv/AWQhwFJ7zlKrYEBmEe0WpMukranNlX5l0J0916Rp2IhJXEOdovOrcJFvT+/pPgHth0d5XVy8gEqiX2watLN235tWFjjRoEzABdPRoC1tTgHFB/kh+Lfka+PmBsK8LMg0VYLoLb9brF X-Bogosity: Ham, tests=bogofilter, spamicity=0.000315, 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, Feb 19, 2025 at 1:17=E2=80=AFAM Lorenzo Stoakes wrote: > > On Wed, Feb 19, 2025 at 10:15:47AM +0100, David Hildenbrand wrote: > > On 19.02.25 10:03, Lorenzo Stoakes wrote: > > > On Wed, Feb 19, 2025 at 12:25:51AM -0800, Kalesh Singh wrote: > > > > On Thu, Feb 13, 2025 at 10:18=E2=80=AFAM Lorenzo Stoakes > > > > wrote: > > > > > > > > > > The guard regions feature was initially implemented to support an= onymous > > > > > mappings only, excluding shmem. > > > > > > > > > > This was done such as to introduce the feature carefully and incr= ementally > > > > > and to be conservative when considering the various caveats and c= orner > > > > > cases that are applicable to file-backed mappings but not to anon= ymous > > > > > ones. > > > > > > > > > > Now this feature has landed in 6.13, it is time to revisit this a= nd to > > > > > extend this functionality to file-backed and shmem mappings. > > > > > > > > > > In order to make this maximally useful, and since one may map fil= e-backed > > > > > mappings read-only (for instance ELF images), we also remove the > > > > > restriction on read-only mappings and permit the establishment of= guard > > > > > regions in any non-hugetlb, non-mlock()'d mapping. > > > > > > > > Hi Lorenzo, > > > > > > > > Thank you for your work on this. > > > > > > You're welcome. > > > > > > > > > > > Have we thought about how guard regions are represented in /proc/*/= [s]maps? > > > > > > This is off-topic here but... Yes, extensively. No they do not appear > > > there. > > > > > > I thought you had attended LPC and my talk where I mentioned this > > > purposefully as a drawback? > > > > > > I went out of my way to advertise this limitation at the LPC talk, in= the > > > original series, etc. so it's a little disappointing that this is bei= ng > > > brought up so late, but nobody else has raised objections to this iss= ue so > > > I think in general it's not a limitation that matters in practice. > > > Sorry for raising this now, yes at the time I believe we discussed reducing the vma slab memory usage for the PROT_NONE mappings. I didn't imagine that apps could have dependencies on the mapped ELF ranges in /proc/self/[s]maps until recent breakages from a similar feature. Android itself doesn't depend on this but what I've seen is banking apps and apps that have obfuscation to prevent reverse engineering (the particulars of such obfuscation are a black box). > > > > > > > > In the field, I've found that many applications read the ranges fro= m > > > > /proc/self/[s]maps to determine what they can access (usually relat= ed > > > > to obfuscation techniques). If they don't know of the guard regions= it > > > > would cause them to crash; I think that we'll need similar entries = to > > > > PROT_NONE (---p) for these, and generally to maintain consistency > > > > between the behavior and what is being said from /proc/*/[s]maps. > > > > > > No, we cannot have these, sorry. > > > > > > Firstly /proc/$pid/[s]maps describes VMAs. The entire purpose of this > > > feature is to avoid having to accumulate VMAs for regions which are n= ot > > > intended to be accessible. > > > > > > Secondly, there is no practical means for this to be accomplished in > > > /proc/$pid/maps in _any_ way - as no metadata relating to a VMA indic= ates > > > they have guard regions. > > > > > > This is intentional, because setting such metadata is simply not prac= tical > > > - why? Because when you try to split the VMA, how do you know which b= it > > > gets the metadata and which doesn't? You can't without _reading page > > > tables_. Yeah the splitting becomes complicated with any vm flags for this... meaning any attempt to expose this in /proc/*/maps have to unconditionally walk the page tables :( > > > > > > /proc/$pid/smaps _does_ read page tables, but we can't start pretendi= ng > > > VMAs exist when they don't, this would be completely inaccurate, woul= d > > > break assumptions for things like mremap (which require a single VMA)= and > > > would be unworkable. > > > > > > The best that _could_ be achieved is to have a marker in /proc/$pid/s= maps > > > saying 'hey this region has guard regions somewhere'. > > > > And then simply expose it in /proc/$pid/pagemap, which is a better inte= rface > > for this pte-level information inside of VMAs. We should still have a s= pare > > bit for that purpose in the pagemap entries. > > Ah yeah thanks David forgot about that! > > This is also a possibility if that'd solve your problems Kalesh? I'm not sure what is the correct interface to advertise these. Maybe smaps as you suggested since we already walk the page tables there? and pagemap bit for the exact pages as well? It won't solve this particular issue, as 1000s of in field apps do look at this through /proc/*/maps. But maybe we have to live with that... We can argue that such apps are broken since they may trip on the SIGBUS off the end of the file -- usually this isn't the case for the ELF segment mappings. This is still useful for other cases, I just wanted to get some ideas if this can be extended to further use cases. Thanks, Kalesh > > This bit will be fought over haha > > > > > -- > > Cheers, > > > > David / dhildenb > >