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 99A25D3C522 for ; Thu, 17 Oct 2024 16:35:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E26AD6B0083; Thu, 17 Oct 2024 12:35:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD6ED6B0085; Thu, 17 Oct 2024 12:35:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC62A6B0088; Thu, 17 Oct 2024 12:35:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B13856B0083 for ; Thu, 17 Oct 2024 12:35:44 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1F953121555 for ; Thu, 17 Oct 2024 16:35:34 +0000 (UTC) X-FDA: 82683644778.20.0391354 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf25.hostedemail.com (Postfix) with ESMTP id 4E133A000F for ; Thu, 17 Oct 2024 16:35:35 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ScJR6ayF; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729182894; a=rsa-sha256; cv=none; b=xxUZiTlCtVDrRLw+Oqo0xjcgH137Hj3FAB5AiWHz/L3AgXt/7Drg2AQUIRR92Ycd25JX+K BXr1p52cbi4wvoQkhvl0oJdHgw+gkBor5KKiYPABoTvoM5cJ7By+7tdJVMvoOwJkb/mx3l tRPyEsvJ4T3RElEt/HSkSyAxvx9iUsA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ScJR6ayF; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729182894; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uv4u/dmDTQJhJoxVvRtBaO6HLRbACzvQxs5bHjLIACw=; b=gqviwC4jFviC7vT+ResAgSGFw/i9OOSy75v+yQdzyPoKV0BU6yPU+QblI/bmD0JnkasjJF 9Wj/3k5A149qsgyQuKvd4X0cOBI6G684YQ6jKtUhXn96nvvWT9ArUL1mrNQsZUSnmVW8pp DaFzt16XN4bs1GTNrfsRCX5NHUp+gtA= Date: Thu, 17 Oct 2024 09:35:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729182940; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uv4u/dmDTQJhJoxVvRtBaO6HLRbACzvQxs5bHjLIACw=; b=ScJR6ayFPyLgeWRn4F5FTI6XN6xRijnlkjHUdIvQEfwkDZx8BgeDSaUof4NZtSP6Lpoqdd nqqyColVTwsmvwl2sYQy3h5y+KqLBMoszqHpWe2DSSUDktNroHVLwc83Zy3XEmGmoFnauU a63TZ/9zXeaSeMUy2Reu3B8zB/wgfss= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: David Hildenbrand , g@linux.dev Cc: 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 Subject: Re: [PATCH v2 bpf] lib/buildid: handle memfd_secret() files in build_id_parse() Message-ID: References: <20241016221629.1043883-1-andrii@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 4E133A000F X-Rspamd-Server: rspam01 X-Stat-Signature: no6a31s9jopp7at1f8mmz6s3ha19wh4h X-HE-Tag: 1729182935-752711 X-HE-Meta: U2FsdGVkX1+C1F3i/gueBUpifNha4Zbs/NhDtG7KG9WzF0yV/OlwC0iPCVfJDNGAwUyklfAtaLk7h98RzuOBM4JA9ARvq1vbr8bvBpE5p9v/R6pbGEjeiU+IeboMtYOSn41/4TWN34x/3o81+GQ/SJe+lpuO0WwzrCD0tdQiUavcN43VZtAa0yaGU4inTacefOMZ9LucPxq76wTofqKgmpFQTeOQqohAm0vdxGd2UqJNkRgJRRCwidJwmegXuyRR6mNVPCZFgdVG58KGUVBCLXJu9yb1A2af+NBstFvyESIP551ysAZMsvLwxb1kzU7Fhj1PuIdQWwTQYxMyHqQQlhd4Dx9o3AWVng8blHJXpzqphf7t0gh3i2wnpekbckgtOyEXcVaBoy1lfGU200FpxqYKr0L3/RW+jmYhtOvHKLbnYLE19V4xq74uglE7ylDMT/tXuc0hTQr9YYem4xE2TLXW0qesW0fyvoCYc5ZqZ4yQHqDtxKqV3TpnqJ2/Z90+BiGVApzrMyJEN+F+eEsaAPq7zQiWVxmDq/b5wAR96ar9gaSVIqZmxc3SToF1hjmIK6oZ5l0LG2aJCbkg2BpUKAqYw6ndlqQQnR4mQ1w3rzUmRpTr6UieeBvLpOlFw7DUc4krcqKEYRte373gpAenlpLJnbaX+HhHo7NDBhqzz5h5bPI9zvVJbkslAiQSOx45SFBegLpQ19bd0Wqoc3Hjle1eGe5TuMytuqWWWUex/iDX7COhz6cXj5Plwfj7z7+UuN/9UMXwBtxemhjMpmz/wIPaQ2lhGsFhZ4iFXGhOqDUwU+b0AfCLEoa1Qc0cNKMZEL9GkaozuptEmFtSsCy0yh20IyOOSUPCGMIPnrb8/Ldu3yOwNQmzwJJl4a4OVBoJcOg7pQqyHMfBsi+pMiS7ORmZw3Us3SRE/fxGTF19gVhpuJvYt1PBm3bidg6PLfopKlT1NoKabRVUOZIdhs0 XG9x8rr8 E3EVr6wXSVonlKj0Um+O0KGMwikodoAmTDTxfg1DdqsZcwoe+UGvB/TbxX7SCJIIKxarRu+usxzTanjpegf8eu0kbvIRbOMRtQ6qh+MuBb6B1KxkACiKXHAl3Vu7Hj0mLm+uW7LkY7X+iot77PZL2TCwpb9NqzY+KHXedk5nYLOWiFSSgrcE12oEdCiWoEHrQQ9YMy+nMPe5R6pJHN1GUTlcEu4czpm7yKEXRmRq+BUY9DZW1oBfas8vDv4tX3yGgKg50g4VH/5p3hGpNjvVMYHci1WIRezMUmMa8 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 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 descriptor. > > 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 the > > 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 the > > future for similar special mappings, do a generic check of whether the > > 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, loff_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 = 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. Andrii, let's move forward with the v1 patch. > > > -- > Cheers, > > David / dhildenb >