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 X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EF49C433E9 for ; Mon, 25 Jan 2021 21:48:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB04521BE5 for ; Mon, 25 Jan 2021 21:48:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732809AbhAYViL (ORCPT ); Mon, 25 Jan 2021 16:38:11 -0500 Received: from mail.kernel.org ([198.145.29.99]:35688 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732797AbhAYViG (ORCPT ); Mon, 25 Jan 2021 16:38:06 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 743FA208C7; Mon, 25 Jan 2021 21:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611610595; bh=ajaCsDQ6e4U1hUENrIDNUbcuSNalQWKY+iQc4S18YHs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cfQR8nUEYwM75PG5OUFV5JcmnnumpQwkS1CnVqcT2d4p/kUpcS/2u20YYyJroZRCW Jbt8N0i9NWstZhVeQAoWuL0s1n+n5az5ZLRoklNtsiaP1TJWCjFUBgluHnK4qcx2vR E16vQW+kwJovzCui9zqUqcbslF/9K9Il+/0P40Td3raK5Q2WzGx+8y38H1+/m5CZ3T SSW4VXI/VuuQaVG+TxLnGPfGOo0qcOYMor1OjHyeeaSkuT9z8sM7rhBjawSDsbXbG4 xDuvORI7oTg4YIT62Z9kQe6ps0I6CSs8pq6QDrPQmTgAxuIU4vdgt6s4t3c2vLy5LL LDqeEHslmluVA== Date: Mon, 25 Jan 2021 23:36:18 +0200 From: Mike Rapoport To: Michal Hocko Cc: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20210125213618.GL6332@kernel.org> References: <20210121122723.3446-1-rppt@kernel.org> <20210121122723.3446-7-rppt@kernel.org> <20210125170122.GU827@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210125170122.GU827@dhcp22.suse.cz> Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote: > On Thu 21-01-21 14:27:18, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Introduce "memfd_secret" system call with the ability to create memory > > areas visible only in the context of the owning process and not mapped not > > only to other processes but in the kernel page tables as well. > > > > The user will create a file descriptor using the memfd_secret() system > > call. The memory areas created by mmap() calls from this file descriptor > > will be unmapped from the kernel direct map and they will be only mapped in > > the page table of the owning mm. > > > > The secret memory remains accessible in the process context using uaccess > > primitives, but it is not accessible using direct/linear map addresses. > > > > Functions in the follow_page()/get_user_page() family will refuse to return > > a page that belongs to the secret memory area. > > > > A page that was a part of the secret memory area is cleared when it is > > freed. > > > > The following example demonstrates creation of a secret mapping (error > > handling is omitted): > > > > fd = memfd_secret(0); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > I do not see any access control or permission model for this feature. > Is this feature generally safe to anybody? The mappings obey memlock limit. Besides, this feature should be enabled explicitly at boot with the kernel parameter that says what is the maximal memory size secretmem can consume. -- Sincerely yours, Mike. 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CF3CC433E6 for ; Mon, 25 Jan 2021 21:36:38 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1E50422573 for ; Mon, 25 Jan 2021 21:36:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E50422573 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 9B295100EBBCE; Mon, 25 Jan 2021 13:36:37 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=rppt@kernel.org; receiver= Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 7FB07100EBBCB for ; Mon, 25 Jan 2021 13:36:35 -0800 (PST) Received: by mail.kernel.org (Postfix) with ESMTPSA id 743FA208C7; Mon, 25 Jan 2021 21:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611610595; bh=ajaCsDQ6e4U1hUENrIDNUbcuSNalQWKY+iQc4S18YHs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cfQR8nUEYwM75PG5OUFV5JcmnnumpQwkS1CnVqcT2d4p/kUpcS/2u20YYyJroZRCW Jbt8N0i9NWstZhVeQAoWuL0s1n+n5az5ZLRoklNtsiaP1TJWCjFUBgluHnK4qcx2vR E16vQW+kwJovzCui9zqUqcbslF/9K9Il+/0P40Td3raK5Q2WzGx+8y38H1+/m5CZ3T SSW4VXI/VuuQaVG+TxLnGPfGOo0qcOYMor1OjHyeeaSkuT9z8sM7rhBjawSDsbXbG4 xDuvORI7oTg4YIT62Z9kQe6ps0I6CSs8pq6QDrPQmTgAxuIU4vdgt6s4t3c2vLy5LL LDqeEHslmluVA== Date: Mon, 25 Jan 2021 23:36:18 +0200 From: Mike Rapoport To: Michal Hocko Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20210125213618.GL6332@kernel.org> References: <20210121122723.3446-1-rppt@kernel.org> <20210121122723.3446-7-rppt@kernel.org> <20210125170122.GU827@dhcp22.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210125170122.GU827@dhcp22.suse.cz> Message-ID-Hash: BESHQA7SMQCZJ3ZUD4SMJOOOXN7V2RA5 X-Message-ID-Hash: BESHQA7SMQCZJ3ZUD4SMJOOOXN7V2RA5 X-MailFrom: rppt@kernel.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote: > On Thu 21-01-21 14:27:18, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Introduce "memfd_secret" system call with the ability to create memory > > areas visible only in the context of the owning process and not mapped not > > only to other processes but in the kernel page tables as well. > > > > The user will create a file descriptor using the memfd_secret() system > > call. The memory areas created by mmap() calls from this file descriptor > > will be unmapped from the kernel direct map and they will be only mapped in > > the page table of the owning mm. > > > > The secret memory remains accessible in the process context using uaccess > > primitives, but it is not accessible using direct/linear map addresses. > > > > Functions in the follow_page()/get_user_page() family will refuse to return > > a page that belongs to the secret memory area. > > > > A page that was a part of the secret memory area is cleared when it is > > freed. > > > > The following example demonstrates creation of a secret mapping (error > > handling is omitted): > > > > fd = memfd_secret(0); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > I do not see any access control or permission model for this feature. > Is this feature generally safe to anybody? The mappings obey memlock limit. Besides, this feature should be enabled explicitly at boot with the kernel parameter that says what is the maximal memory size secretmem can consume. -- Sincerely yours, Mike. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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 X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2576C433E0 for ; Mon, 25 Jan 2021 21:36:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6D4AB2100A for ; Mon, 25 Jan 2021 21:36:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D4AB2100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z2TK+5VwvphTQEMyfMrFl9LPGW4lD8Pzb/ICWj5Kr4I=; b=3cV+KDg/7iXsQdKdRDLdWeLQR IqHB9k+BnZPBBUcQiaiXIe75fS094ZV1iBP/qlp0MX+6v9Tm43IcYGSZ5PTWOJSoaOzz1N1R3Y3fv CMgrw7xAbbi1xHGcJxVKAtpp6+HkRDB4NSDoNxd0Dgtxa1bCB04NTP9jGP9+vjHYiIUdmq792PRR4 0Itno/AySYeyvyoKApLLTLr8pfoTlOkUFpofZe2lkfZcgv8SruX9uSDiVNZ5BXx5hPlvC1T3fikgi DcaP9wvt0cGzET+hl6k01BqmAJ9a1LkU6Hg1bIke82CCX9OW5y+U97QsUI0cT8vQJJpdmPwk6g+Bz 4pJ8smjwg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l49XO-0003FS-27; Mon, 25 Jan 2021 21:36:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l49XH-0003Cl-VZ; Mon, 25 Jan 2021 21:36:37 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 743FA208C7; Mon, 25 Jan 2021 21:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611610595; bh=ajaCsDQ6e4U1hUENrIDNUbcuSNalQWKY+iQc4S18YHs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cfQR8nUEYwM75PG5OUFV5JcmnnumpQwkS1CnVqcT2d4p/kUpcS/2u20YYyJroZRCW Jbt8N0i9NWstZhVeQAoWuL0s1n+n5az5ZLRoklNtsiaP1TJWCjFUBgluHnK4qcx2vR E16vQW+kwJovzCui9zqUqcbslF/9K9Il+/0P40Td3raK5Q2WzGx+8y38H1+/m5CZ3T SSW4VXI/VuuQaVG+TxLnGPfGOo0qcOYMor1OjHyeeaSkuT9z8sM7rhBjawSDsbXbG4 xDuvORI7oTg4YIT62Z9kQe6ps0I6CSs8pq6QDrPQmTgAxuIU4vdgt6s4t3c2vLy5LL LDqeEHslmluVA== Date: Mon, 25 Jan 2021 23:36:18 +0200 From: Mike Rapoport To: Michal Hocko Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20210125213618.GL6332@kernel.org> References: <20210121122723.3446-1-rppt@kernel.org> <20210121122723.3446-7-rppt@kernel.org> <20210125170122.GU827@dhcp22.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210125170122.GU827@dhcp22.suse.cz> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210125_163636_176269_6198399B X-CRM114-Status: GOOD ( 22.18 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , David Hildenbrand , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Palmer Dabbelt , Arnd Bergmann , James Bottomley , Hagen Paul Pfeifer , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Shakeel Butt , Andrew Morton , Rick Edgecombe , Roman Gushchin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote: > On Thu 21-01-21 14:27:18, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Introduce "memfd_secret" system call with the ability to create memory > > areas visible only in the context of the owning process and not mapped not > > only to other processes but in the kernel page tables as well. > > > > The user will create a file descriptor using the memfd_secret() system > > call. The memory areas created by mmap() calls from this file descriptor > > will be unmapped from the kernel direct map and they will be only mapped in > > the page table of the owning mm. > > > > The secret memory remains accessible in the process context using uaccess > > primitives, but it is not accessible using direct/linear map addresses. > > > > Functions in the follow_page()/get_user_page() family will refuse to return > > a page that belongs to the secret memory area. > > > > A page that was a part of the secret memory area is cleared when it is > > freed. > > > > The following example demonstrates creation of a secret mapping (error > > handling is omitted): > > > > fd = memfd_secret(0); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > I do not see any access control or permission model for this feature. > Is this feature generally safe to anybody? The mappings obey memlock limit. Besides, this feature should be enabled explicitly at boot with the kernel parameter that says what is the maximal memory size secretmem can consume. -- Sincerely yours, Mike. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF242C433E0 for ; Mon, 25 Jan 2021 21:37:40 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 55BC52100A for ; Mon, 25 Jan 2021 21:37:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55BC52100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o3lVc+n0yXpNYauYdeTaTDCEjzWeZLfpPB9OgNE/SEg=; b=B+faPa2RrppgEyIIACwLOvi4d /3rGS8+l6Tvljl69iKsj3ApBR3DJMzB81wqzmxP8Fb38WqBu2r/gz6q8QBhnG93eZgUmKkfxCqVVW lUnCnMmWiSHrz1w1oc/neY++VVwcMGhR4a0HE8GFyCcfqobIXEPNwsBJX/oifLfuvdXAPqC4SKcrV wnaEODB5Iw0Y96wL3Va4s+41U9VljP+L/9PBjOH3b/JuEzQdfpVzd1S+VAYxDNckRO+kxbYEaZdE6 L+ZoXOcLzbhdZc2Jcc6sqNv2VjDEFEuT3ksaavy1Pyb9H7DipV5x9Sydl7gBXuyuu2Y0z5sL0s7gE bGrlxxaQg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l49XL-0003Ep-VD; Mon, 25 Jan 2021 21:36:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l49XH-0003Cl-VZ; Mon, 25 Jan 2021 21:36:37 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 743FA208C7; Mon, 25 Jan 2021 21:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611610595; bh=ajaCsDQ6e4U1hUENrIDNUbcuSNalQWKY+iQc4S18YHs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cfQR8nUEYwM75PG5OUFV5JcmnnumpQwkS1CnVqcT2d4p/kUpcS/2u20YYyJroZRCW Jbt8N0i9NWstZhVeQAoWuL0s1n+n5az5ZLRoklNtsiaP1TJWCjFUBgluHnK4qcx2vR E16vQW+kwJovzCui9zqUqcbslF/9K9Il+/0P40Td3raK5Q2WzGx+8y38H1+/m5CZ3T SSW4VXI/VuuQaVG+TxLnGPfGOo0qcOYMor1OjHyeeaSkuT9z8sM7rhBjawSDsbXbG4 xDuvORI7oTg4YIT62Z9kQe6ps0I6CSs8pq6QDrPQmTgAxuIU4vdgt6s4t3c2vLy5LL LDqeEHslmluVA== Date: Mon, 25 Jan 2021 23:36:18 +0200 From: Mike Rapoport To: Michal Hocko Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20210125213618.GL6332@kernel.org> References: <20210121122723.3446-1-rppt@kernel.org> <20210121122723.3446-7-rppt@kernel.org> <20210125170122.GU827@dhcp22.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210125170122.GU827@dhcp22.suse.cz> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210125_163636_176269_6198399B X-CRM114-Status: GOOD ( 22.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , David Hildenbrand , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Palmer Dabbelt , Arnd Bergmann , James Bottomley , Hagen Paul Pfeifer , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Shakeel Butt , Andrew Morton , Rick Edgecombe , Roman Gushchin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote: > On Thu 21-01-21 14:27:18, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Introduce "memfd_secret" system call with the ability to create memory > > areas visible only in the context of the owning process and not mapped not > > only to other processes but in the kernel page tables as well. > > > > The user will create a file descriptor using the memfd_secret() system > > call. The memory areas created by mmap() calls from this file descriptor > > will be unmapped from the kernel direct map and they will be only mapped in > > the page table of the owning mm. > > > > The secret memory remains accessible in the process context using uaccess > > primitives, but it is not accessible using direct/linear map addresses. > > > > Functions in the follow_page()/get_user_page() family will refuse to return > > a page that belongs to the secret memory area. > > > > A page that was a part of the secret memory area is cleared when it is > > freed. > > > > The following example demonstrates creation of a secret mapping (error > > handling is omitted): > > > > fd = memfd_secret(0); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > I do not see any access control or permission model for this feature. > Is this feature generally safe to anybody? The mappings obey memlock limit. Besides, this feature should be enabled explicitly at boot with the kernel parameter that says what is the maximal memory size secretmem can consume. -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel