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 C7159C4167B for ; Mon, 13 Nov 2023 13:26:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43E9C8D002B; Mon, 13 Nov 2023 08:26:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EEAA8D0001; Mon, 13 Nov 2023 08:26:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DD0F8D002B; Mon, 13 Nov 2023 08:26:36 -0500 (EST) 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 1E2F38D0001 for ; Mon, 13 Nov 2023 08:26:36 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AA13BC084D for ; Mon, 13 Nov 2023 13:26:35 +0000 (UTC) X-FDA: 81453005550.15.0E4CE65 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf16.hostedemail.com (Postfix) with ESMTP id B512D18001C for ; Mon, 13 Nov 2023 13:26:32 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=mit.edu header.s=outgoing header.b=i7ZrQb3Q; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (imf16.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699881993; 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=A3cLrLsAD7R33FPlXA97BU26N5BmXyNiPD9pSS1uKUQ=; b=RtDfMC6lwooG5HS4O99w6EZpVJdGSXZgOy4fBOIopO2woJQKIyj7D2Buln7n7e7LUoChG3 5WQIzQb2lE0vBgr7amOy1Go75LW+sEKH60K35BDlMRc04jIb1d1McvJ8WjQZldveHCMsvX XoPQlVV23z0LESBpLW6F+WYtslLjvNo= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=mit.edu header.s=outgoing header.b=i7ZrQb3Q; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (imf16.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699881993; a=rsa-sha256; cv=none; b=rtXGtVujssW48I5V0d+LHNL/QX2mt89VV8svBtPmGqyYDc1K9dQH4G5Gi4Tj/BSMv3PO/y 1tVelG7smW1oapIHj4rcHnveGMiSoJeHUj2qzOZnUMLZsr+QsnoyuOK/U3Hq5HDlnE4t1/ kYZD5XKXTmzxbjCcdsutCLP8YDf1Vaw= 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> X-Rspamd-Queue-Id: B512D18001C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5fnkti1rr7puyfg7qk51h8cemg3hy9bc X-HE-Tag: 1699881992-618150 X-HE-Meta: U2FsdGVkX1/XnRXZtl1BC/WSAEU+9YiY8kVrRPItyGIGA1Y2Z8tVUcCNQAvfh55DBFxRL0JxM/1rSDG2AlgUmeOjZ+wkHwUFVEFNPqgV0GI7K924qdMOOjkrRrK9NGoFsQLjTKBNgK8yBTmPkX3O4UfsdVgl3F7N7G0pz8SvFKw4e0XAidffFPa/BkNKxQTxP9Ef3K9d2XSu2dLPU51o53hbQ18z5rIvCuVGabJLwnArWxgzoO/1WJDCxpY+lDcrg//wXpLQ6xBHL9ZXqzHG/pJ0rGrpNINjYCXXdebKvWIHvsDmei2PcdcXixh8PKW0mXICc+4mnaSYGTMWmhUPAvpk9d5YiRMDNCVLOyEx36dOoSA5iJEfAZgOGoGahOa7uCXI30lKNVFrJTI3J4OUsBAjqGiGzg+FEbOpsFlPQBd0iWxZudUPhjdwFgb13DgS5aq3mV3HMtEGtB7ltVO8G+1dxn1RXi5D5ikhuFA5DC+/gdjHl/COqsN0ez8ZSrAw53lp5GlQqDfe3bH054zB7gNrDNJtDAVAxh//h2ASqy6PZofhhGKISiI9TWiBW0zUqSNSiFeLtNY2wJMGxUW3DWEjpij2IpjF/IJ6AHOpm4UcJPNDD64hu7JivckMHSRvLknE955VzDdK6iqrP7aqJnD6m5laUbnAjtmT1QimwrCFm0sEwaNiG2MQCIPFbTGEs73uHgh2pMRIBohCh/10rLcIo0K4pISVvJrGmGpQDhk2REh7/SuI/bB/ZVbxxu90JGYqdDnUTrPHq24eI0SoDMfw07MGnOHwnfXrva7MKQCcvWuZI7eJsk2SSkP0LdikkdiW62Q+8P7j9W4ZwtwUn8swOPfFMeYjENZGe0fN48ARgS84+zcyRP5a9Wy51hM82n0+oNZFblwcL1+o2AxCo7RlSq2xRkTAV1XecN5jmM3+B2R7IWrFWxJVAGl254rWiJR7XSW4h36qV3q4wYs bFhjPcVt LmgCtWhXv55lTaktdUg70X892YhH1Her78WjV7PTGEB5F69Qs/IVeLUCygcOdHvX09dgvOaPm+FYWMOP1ZXMAmwJO4J/a6qRodg1iAd4St3npUdOW2+Kd2CpSO+yIz1e4W8PpfSyuTQ5f9YG7qpWqIWDGjSH0evy6h4HPOnxnALPaIMnG/3VnsqjWLkFrUxcfoG1fdlta2OyC3iZT5THwXYPA1QwadT0W3j8zm2gTty6EivgtZhKi54YW5sNIN8O7tceOA9XOn/sPMXd0bE+7rUvflN+CXxE+JFxEUYpAxAhejZVrm71oOhe0QA== 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 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