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 84877EE01F6 for ; Wed, 11 Sep 2024 00:28:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E74CC8E0005; Tue, 10 Sep 2024 20:28:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E24F88D00E2; Tue, 10 Sep 2024 20:28:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC4568E0005; Tue, 10 Sep 2024 20:28:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AB65C8D00E2 for ; Tue, 10 Sep 2024 20:28:01 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2B72CA0D88 for ; Wed, 11 Sep 2024 00:28:01 +0000 (UTC) X-FDA: 82550569962.15.CAFD412 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf09.hostedemail.com (Postfix) with ESMTP id 5C51514000B for ; Wed, 11 Sep 2024 00:27:59 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="b/l4Fbhb"; spf=pass (imf09.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726014427; 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=4G6htZmT/2OcXeGPBRBMMe5AADfAbOwvpNDLSDJ2pR0=; b=n7TIwFCwycWoJf/ehJjtW7g4Tn2UQ5OLQNY/va7x4XGSunvzI/BHpsc60ogFEJnQRHQ8Te 6gVZnNNoG9I4CqVCZJ5415AMyt9ROdJyhwmwuKQbMSFesVb/MckH8t0N/ltHwW9IYYZvky qfqn5NkZL93D7sqJw2fGymiq60aEb9E= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="b/l4Fbhb"; spf=pass (imf09.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726014427; a=rsa-sha256; cv=none; b=epN3GK2HWy27EHE+6Qx6SDiiv0JEHSRUuuJPWeByrMGFIYjRVtnlxv8exoBKRddG0D1mEI 3cJfS31VZLYSQyeoJLU7bbzHKakqxrFClM2eqG0P94C8sjYXU2B3EUi46TaV5Kk9eLvhmP OUs/kF470PKccLTPenhw5D5RnUPMvd4= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-42cb1758e41so32245705e9.1 for ; Tue, 10 Sep 2024 17:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726014478; x=1726619278; 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=4G6htZmT/2OcXeGPBRBMMe5AADfAbOwvpNDLSDJ2pR0=; b=b/l4FbhbSWzxlTNWXtfR8oPBVWPWB9ApqOsRSVxVkGMByo+iqASIt0zw/Cu1hPyu+i TGL8YGhH312uzlc0Pvq1Gj63SbgaMR5D9y83Y/405Yzh4ZAi7G/FjLOUjVxJvZt13eY8 0ZoAFwEqkighJhk8Q/uH2bgoJxZv/xonxIRZeH9CKqgVPtRlNi8nlH1VHrqEG10A3inP oOhMBNueS98TEap3dZOUE3dltIqL6QghoaDe3B6DeMH81guQ7JC+YiHVaeZYI9PCxjq8 luOL9cgyf/zN1soQ7Gjt/WxHAFpIH0gMLyt5b6n42/jExRPkuMMpDt28rfcdF/tzlOdV 33bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726014478; x=1726619278; 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=4G6htZmT/2OcXeGPBRBMMe5AADfAbOwvpNDLSDJ2pR0=; b=LgDAJsKrxrJAMSCjTeSgY74rxBU9P849IuEjmQYNLtCF/hxU1GIp2RwaEoxg+Fc+hj h0Zu8AAMqgPpr2qbYVTvKJP54QK+cdy5bZ2d0Y5wOgjxwDC8r/EJLtAc/Ja7Ab34V8se aw0gE+WK3MY+KarNjhKX09j5JDBmh6Z/NsJOZDkOYbqoUlA2m3N1G5S7rjsBZIWdsH5F LkrxnmPcsNWAtb8PiFZ7dBLwhQ4DjlR2Ga8A/oyMvG6nme6C7d125knEqjgkFkIDTzfx RvmxhnNNXDCR2M9asWA58+DviV2LxTQNiN6SD28f9Xs+xicLFXbTd3ME+UmuzwLcWQap 2y+w== X-Forwarded-Encrypted: i=1; AJvYcCUdOimt2+ypILTB7JtGdGlgS+U9cUOCBkM9rSRh5QeubKPKbhN9j9jIT0pjgHe4OlkfEwP6XG9/qw==@kvack.org X-Gm-Message-State: AOJu0YwdfwdSBVx/Lp1jP7BLiT0hFcmTUNDnZG8kqnScIcq0tnhrzLti YrKZN+VueUukfbJrqZ6yEEeUaK6eJy6g9YrWC81tqA/2+zqHfmS5sGJzx4nvdbIDpVzzt3bGLoq 6cXNGWq+zEe7bKpwrfHUceW1XZsQ= X-Google-Smtp-Source: AGHT+IHwJFWF6RxNiu9vVCXQmuzDa865/DIVQv/Pt4mgdRYAXkfoTXIAxRs5nhL80CtYqi67RErDr704Zfs90RK9RUA= X-Received: by 2002:a05:600c:4451:b0:426:6308:e2f0 with SMTP id 5b1f17b1804b1-42cae76cfa5mr91418565e9.26.1726014477550; Tue, 10 Sep 2024 17:27:57 -0700 (PDT) MIME-Version: 1.0 References: <20240829174232.3133883-1-andrii@kernel.org> In-Reply-To: From: Alexei Starovoitov Date: Tue, 10 Sep 2024 17:27:45 -0700 Message-ID: Subject: Re: [PATCH v7 bpf-next 00/10] Harden and extend ELF build ID parsing logic To: Andrii Nakryiko Cc: Matthew Wilcox , linux-mm , Andrew Morton , bpf , Alexey Dobriyan , shakeel.butt@linux.dev, Johannes Weiner , Andi Kleen , Omar Sandoval , Song Liu , Jann Horn , Linux-Fsdevel , Andrii Nakryiko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 5C51514000B X-Stat-Signature: pji6bmydqhopkc4gaqj4umukj3yjjy3g X-HE-Tag: 1726014479-964105 X-HE-Meta: U2FsdGVkX18JgHXTO1q0LsaGG6d9l0x/SWcuKhTFHQpZn9tzLTUFCeljuN8s3mhjhtV5Vu1SyhbPpc8GZBxCeABkUXDFWauxWPHt2s7xMTc7ILSAUEgwcivJ7WCksti/DN/j2s+boSZyYWEVNh+ppyCjZY0pOjhFSEx5zQGpQ3XZ4pICXMegAFTKR3Lktv0mW5eGY/ZZxe7TJUEQRqjB4R04ESmHbboc2tbCVaGl4FAaVEbqB3uatCo80Y44IrgV5c3OLAiHGGeCdVF29o4stgJBAOiMSTx2ugz78Ydflg+Z3zbEMph1MBbMhALZPp9SjaGJr/24o9o8F+LcupUIrXswI6Q5MqkX9zG+Z1+WkpSgXcQ2lKeaUsUvAEsfjgJfMOxj3FZp/8WQdKrycCqyzXNlLbvcdC/yMlW3i8jY1IKHk+HhK2OWJwiuzep3II8NJmMKhVl5LpbkP0LRnAyHlC6iGfMG/GwTRMrsNa7MBX49S345Jwo5P6RqVMAsFdxs+YaJPzs5RHEvGtTMh8Cq1XSOpoavC3PI8ifxDxSpa5Az7E3ee9BedKaDmCyG87Q5zXaaTrBllhGl7ohi/AJUNL8VzVVFaxtuJYF4tzEs1zigW4V5FUvS9oqIf30qDLFKmZsdDYqie2NufbxYgSHOBwQqhZYjv7Yi+IP9h0FyfGVY0O2WHSdf73OL6fHp5DLFv1xL+RU0hPB6VDYmKdj0H8mUyR1nIqqVKmhJPH2FFZJchFa0UD0Mj/LVxg5uVCreW+h5G4pv5RGg3m8mpnO+UP5GwscWnwDlrD4DO9IOs0n1A9GSxo58zBVGcEEGmc8yFo8xR7x8azoDiC905jb7OUHfGKwsg+OtJV/oGjvM+0aSOs0pgul6iiNrYNddOzL+m3rXldaWfTPzHl7w3AbT70OaAOkNiwOQdnYIVf7Hi/J9w1coj+CVDMNa5HDq90IDtFvUz8kTUgdZmiU0K5Z Kug/TPZx fXIX7RA3Ri/YPk9kK0EkTcFLhAsZZNgh8tBOirWRSTE73eS043OqoTpEFE5Bw0k9I4xPhH4+TMKEu5zfJqTpqYtRq4s7Rlr+kRqfSLnZk2rknQuMakj4hzObd8iypuaDMbhV4ztfpRRNfB47Luc1Rfcv3yfLpS6/NbUE1vRZufrcXBN/YdKHqxp3Osnak/1AMt14vFLrbBf3zisX+BoYDOvZkVMmaBZdUfNs0MYSlIVsjuRX18gGvvkKweOY0NoUzMad2JTzSBFR1aSbDvYUmCgC3j3+9fOpH/7hi43Gz1FOhq/mw0TNa1RBHQ4fRJJHv5G0ZEaAwGtn74A3JsuuyLdXf0wEfbTycHRYPn9em6xecU59ehVLOlicQYjcwTNVx+HB7+uwKoHN5f5WovMTbKQe9zVrhtYE2uL/e5AB4t6GZqK2HslGsfalycHTs0xzOWu1ISh1et8uWwajbWt9ZRfUpc2PLHs7KaeBT69WQeqh04EM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Tue, Sep 3, 2024 at 3:39=E2=80=AFPM Andrii Nakryiko wrote: > > On Thu, Aug 29, 2024 at 10:42=E2=80=AFAM Andrii Nakryiko wrote: > > > > The goal of this patch set is to extend existing ELF build ID parsing l= ogic, > > currently mostly used by BPF subsystem, with support for working in sle= epable > > mode in which memory faults are allowed and can be relied upon to fetch > > relevant parts of ELF file to find and fetch .note.gnu.build-id informa= tion. > > > > This is useful and important for BPF subsystem itself, but also for > > PROCMAP_QUERY ioctl(), built atop of /proc//maps functionality (se= e [0]), > > which makes use of the same build_id_parse() functionality. PROCMAP_QUE= RY is > > always called from sleepable user process context, so it doesn't have t= o > > suffer from current restrictions of build_id_parse() which are due to t= he NMI > > context assumption. > > > > Along the way, we harden the logic to avoid TOCTOU, overflow, out-of-bo= unds > > access problems. This is the very first patch, which can be backported= to > > older releases, if necessary. > > > > We also lift existing limitations of only working as long as ELF progra= m > > headers and build ID note section is contained strictly within the very= first > > page of ELF file. > > > > We achieve all of the above without duplication of logic between sleepa= ble and > > non-sleepable modes through freader abstraction that manages underlying= folio > > from page cache (on demand) and gives a simple to use direct memory acc= ess > > interface. With that, single page restrictions and adding sleepable mod= e > > support is rather straightforward. > > > > We also extend existing set of BPF selftests with a few tests targeting= build > > ID logic across sleepable and non-sleepabe contexts (we utilize sleepab= le and > > non-sleepable uprobes for that). > > > > [0] https://lore.kernel.org/linux-mm/20240627170900.1672542-4-andrii= @kernel.org/ > > > > v6->v7: > > - added filemap_invalidate_{lock,unlock}_shared() around read_cache_f= olio > > and kept Eduard's Reviewed-by (Eduard); > > v5->v6: > > - use local phnum variable in get_build_id_32() (Jann); > > - switch memcmp() instead of strcmp() in parse_build_id() (Jann); > > v4->v5: > > - pass proper file reference to read_cache_folio() (Shakeel); > > - fix another potential overflow due to two u32 additions (Andi); > > - add PageUptodate() check to patch #1 (Jann); > > v3->v4: > > - fix few more potential overflow and out-of-bounds access issues (An= di); > > - use purely folio-based implementation for freader (Matthew); > > Ok, so I'm not sure what one needs to do to get Matthew's attention > nowadays, but hopefully yet another ping might do the trick. > > Matthew, > > Can you please take another look and provide your ack or nack? I did > the conversion to folio as you requested. It would be nice if you can > give me a courtesy of acking my patch set, if there is nothing wrong > with it, so it can finally go in. Looks like no further comments from Matthew or anyone else. I'll take another look through the set before applying to bpf-next.