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 046E9D3C52A for ; Thu, 17 Oct 2024 17:35:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 884326B007B; Thu, 17 Oct 2024 13:35:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80CD06B0082; Thu, 17 Oct 2024 13:35:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6869F6B0083; Thu, 17 Oct 2024 13:35:43 -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 471696B007B for ; Thu, 17 Oct 2024 13:35:43 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5FA3414024D for ; Thu, 17 Oct 2024 17:35:31 +0000 (UTC) X-FDA: 82683796272.22.44D7B75 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf18.hostedemail.com (Postfix) with ESMTP id BAF031C000A for ; Thu, 17 Oct 2024 17:35:36 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VspOET8H; spf=pass (imf18.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=andrii.nakryiko@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=1729186347; 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=9cRq+JMgpIcPa51fjgQPc9Xd4RyxDQLcY0GP4aMUeu0=; b=JNDbgpAo0F4ZT+WqCXU8Rrp4nnKaOYOKKNy48LnwMFB8uF7Dlqmbrm9aeTUfzn+/Z6VleS Mb3RFBFwnO/ZWAlspG6GDcnfFwYzLuInQLzTnF/X07ppEARuWRnbrL63xrqOT23mlMS8ki HJXxS8Ha19L9DvF13Po518OUxV2ITgg= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VspOET8H; spf=pass (imf18.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729186347; a=rsa-sha256; cv=none; b=ppzD3z9eO2MgYqxtu5HmEG0tvUWbzCb6E5RnwPPu8kDpzuvHxJvExpzV4wrx2BfH6dcPzj gHmWoU33K9aoB1go88Bb7xPzbKYMV+FgHeQOSz0il6fy7mtQu5T4Pua57GLqzRRq8N9V7u dHUxSj+JhSn0rhTVZhlNcliAEMIfJzM= Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-71e585ef0b3so1006209b3a.1 for ; Thu, 17 Oct 2024 10:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729186539; x=1729791339; 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=9cRq+JMgpIcPa51fjgQPc9Xd4RyxDQLcY0GP4aMUeu0=; b=VspOET8HcvH6MSOAz9mwGHPS29dxJ85XBJU76n6D/4Y2Lf7HTJtkgD+A2i/7icXF6R ZII5wafPUM7x+o7zcy5mvmFuiAtt0oPMQRx9//OshvKV9nErgLuDBMjJxiAMOhlqwau/ Fp3NkxKu0zgy0/n9uTJBZNr/mYkuvrTF9MUWon5fHPChGF/M0CobrXDVyqUxLNet3tt8 QwubDdBhL3WIJvjFeiCGPHrYWeSxy5oSgTo1ac8YmU8XodQVMfbB55BlfxOmHxelPJXN auO7N9CXeZ2IINWoaGg6Re8Bxlz83RYJM8NT98d9HKXbuYMxgJF7m0bmg0AkZoNfEp6Z jfQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729186539; x=1729791339; 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=9cRq+JMgpIcPa51fjgQPc9Xd4RyxDQLcY0GP4aMUeu0=; b=fthynndwVyfpb4kVWfSYWnR4Clvb5fRHolTOpegi7eEMq3YaduFBFqpgIBYXBTOCSY VjargG2MLrKZBsVxBsnC72E1QBIi6lMqY7vw1T0qDdhloPqosBtoJTA5DYEqZDZQdJqt MUHcs0gaKYKtkbzuTxo3igF8JzWCIcv/yetdpIYG4udc6TBP/jgRgqFvJCYZeQDqQY34 H4QVNy9QEj0xfGtT00APC7cFd7Ervmoyz2AYNZHOxoeEt/ngazQBFlfvc4e6DN+Uqhc3 dwKG6CV/aeTpohBU09DHnt6OP4Bt9qwJUZuGFEmIvhxQRELLCAXHz5TTtXTU+nAtHx0C M8dg== X-Forwarded-Encrypted: i=1; AJvYcCX1tEHl1DwqL/p5pjc79tzQsXR6meLOIMYbI7iTvGVbrF7cFe5pf25EM0D+wF630MUof0T4ztsTug==@kvack.org X-Gm-Message-State: AOJu0Yy3A6PoO1SpZYVBEBtLr17ClfKxDjUCOAj2mGUh6WBMcPEZ5akz woOl36UxP8cmqLlHaQsVEJODXHhQK3x3ROPy7CYwlS5CwPgU42CR7Gt8NBfOLbnmDcSmgkSPuU1 +fIoaD/rbOxxK5Ca76OxZ7vTWO6SJrA== X-Google-Smtp-Source: AGHT+IFP1gS3BVli/9MbbFfT+uorzh3EZH4kvMyHBWdsERzNNEba4MsHj8+B6NXGoSl6fFdb21qxBv6QIYAYLHs0xHI= X-Received: by 2002:a05:6a00:2353:b0:71e:59d2:9c99 with SMTP id d2e1a72fcca58-71e59d29ef4mr25732384b3a.4.1729186539552; Thu, 17 Oct 2024 10:35:39 -0700 (PDT) MIME-Version: 1.0 References: <20241016221629.1043883-1-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Thu, 17 Oct 2024 10:35:27 -0700 Message-ID: Subject: Re: [PATCH v2 bpf] lib/buildid: handle memfd_secret() files in build_id_parse() To: Shakeel Butt Cc: David Hildenbrand , g@linux.dev, Andrii Nakryiko , bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, martin.lau@kernel.org, linux-mm@kvack.org, linux-perf-users@vger.kernel.org, linux-fsdevel@vger.kernel.org, rppt@kernel.org, yosryahmed@google.com, Yi Lai Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BAF031C000A X-Stat-Signature: mj9ammmipy31gybd6mw79k311cnhgcp9 X-Rspam-User: X-HE-Tag: 1729186536-338725 X-HE-Meta: U2FsdGVkX1/Y7jQKX4QFfBbEdTE4yiJWbiKLkHe+Jin7Th39CchUbCQyFEAvvcPYXXLrDMOBeUES6LudGXWjByzpUIN+tjsjUncA/Wu0Q9NeQVEr9S95XazV1OizRl5pM19ySEMctgG2XPpMGIhf/bGAgsKONl44pAeqESJieVfN1opWOXW9eGhQZhQQLgwVLpCMHnq0+GZL+6gVCojm2NHtNUpcKNLXntuaWwavcyr3TvXROlwl7REAr/VHklJTPiOBuzalPcKOHApbSSRwvS0kt0mdEFX46qg1VedNEq0hooFvaVOo5hvgULOZywqBVFgv1Tdx2lwU0s7Z4yDhu6yZHEXdnkwGJQzngcD+ERbBo6kpLsWZA1g8rxNcAYst5665AvRezXzSIlAfDtk4tpFlEd8FoyTEFkT+6d/2RBxkbp0S8R7UXUQ7OVuOkrhrqz8lfDwP9QwiO2PiwdZAdftl8KQpkHZUWVWp8bYRi8vAoXhM2QXmvBU5FdWSzyqUNHqoLS9uYD4YyUe4x6ina7sjGXi4TeXVNW4HelwFissR2b1kUIDpZjAENS0BKk+UjPc0dQE8yOvaocHg2kg/Nf1tOuqx9hNqxEaCzeumbyYg05wZUG8Ye7IHMnd21X/uq4e2BFETpoGnmPW3cw9i/vgC1t+Dk0KBRiNQa/8d9yjS6mbFny9aNYpP4VFdHkCWDqwaoRf38ZI1W2eeRjO+QqHrR8K/iuQ3JJZo36tFX9qEmWIEb+31cjN8rvD+XATVr2+5/5Zxj6tjeQiWVNzagKskGTc2U+5X+kuC6pIEzqYSbn3mIl8x+33c+Vi6B2fNgj4445b5WavpjcOcLZzFfLAyIhcTd21CGkQ6XYzUYpVWabNsTZYdSAfC4BCgD7Pns7JaZcwHncZcqxLEHApeF/CoxV61IzZmBGgmHOs4y04JTjpTWTFphWCUzrhcddKzlDJsGwIqBmsE3RG8/TP QMfDpjOm GPl8xkLGw4Oy5W057lJux1Y45hNfIREHfeHy4T/Hnttvx1Pq1s1u4Enq8Cj5bJIDtnAC0GAhdVCkaoD1clw1l6k609YI7Fk7m4wzDzC8NFIJ+RhfubQZpOuH8wT48W/0g/ppkADUNJTmK17FJYDbFOEn6OQVx3Bw2TNZ+WiDdYtuAtMNWDfyYeMkbnSEco6SVlJnWGD8oIqpVdipd5x3MS0qMGXO0nl/pbI5Cunf6+zve/wjRHSoVK75ynyU11e4u5M85oDGuMZz91kZTTZX3qd7W4PjwhvXJD60uFeDb75EBvAXzJoukjqKdOUHnCZOl8WbEq2iL/I5tjIcvJhUyaXAp1+4WomlQXDCJz4n7NxhU7LTGXWMWPqmSRhBYcybh/2t8Koo6uoWOD+vIIesGOs+fgMfxuvsAal3mORJDkbi36XRbDDDnxT8K/PwSJNyfSrEonXOREll0l0M= 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 Thu, Oct 17, 2024 at 9:35=E2=80=AFAM Shakeel Butt wrote: > > On Thu, Oct 17, 2024 at 11:18:34AM GMT, David Hildenbrand wrote: > > On 17.10.24 00:16, Andrii Nakryiko wrote: > > > From memfd_secret(2) manpage: > > > > > > The memory areas backing the file created with memfd_secret(2) are > > > visible only to the processes that have access to the file descrip= tor. > > > The memory region is removed from the kernel page tables and only = the > > > page tables of the processes holding the file descriptor map the > > > corresponding physical memory. (Thus, the pages in the region can'= t be > > > accessed by the kernel itself, so that, for example, pointers to t= he > > > region can't be passed to system calls.) > > > > > > So folios backed by such secretmem files are not mapped into kernel > > > address space and shouldn't be accessed, in general. > > > > > > To make this a bit more generic of a fix and prevent regression in th= e > > > future for similar special mappings, do a generic check of whether th= e > > > folio we got is mapped with kernel_page_present(), as suggested in [1= ]. > > > This will handle secretmem, and any future special cases that use > > > a similar approach. > > > > > > Original report and repro can be found in [0]. > > > > > > [0] https://lore.kernel.org/bpf/ZwyG8Uro%2FSyTXAni@ly-workstation/ > > > [1] https://lore.kernel.org/bpf/CAJD7tkbpEMx-eC4A-z8Jm1ikrY_KJVjWO= +mhhz1_fni4x+COKw@mail.gmail.com/ > > > > > > Reported-by: Yi Lai > > > Suggested-by: Yosry Ahmed > > > Fixes: de3ec364c3c3 ("lib/buildid: add single folio-based file reader= abstraction") > > > Signed-off-by: Andrii Nakryiko > > > --- > > > lib/buildid.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/lib/buildid.c b/lib/buildid.c > > > index 290641d92ac1..90df64fd64c1 100644 > > > --- a/lib/buildid.c > > > +++ b/lib/buildid.c > > > @@ -5,6 +5,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #define BUILD_ID 3 > > > @@ -74,7 +75,9 @@ static int freader_get_folio(struct freader *r, lof= f_t file_off) > > > filemap_invalidate_unlock_shared(r->file->f_mapping); > > > } > > > - if (IS_ERR(r->folio) || !folio_test_uptodate(r->folio)) { > > > + if (IS_ERR(r->folio) || > > > + !kernel_page_present(&r->folio->page) || > > > + !folio_test_uptodate(r->folio)) { > > > if (!IS_ERR(r->folio)) > > > folio_put(r->folio); > > > r->folio =3D NULL; > > > > As replied elsewhere, can't we take a look at the mapping? > > > > We do the same thing in gup_fast_folio_allowed() where we check > > secretmem_mapping(). > > Responded on the v1 but I think we can go with v1 of this work as > whoever will be working on unmapping folios from direct map will need to > fix gup_fast_folio_allowed(), they can fix this code as well. Also it > seems like some arch don't have kernel_page_present() and builds are > failing. > Yeah, we are lucky that BPF CI tested s390x and caught this issue. > Andrii, let's move forward with the v1 patch. Let me post v3 based on v1 (checking for secretmem_mapping()), but I'll change return code to -EFAULT, so in the future this can be rolled into generic error handling code path with no change in error code. > > > > > > > -- > > Cheers, > > > > David / dhildenb > >