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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F05F3C4332F for ; Mon, 13 Nov 2023 13:26:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231157AbjKMN0q (ORCPT ); Mon, 13 Nov 2023 08:26:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230056AbjKMN0o (ORCPT ); Mon, 13 Nov 2023 08:26:44 -0500 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D6791732 for ; Mon, 13 Nov 2023 05:26:41 -0800 (PST) Received: from letrec.thunk.org ([12.191.197.195]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 3ADDQLDS005972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Nov 2023 08:26:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1699881985; bh=A3cLrLsAD7R33FPlXA97BU26N5BmXyNiPD9pSS1uKUQ=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=i7ZrQb3Qs3XpKtboy0+/4evxuo59TCF46dEv7qxwTbVc3/dOgUfj9E6hTOyDUrJfF VkWoMMPfGr6h+e+W2NWTwj4chpY65ICyA0nK9E7IG4KeoCacKGyF4eH/jbAzs87Pno oGZJJ95/6r2KnOv5KHnIII147SCq4F3byW4uFZzSNycAILnSDZLElH4y4/dj9gEI4V rWtXR7LEzzQ62Et2MnXWSgR/v+8kUr0HgDkYsTbsJpuH+3rdfE/PCvOxMCPjv3NJk9 4hf8rzPjqpxt17n5zVTq87WIiuRJaFqPpNj7AACl7krHhGENUQIOZq9CeCwg7lUx4s yzouDv2jQIQkw== Received: by letrec.thunk.org (Postfix, from userid 15806) id 096D18C034B; Mon, 13 Nov 2023 08:26:21 -0500 (EST) Date: Mon, 13 Nov 2023 08:26:21 -0500 From: "Theodore Ts'o" To: David Hildenbrand Cc: David Wang <00107082@163.com>, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Rapoport Subject: Re: [BUG?] mm/secretmem: memory address mapped to memfd_secret can be used in write syscall. Message-ID: References: <61159548.60cf.18baec1fd65.Coremail.00107082@163.com> <60081af2-d580-4f82-9233-3d3d7dd883bc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60081af2-d580-4f82-9233-3d3d7dd883bc@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 13, 2023 at 10:15:05AM +0100, David Hildenbrand wrote: > > According to the man page: > > "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.) > > I'm not sure if the last part is actually true, if the syscalls end up > walking user page tables to copy data in/out. The idea behind removing it from the kernel page tables is so that kernel code running in some other process context won't be able to reference the memory via the kernel address space. (So if there is some kind of kernel zero-day which allows arbitrary code execution, the injected attack code would have to play games with page tables before being able to reference the memory --- this is not *impossible*, just more annoying.) But if you are doing a buffered write, the copy from the user-supplied buffer to the page cache is happening in the process's context. So "foreground kernel code" can dereference the user-supplied pointer just fine. Cheers, - Ted