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 54811C02182 for ; Thu, 23 Jan 2025 21:51:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1A1328001E; Thu, 23 Jan 2025 16:51:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC9FE28001A; Thu, 23 Jan 2025 16:51:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6ACE28001E; Thu, 23 Jan 2025 16:51:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 886A628001A for ; Thu, 23 Jan 2025 16:51:01 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 055CF8075B for ; Thu, 23 Jan 2025 21:51:01 +0000 (UTC) X-FDA: 83040062322.23.FD31A73 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) by imf04.hostedemail.com (Postfix) with ESMTP id 1F7454000E for ; Thu, 23 Jan 2025 21:50:58 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=yHFMhnxr; spf=pass (imf04.hostedemail.com: domain of enh@google.com designates 209.85.219.41 as permitted sender) smtp.mailfrom=enh@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=1737669059; 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=KNeH/Vwk0WxnvmxGVA+MQY7eTIFt8El+y7lX9sdBBHQ=; b=cWYpxrNZxfr+2ataWHQtv/8C7D6D6DSO02DHaYyqqFNDDPSxrWIS+Nj8swU5oaco/LbbTW Obdv8Fco6rcylQVjSUPV4mZlN3OfwzHCwipTzYne2WIprwwFyrP/7Y9qFgT5YORR4gAQIp 091X000ZJZf/xXtwSKr+xGFOrgpc4vI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=yHFMhnxr; spf=pass (imf04.hostedemail.com: domain of enh@google.com designates 209.85.219.41 as permitted sender) smtp.mailfrom=enh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737669059; a=rsa-sha256; cv=none; b=sqeSzx1WHIgKVvVRpNd9Sj6K2abnTA7ySEEW8Kso38LG8Ay3KmFj1Ka+P9qEBlwvfrqX7a yZFDziPKRJzH74UGkda5HnDVmIFsk1Vs4xiQJYU3gw4iAk6L6EfP0hF5cOg4HweDRadZd+ DanMeqTGwQKCwtdYdB8u4GSDs0UN+5g= Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-6d92cd1e811so22591806d6.1 for ; Thu, 23 Jan 2025 13:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737669058; x=1738273858; 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=KNeH/Vwk0WxnvmxGVA+MQY7eTIFt8El+y7lX9sdBBHQ=; b=yHFMhnxra/u7vgm8ik+kSmjShOugn1+QpT3uxKySEEv8ou37XDKdOiuyUi5IXl6MeN CJNaDpUWYU+cyeRDQw9Emgtm3lpNSxttukCbLaZ2x5IT0kjek5r6X+T7Ds8886vbSq6o 9wpHE0gtiWcV7sbv/JI+auW7gypy9684y5h7YDhoze+3lJZF9rvC2O0wmfBRsuFQtpXi qnFcIrZzW3ct992sBR8mP9x2ysBA9dZrhTzUwz8oaVdeS53IBP3XXmShxjKKvQgpx2/d 2qkwE4dBXbN8fRwb1uo/Re9S1v5hRi/MZefxiuwythyGugYTBJ9S0n7krM26TLG2393r EMvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737669058; x=1738273858; 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=KNeH/Vwk0WxnvmxGVA+MQY7eTIFt8El+y7lX9sdBBHQ=; b=eqjGanhsAM7W8iogqvXZb6EEdcN1d/myMNK44DVba2e14ccpT7LcYOVu84bR4Srcie M9Ib2GrcBhJxs/qI5E45FtKsLo9m+v+aXL5FKz3rtGh3le28y6TVOQgXCnkJMA41a0v4 mHCKx0LrHnv1P8aEJUIPAOOp2+yvi4L8p/nqjLg2VqBgJF+O94P4OX7Hi2S69iPUVNLG CiY9JHSE8dFw4Yo7IAK8ycLYOmO+OnbVS3xbsMw4c84tVOjduhJ2mKE4kq44Z9qdcGTL Uc2UnpXSs7VzwxQBnKYd41WnbrWOSnCCvWXRJ/H7Vzx3qx6dnOCly7OmxFfaVIpr/Qu8 ktxw== X-Forwarded-Encrypted: i=1; AJvYcCXzvTxkrFgh3X0mOii/ueLehJt/8a/CfmEPbcEJb4KkYXKFtW7NrlSSaMFSd6hEtjFtQXUHaLTRAw==@kvack.org X-Gm-Message-State: AOJu0Ywau7gwlox18g9qCBlCkE+X4y6gqJ5baSTl3drTPANJGWA8Ut9G 7Oz0jkCQC3RLGSY17IlM1H9Qhs3JLg+4wJAMZbkkeZYeOIHGm21H1Yq7UsH6C0J50Nlej7qxa+D cFq/mJLLeEiGd4xG5SRw9YeCGqMMfaEb407pb X-Gm-Gg: ASbGncv9WjUCHSf8P4oYH5d8g8ebjMtKzFRH4Q9qwLeESocA7dxbDBBC9XkQLKNvWAH mGvnZ9mYoD974lyvaeXxBXiWlhyP0pKZSMHF/6fjnZ94VxHum6anrZiC8SGU= X-Google-Smtp-Source: AGHT+IGjQLySf5h15b6EUt2+AojQPd7nFAI3klSmKwAgNbfD03RemFTK5I7CPHB5HkYURLTU16uxH/wLjwcvVxxyEPw= X-Received: by 2002:a0c:ae82:0:b0:6e1:b610:e495 with SMTP id 6a1803df08f44-6e1f9fb9c4emr61264266d6.14.1737669058024; Thu, 23 Jan 2025 13:50:58 -0800 (PST) MIME-Version: 1.0 References: <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local> <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> <881c3558-1101-496e-9ef4-5bef13f3f233@suse.cz> In-Reply-To: <881c3558-1101-496e-9ef4-5bef13f3f233@suse.cz> From: enh Date: Thu, 23 Jan 2025 16:50:46 -0500 X-Gm-Features: AWEUYZmZy44XkynCXJBk1cTdRc_83YgpLifVoyOW6uF3V0AfXoCnVqEoSr1EHzE Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Vlastimil Babka Cc: "Liam R. Howlett" , Jeff Xu , Pedro Falcato , Benjamin Berg , Lorenzo Stoakes , Kees Cook , akpm@linux-foundation.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, Andrei Vagin , Dmitry Safonov <0x7f454c46@gmail.com>, Mike Rapoport , Alexander Mikhalitsyn , Christopher Ferris Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1F7454000E X-Stat-Signature: c4birg5tk7dc7fmpikcewcyb9bmii4mk X-Rspam-User: X-HE-Tag: 1737669058-753447 X-HE-Meta: U2FsdGVkX1/DLYzW4pnrgi8LSgu9QefUxF9vEAm2JiQqJ14I3QCTMxLG4zErz76dSKIt9cb6vKnh/SnohbdlEIbL5vEqF7xW7WFe0XOEUgLGQpxBXIhW6N8UlH0rCnqFgZuR3xt/7VhBISoorCG1gSS6BgUiF133KwZ9OAsYOfS1UJW9wjtF4sI6nsWcjMLOSis8GRLm7lIU5o5C0UgLJ0it5pZCaX+4OdGgSyNLj28Y3PadGTb4FxX/j20h49gA6Y5QmXfpXYK3xdgPF3nWUXtfWi71JgQiCQHwLYWiJ3F+Ml1q5ja11+YKIK8PBLpy1s7u/1OFwkvK/f+fhA9IXjVlxylEj+7WRuc1JKiRMX3ohTA0b9GzPx/s6XntZKjdx9jGQL3M1zXE/7Hi8uyHPIPNTGuZmcmwPg42kP0sOsfAja8U0Y6J8Mwdkv4gmo9BjENQmGRXVgAO+Yqr7QakGq+4hqilazTLV72KW2/tJVx9JO/IAH7lSXExWTGGur6xficuQksTnKzU45sqYfcQK6GQXU8bjsZVkdVGsUwUN9iOHrr8UipmexPkrGGL+Rs9hV5NmbtmczowFwY2i02WXCjWssUyCKdK6up4M2wnbC4/owLzjrS7wluW3lzW1aH8ljDemRrAcYsWY2wq8XeXiEIF1o4bAyaP6SuRHrukiCX8yWGUSuktNiedaYgnlhafuaCwXoA+2B5Zfodm/0+bUoKfpwum9K8ULxO27qLqZt6gcLjfO088mdLwUv75P/TJO0C3goPssP0gtPQ2U1xyZlCpkJiIMu0A8Y5t29sa9gd8rlc2VgPqkqzhjLSMtjuowYUvbwdT4FyE66NjWVSMwgBPYLWqsps6nGUuiiGAX9m4mgF7BXahB1Q7Q0nPPqd3Tyd9mzZU8KkpDJ7ps8eBXavkoFj/INVD0Q3oT1FJoj7983xdFuxi1Rtb8KTKu3i3cRUVkQMAyILCGCHJM20 TdrRCUEm I6DAJHX5jLso371Qpouaa2F0ZjRuVJjzJgiange/pQbLJabAMtReanjAuG1o0ED5KOt8UO7dP8ibrtA4MK0jt9VngNnnprhvf4RyVL7EUBLaZh8OvAM+NipR4+JfqEUTQ/RpbEuBzkwYKMnVSa27xE2IxCoo4IQZtJd9RhiAxtR8pCwiwsr/byKxx2O3CbSW0DHwYgKM2ivNXJEg2ar14zuGLE6bMb3hVUElYLCOOA8nEGGg2pBaBESLtOHBU0iU7PxBKUoaqkHWg7dwa4s+lOzy6VA8722gystv5gnpqD+kXR4vR1EbA3qPQPOtYnIV2wgSHCzd80yu9bMyxRIodler2p1+Nm+nCX1NJ X-Bogosity: Ham, tests=bogofilter, spamicity=0.161236, 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 Thu, Jan 23, 2025 at 3:40=E2=80=AFAM Vlastimil Babka wr= ote: > > On 1/22/25 23:29, enh wrote: > > On Wed, Jan 22, 2025 at 12:24=E2=80=AFPM Liam R. Howlett > > wrote: > >> > >> > >> We are making changes in this area. Can you elaborate on the 'awkward= ' > >> part? The locking or the tearing of data? > >> > >> The way you state the page, it makes me think it's the tearing that is > >> the issue? I think the ioctl would be worse for the possible tearing = of > >> data. > > > > there are two main styles of use of the /proc//maps data i've > > seen in userspace: > > > > 1. i need to know about _all_ the vmas, so i'm reading the whole file > > and stitching it together. > > 2. i need to know about the vma containing a specific address, so i'm > > reading line-by-line looking for a match. > > > > the former is typically just for humans anyway (to be added to a crash > > report) -- so the ability to sendfile() or whatever would be something > > we could use there (though i've no idea whether that actually solves > > the tearing issue) -- so those use cases mostly tend to ignore (or not > > notice) the problem. > > > > for the latter, tearing is a bigger problem because what does "not > > found" mean? do we try again? how many times do we try? so i think the > > ioctl() would solve those problems. plus it would be a lot cheaper, > > and in particular not require [or at least "strongly benefit from"] > > dynamic memory allocation like parsing a text file does. > > IIUC tearing can only happen in place of parallel changes (mmap/munmap et= c) > by another thread, but if it does not affect the VMA in question it > shouldn't lead to skipping it. If it does affect it, the query would be > inherently racy anyway. yeah, at this point i should (a) drag in +cferris who may have actual experience of this and (b) admit that iirc i've never personally seen _evidence_ of this, just claims. most famously in the chrome source... if you `grep -r /proc/.*/maps` you'll find lots of examples, but something like https://chromium.googlesource.com/chromium/src/+/main/base/d= ebug/proc_maps_linux.h#61 is quite representative of the "folklore" in this area. > One corner case I can however think of is a modification of a previous vm= a > leads to merging with the vma we are querying but even then IIRC the race= s > could mean the previous vma could be reported still as separate, but then > followed by the merged result, so the virtual address range corresponding= of > the previous vma would appear twice in the report, not that a range would= be > skipped. > > But if you have examples of a different experience, i.e. where a vma woul= d > indeed be missing, we would be eager to hear that! > > I think the ioctl interface lets you "seek" to the address of interest > quickly, but I believe it also can't eliminate these racing issues comple= tely. i wasn't thinking of changing the "i inherently need to read the whole thing" uses out for the ioctl(), just the "i need to know more about the vma containing this specific address" cases. > >> Thanks, > >> Liam > >> > >> >