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 D4AF3C02194 for ; Thu, 6 Feb 2025 14:28:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5701E280001; Thu, 6 Feb 2025 09:28:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F9416B0095; Thu, 6 Feb 2025 09:28:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37254280001; Thu, 6 Feb 2025 09:28:48 -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 16F896B0093 for ; Thu, 6 Feb 2025 09:28:48 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 268811C9438 for ; Thu, 6 Feb 2025 14:28:32 +0000 (UTC) X-FDA: 83089750464.24.65AE300 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by imf11.hostedemail.com (Postfix) with ESMTP id 395FC400BF for ; Thu, 6 Feb 2025 14:28:30 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lmFUySMY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of enh@google.com designates 209.85.222.175 as permitted sender) smtp.mailfrom=enh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738852110; a=rsa-sha256; cv=none; b=C/4SfiJk31SwPicRw9ZotdEDKvPpI/A59AU9QaYUxXowlbVYAwSP6kVT67uECTgT0wHmcS d3y8zuXPSY1a6fV1V3wuvacAmPF1/Hj5eCemIvRmDwcF2NDNpq7diGLLZYbv8OF3BpZgm7 pbOMK/eA/SMY5OWlpRzCDDduVFYHORI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lmFUySMY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of enh@google.com designates 209.85.222.175 as permitted sender) smtp.mailfrom=enh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738852110; 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=tksEl2KlAVxEf8W+lYv0ussSoMxCHLsGsx0wrvueTGs=; b=k7gXobEXfu7I6rDjW7LFnB779BBScCvBaxBPd+aPSBCYrXthrf+Cj5RFlfXpzA8pI59tMm bxMlJi+SwrSaJ2dq4Zcr2ve3OApo0b+rkGmIDsnOQSj1XYjpJvTQnt3XuILy6uuxOaQAFx IY+d4boSMK9NXNNlOok7HaKBsnkCFBg= Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-7be8efa231aso81623685a.2 for ; Thu, 06 Feb 2025 06:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738852096; x=1739456896; 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=tksEl2KlAVxEf8W+lYv0ussSoMxCHLsGsx0wrvueTGs=; b=lmFUySMYrtYaYSJ0mWFboLEUtqoV5ch2sIIkKWv5NnnlMTSQfMZrb5u+8KIkgIfjvr fFwYh6qjoyx9l1iXuTjcKMLNeM8VCYIo5S/D1eaug6iwP6y0s+z654In0l4L50rVbuaO hRAp79DpYWSMN4er/bGMXjWWKbuwGlNzp1bTbX+xIjMKm5T/PPQmw6r3+7iZ1f6Ytf6t iOvV3Vde08yi0BxfeWQWBXlaPyuzZOq5aDZeSZq7Hqx7YenF5yhwh8e0wqaDUv0B/j0+ A1762nm59zv+Flkufo2xP4IT19rZ7Lva3/bioikWUi1h9EjLtLdeqcv2tNQcETDhElut 16Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738852096; x=1739456896; 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=tksEl2KlAVxEf8W+lYv0ussSoMxCHLsGsx0wrvueTGs=; b=d2b4r1tupigRDlrCp6UIaL2ViWbnE2ShC5TAIlKuAGymOlvFVTZqKh4O+g/FkjXxmv 7eCsD5n1oI+s1Vgm9Nl5itmsoa/7bq+F3PDw51pbtmSQWv4mCM4sYB0goVOjcIlnfWr4 CO10pzqCWxKEMbBepU0NhLX3GpIk+AUOA4aQnd9Ml0e5Ii5D2CtOWAeJKBjd/Uvu/rXe jmCQ0WOhTXtEryr5zlZjcWc5cMDkqMym3AuUFW+MGTCcBSyvbaT0swHt/F8LrsUX+bYv BXqkxy57RI8XJfuFXRcb57yRP39TUtNwqondOLiarSm4oSykHvv5vb6yI/7Qnwjd1wzG 2VQQ== X-Forwarded-Encrypted: i=1; AJvYcCWeIyrg4NeXiHCAl0EG7rVtbY8X7k9biiInNfMzRzi3bVrMQsGU1ViLfa+UkDJFwZ8GIjypHvWKTw==@kvack.org X-Gm-Message-State: AOJu0YxtOOerPEMi0HAKmRXL0mh3PJmd9Wll9uce+J/ywJGVxZ1F1F3h 9qxJL546KhwYHTGhnGucLltZZ8uDjorjpLfbsC8xJaKd+UERiZOvdanpwYD8cEcdS/CIUCEsa81 LAX8xVyNXU8DGhja+qg+6W4b1z/ehuSdJzGonvFBQYeTiYn5rlvf9 X-Gm-Gg: ASbGncuXAwadGO3YO0SFY9ioUH6A0q5Ex890VtZkyScVK0JL0F1W14fQ3QATQIsrIns 6XFYbFJhesHCqlCKiIl6a0RF/jEIWR9kal5/AAZdtd78j8Ap+MDrSV2LNS8Tj50CCbvLYXg== X-Google-Smtp-Source: AGHT+IEfLHpnvobMcgVrLSNbsfNw4AFRnCPQWXFAu2fq4BUPy8NoWcDtZg+st9iEyOh2nL29zJbCH2+K927euTM+iyE= X-Received: by 2002:a05:6870:8188:b0:296:fff8:817 with SMTP id 586e51a60fabf-2b8051adbd4mr5104149fac.35.1738851563761; Thu, 06 Feb 2025 06:19:23 -0800 (PST) MIME-Version: 1.0 References: <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> <881c3558-1101-496e-9ef4-5bef13f3f233@suse.cz> In-Reply-To: From: enh Date: Thu, 6 Feb 2025 09:19:12 -0500 X-Gm-Features: AWEUYZkbH44gyYIM4OSRYeiM_40wARCJ9iHWw7ukWWa1MTVZt14y_2GEShpURoo Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Matthew Wilcox Cc: Vlastimil Babka , "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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 395FC400BF X-Stat-Signature: nq7xzw5jrc7hxxw6nmi68q7k8jaemh58 X-HE-Tag: 1738852110-798219 X-HE-Meta: U2FsdGVkX1/Ados0bJr/R4qF+R0XeGqx7z64RbXTtcGQHMB/R+9qhcjY4dODrHPQCkiblNDDLbztYUKp49zCLtJfkUrQfmU9slIMurInJM+fj8mPELg2Cl0iCjQ/32uVevWbGt7Q58m3SiQJXCCNKQ8K/gl+r0y676cVRBmoMWNi3aAaO4+7TPMx5LqbltLtd9WwXqVzlY2xnKFDTDKGK5OYwAVpeOdUZ1/qxvpfQswp0TOZI8IjyzyBAewzHmwqddQh2p5b8eS3GPFD+1UX7eJGwqt8oizTdJ7DLGP4qfGLH4yWG2u/+ltQmDTdU0ocY1nd4SgBQmj+fuZnyNILQ+/yulrqEBiv1kZ4+rG0zOLz0zMKKh2lHJKKczmhWANvCKjsBmnbnD42ZZV8zTBuQ4QCcHGq5bYYmLIguGlAUv0m95S9PVxMdGS2CxEHUU3JNnPVlgRbRcDo30tpuODOmOacE+eA1L+jz23PnHtzvpQEl5q+EeC3sf2k/wKJXDHa14seAz5W5We9OT9/cI2GQ3tVAXbyexcsEK2CfHSmypFPWr4EUIbCoIJWFiOlnpjQcfmRQIkUqk0QuLqHiCaNrxom1t1VHcCkODg7AQ0PGF0AP0bQRyn3PtVLJPA5HOiW/4KiN5ivPlprugtX0X2xZSota0Sac7Z+emGhoHIx/LijyMe8/xwNctpgaj9D/Nq+q+oeAeSW24th+c2di7G3a0dztjM9hxAWYPOunyfQ71RQyjswWn6LUbkCiObPNTR2MY9Xp5d2O0eDu1gXNMxkM3RM/4wNhO6UF4wPWm+Om6OPBdfoS0vq93kBzLSVaEPqaQhukDPcI8zEuiVL4xfhYrZMgd0Muavt5iYBgYsnxxqv4DjSBGKZFz26GayHHEfvcvlMAV9z4KaSFfUvJPx765xJfAp5lKy3rhnnutz+cBL+wHSW1ina9NsxNz7u3vyhdTKYRPnc4rz0aJVcLaB 2Hb6+sSE 8yzGYDVn7PcCmVbOSzNjeqL/7K6xnEatyMOJd3qJD3pdGBnXdJBMqhnqADerU2Z4FSbQDM007WfEN0HXYoF2dSJwAdlfLdcPU15M7JpZe2+e8MfSxklicyPYSz/H+sP5lEKcs8oegngr3iG7EixjkdxArP6qJnCbf4NjUkEXlzEHOwxqjsiBvQrZDi64imxLB8NnR00WplFGx4HCGBToGIpdhFhax658dWiXJYcl3jWcb63LWoWQ4NdKY74DfOrvouEleDXuB9w+R92LlBaRRs/USZbKUWwkL0wM3e2dYTmoCKvYOgZFKyybsXklv04ePEjChHXI9xL/Ei3u4k+lRv4rCjYdBgbRtK350icBRBNoQ6DMzoxF31Qn23XAqkptIdJAJ X-Bogosity: Unsure, tests=bogofilter, spamicity=0.464864, 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 5:38=E2=80=AFPM Matthew Wilcox wrote: [heh, long time no see! haven't been on an email thread with you in a while :-) ] > On Thu, Jan 23, 2025 at 04:50:46PM -0500, enh wrote: > > 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/ba= se/debug/proc_maps_linux.h#61 > > is quite representative of the "folklore" in this area. > > That folklore is 100% based on a true story! I'm not sure that all of > the details are precisely correct, but it's true enough that I wouldn't > quibble with it. > > In fact, we want to make it worse. Because the mmap_lock is such a > huge point of contention, we want to read /proc/PID/maps protected > only by RCU. That will relax the guarantees to: > > a. If a VMA existed and was not modified during the duration of the > read, it will definitely be returned. > b. If a VMA was added during the call, it might be returned. > c. If a VMA was removed during the call, it might be returned. > d. If an address was covered by a VMA before the call and that > VMA was modified during the call, you might get the prior or > posterior state of the VMA. And you might get both! > > What might be confusing: > > e. If VMA A is added, then VMA B is added, your call might show you VMA > B and not VMA A. > f. Similarly for deleted. > g. If you have, say, a VMA from (4000-9000) and you mprotect the region > (5000-6000), you might see: > 4000-9000 oldA > or > 4000-5000 newA > 4000-9000 oldA > or > 4000-5000 newA > 5000-6000 newB > 4000-9000 oldA > or > 4000-5000 newA > 5000-6000 newB > 6000-9000 newC > > (it's possible other combinations might be visible; i'm not working on > the details of this right now) > > We shouldn't be able to _skip_ a VMA. That seems far worse than > returning duplicates; if your maps parser sees duplicates it can either > try to figure it out itself, or retry the whole read. yeah, fwiw i can't think i've seen a case where a duplicate would matter --- half the code i've seen ["tell me more about the VMA containing this address"] would just stop at the first match anyway (though that's exactly the case where i'd rather have "direct access" than have to search), and the other half ["give me a snapshot of all the VMAs for offline debugging purposes"] doesn't really bother with interpretation and leaves that up to humans.