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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 B5C87C433E2 for ; Mon, 20 Jul 2020 14:21:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8F84A22B4D for ; Mon, 20 Jul 2020 14:21:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595254870; bh=HLsnWapSZr1TpttXIYrQQDMJGrH8nj1rqvBMPrAFCRE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=aqyVv9M2lubrSuM58bxfwZKhccWZ2ZYM6tXxvjAVSte/mZ6N6FfBi2sZEsHeAD6tU REvR2oUyPilA1NwI/dz6YRY203PjpGJR8d/8gSxydqjt76BEGJFeILsZlr8dBI6gO2 OvVLTIgTqEKrDyKgX7kukxjM5Rzazk4poyl/6Zsc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728469AbgGTOVK (ORCPT ); Mon, 20 Jul 2020 10:21:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:48780 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726759AbgGTOVK (ORCPT ); Mon, 20 Jul 2020 10:21:10 -0400 Received: from kernel.org (unknown [87.71.40.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 268A520B1F; Mon, 20 Jul 2020 14:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595254869; bh=HLsnWapSZr1TpttXIYrQQDMJGrH8nj1rqvBMPrAFCRE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XQFs0H8abPDZJviZX+5bTqQNawGqmx/pBTGly2VfVP90WSpMzcMHYQaTLQ4IRVWLD k/TvI13Gi+NhRKv0vTnOIb6rS5YvbMFxFB2Z5aBUzsuJsDlzLpFqI8rMGY5I1SWibn SqtW927tzctc+7dbf6a1ky5SigWZ7PMcfQCFsoO4= Date: Mon, 20 Jul 2020 17:20:53 +0300 From: Mike Rapoport To: Arnd Bergmann Cc: "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Idan Yaniv , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Thomas Gleixner , Tycho Andersen , Will Deacon , Linux API , linux-arch , Linux ARM , Linux FS-devel Mailing List , Linux-MM , linux-nvdimm@lists.01.org, linux-riscv , the arch/x86 maintainers , linaro-mm-sig@lists.linaro.org, Sumit Semwal Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas Message-ID: <20200720142053.GC8593@kernel.org> References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Mon, Jul 20, 2020 at 01:30:13PM +0200, Arnd Bergmann wrote: > On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport wrote: > > > > From: Mike Rapoport > > > > Introduce "secretmemfd" 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 secretmemfd system call > > where flags supplied as a parameter to this system call will define the > > desired protection mode for the memory associated with that file > > descriptor. Currently there are two protection modes: > > > > * exclusive - the memory area is unmapped from the kernel direct map and it > > is present only in the page tables of the owning mm. > > * uncached - the memory area is present only in the page tables of the > > owning mm and it is mapped there as uncached. > > > > For instance, the following example will create an uncached mapping (error > > handling is omitted): > > > > fd = secretmemfd(SECRETMEM_UNCACHED); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, > > fd, 0); > > > > Signed-off-by: Mike Rapoport > > I wonder if this should be more closely related to dmabuf file > descriptors, which > are already used for a similar purpose: sharing access to secret memory areas > that are not visible to the OS but can be shared with hardware through device > drivers that can import a dmabuf file descriptor. TBH, I didn't think about dmabuf, but my undestanding is that is this case memory areas are not visible to the OS because they are on device memory rather than normal RAM and when dmabuf is backed by the normal RAM, the memory is visible to the OS. Did I miss anything? > Arnd -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Rapoport Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas Date: Mon, 20 Jul 2020 17:20:53 +0300 Message-ID: <20200720142053.GC8593@kernel.org> References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arnd Bergmann Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Alexander Viro , Andrew Morton , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Idan Yaniv , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mike Rapoport , Palmer Dabbelt , Paul Walmsley List-Id: linux-arch.vger.kernel.org On Mon, Jul 20, 2020 at 01:30:13PM +0200, Arnd Bergmann wrote: > On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport wrote: > > > > From: Mike Rapoport > > > > Introduce "secretmemfd" 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 secretmemfd system call > > where flags supplied as a parameter to this system call will define the > > desired protection mode for the memory associated with that file > > descriptor. Currently there are two protection modes: > > > > * exclusive - the memory area is unmapped from the kernel direct map and it > > is present only in the page tables of the owning mm. > > * uncached - the memory area is present only in the page tables of the > > owning mm and it is mapped there as uncached. > > > > For instance, the following example will create an uncached mapping (error > > handling is omitted): > > > > fd = secretmemfd(SECRETMEM_UNCACHED); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, > > fd, 0); > > > > Signed-off-by: Mike Rapoport > > I wonder if this should be more closely related to dmabuf file > descriptors, which > are already used for a similar purpose: sharing access to secret memory areas > that are not visible to the OS but can be shared with hardware through device > drivers that can import a dmabuf file descriptor. TBH, I didn't think about dmabuf, but my undestanding is that is this case memory areas are not visible to the OS because they are on device memory rather than normal RAM and when dmabuf is backed by the normal RAM, the memory is visible to the OS. Did I miss anything? > Arnd -- 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=-6.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 D1983C433E5 for ; Mon, 20 Jul 2020 14:21:15 +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 A32E522CB1 for ; Mon, 20 Jul 2020 14:21:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="XQFs0H8a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A32E522CB1 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 5F49C1239E546; Mon, 20 Jul 2020 07:21:15 -0700 (PDT) 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 5460C1239E542 for ; Mon, 20 Jul 2020 07:21:09 -0700 (PDT) Received: from kernel.org (unknown [87.71.40.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 268A520B1F; Mon, 20 Jul 2020 14:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595254869; bh=HLsnWapSZr1TpttXIYrQQDMJGrH8nj1rqvBMPrAFCRE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XQFs0H8abPDZJviZX+5bTqQNawGqmx/pBTGly2VfVP90WSpMzcMHYQaTLQ4IRVWLD k/TvI13Gi+NhRKv0vTnOIb6rS5YvbMFxFB2Z5aBUzsuJsDlzLpFqI8rMGY5I1SWibn SqtW927tzctc+7dbf6a1ky5SigWZ7PMcfQCFsoO4= Date: Mon, 20 Jul 2020 17:20:53 +0300 From: Mike Rapoport To: Arnd Bergmann Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas Message-ID: <20200720142053.GC8593@kernel.org> References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Message-ID-Hash: Z6CLIFEMMG7PI7YJT5GGGMVIV73YVSJB X-Message-ID-Hash: Z6CLIFEMMG7PI7YJT5GGGMVIV73YVSJB 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: "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Idan Yaniv , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Thomas Gleixner , Tycho Andersen , Will Deacon , Linux API , linux-arch , Linux ARM , Linux FS-devel Mailing List , Linux-MM , linux-nvdimm@lists.01.org, linux-riscv , the arch/x86 maintainers , linaro-mm-sig@lists.linaro.org, Sumit Semwal 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, Jul 20, 2020 at 01:30:13PM +0200, Arnd Bergmann wrote: > On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport wrote: > > > > From: Mike Rapoport > > > > Introduce "secretmemfd" 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 secretmemfd system call > > where flags supplied as a parameter to this system call will define the > > desired protection mode for the memory associated with that file > > descriptor. Currently there are two protection modes: > > > > * exclusive - the memory area is unmapped from the kernel direct map and it > > is present only in the page tables of the owning mm. > > * uncached - the memory area is present only in the page tables of the > > owning mm and it is mapped there as uncached. > > > > For instance, the following example will create an uncached mapping (error > > handling is omitted): > > > > fd = secretmemfd(SECRETMEM_UNCACHED); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, > > fd, 0); > > > > Signed-off-by: Mike Rapoport > > I wonder if this should be more closely related to dmabuf file > descriptors, which > are already used for a similar purpose: sharing access to secret memory areas > that are not visible to the OS but can be shared with hardware through device > drivers that can import a dmabuf file descriptor. TBH, I didn't think about dmabuf, but my undestanding is that is this case memory areas are not visible to the OS because they are on device memory rather than normal RAM and when dmabuf is backed by the normal RAM, the memory is visible to the OS. Did I miss anything? > Arnd -- 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 9915DC433E1 for ; Mon, 20 Jul 2020 14:21:33 +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 67DC620B1F for ; Mon, 20 Jul 2020 14:21:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="x/n7rt3w"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="XQFs0H8a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67DC620B1F 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=UZrqmlSn4DS+AjASVaTRosLl4xGqFJaomAFPNnfYmo8=; b=x/n7rt3wqFlCflG3Unfi96cSh pvmsPCI8yIZfB1QBWD9idgYu1K+4xm0dVeUR7RjoLER0OTqPrAMeduuo6TbZQAUjUyEyxdPet1lk0 MtpMTe8AzJW69enZtNgFgGCc9CfIGgQRaLN+udMwt2QTzxcTARWuRfgQb/roPr+reTCD4Eno9xhGO +qwzqhrUdA2sNQXIYZMPUJiXBv78Bs9yoRRMiosAbjUnHcMy4q6CiL314MBd6EMwhSmXOfgu867Ih vMbMaW3BO9di3AZC/l3xhAx++8nf5GYo67hazHpNq2/wOS+rQ721hfpv8ap3dOjvwFZOq9n26p83d MXdGNyxig==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jxWfL-0002Y5-VO; Mon, 20 Jul 2020 14:21:15 +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 1jxWfF-0002VR-Po; Mon, 20 Jul 2020 14:21:11 +0000 Received: from kernel.org (unknown [87.71.40.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 268A520B1F; Mon, 20 Jul 2020 14:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595254869; bh=HLsnWapSZr1TpttXIYrQQDMJGrH8nj1rqvBMPrAFCRE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XQFs0H8abPDZJviZX+5bTqQNawGqmx/pBTGly2VfVP90WSpMzcMHYQaTLQ4IRVWLD k/TvI13Gi+NhRKv0vTnOIb6rS5YvbMFxFB2Z5aBUzsuJsDlzLpFqI8rMGY5I1SWibn SqtW927tzctc+7dbf6a1ky5SigWZ7PMcfQCFsoO4= Date: Mon, 20 Jul 2020 17:20:53 +0300 From: Mike Rapoport To: Arnd Bergmann Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas Message-ID: <20200720142053.GC8593@kernel.org> References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200720_102110_025788_8955352B X-CRM114-Status: GOOD ( 25.40 ) 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: Peter Zijlstra , Catalin Marinas , Dave Hansen , Linux-MM , "H. Peter Anvin" , Christopher Lameter , Idan Yaniv , Dan Williams , Elena Reshetova , linux-arch , Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , the arch/x86 maintainers , Matthew Wilcox , Mike Rapoport , Ingo Molnar , James Bottomley , linaro-mm-sig@lists.linaro.org, Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Thomas Gleixner , Linux ARM , Linux API , "linux-kernel@vger.kernel.org" , linux-riscv , Palmer Dabbelt , Linux FS-devel Mailing List , Andrew Morton , Sumit Semwal 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, Jul 20, 2020 at 01:30:13PM +0200, Arnd Bergmann wrote: > On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport wrote: > > > > From: Mike Rapoport > > > > Introduce "secretmemfd" 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 secretmemfd system call > > where flags supplied as a parameter to this system call will define the > > desired protection mode for the memory associated with that file > > descriptor. Currently there are two protection modes: > > > > * exclusive - the memory area is unmapped from the kernel direct map and it > > is present only in the page tables of the owning mm. > > * uncached - the memory area is present only in the page tables of the > > owning mm and it is mapped there as uncached. > > > > For instance, the following example will create an uncached mapping (error > > handling is omitted): > > > > fd = secretmemfd(SECRETMEM_UNCACHED); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, > > fd, 0); > > > > Signed-off-by: Mike Rapoport > > I wonder if this should be more closely related to dmabuf file > descriptors, which > are already used for a similar purpose: sharing access to secret memory areas > that are not visible to the OS but can be shared with hardware through device > drivers that can import a dmabuf file descriptor. TBH, I didn't think about dmabuf, but my undestanding is that is this case memory areas are not visible to the OS because they are on device memory rather than normal RAM and when dmabuf is backed by the normal RAM, the memory is visible to the OS. Did I miss anything? > Arnd -- 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 B8EE1C433DF for ; Mon, 20 Jul 2020 14:22:43 +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 8A92022B4D for ; Mon, 20 Jul 2020 14:22:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="W0oxuJc0"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="XQFs0H8a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8A92022B4D 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=BbSfLQeDCEpjaea22b33rYDq2weQIqQzigSsY/fpeiM=; b=W0oxuJc0JWfwpTFlCy4HxZIeh IQMXJwcM9bU5SC2lkeYDCf0K5JQWeQPQrFpohYLDEBIR7GWudCdQf1Slp3LKzDw903cU/ET8qa5aB p9D035FJY+n1aCESDuiD0DXFTctUk435o1OPXsBoJGJrgm+yKHdJXo+fCE9XGp/J/uArvqngyqSRd fJaV4pQtzkv12uqwKM4vAVY1Gk1yuhLMEVnf2SOIcah9TZUZa2HTQAL+trY78ZIrLuW9BE3bPMQrC ZEg+cNGTDPwZTQPSAfR5vTjJwR1hfAkddE/Vewd7JyUdAB6KJ0ihWPIZlalja/5Yb1UhKiCwPrg2+ pZIomeOUg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jxWfK-0002XM-3C; Mon, 20 Jul 2020 14:21:14 +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 1jxWfF-0002VR-Po; Mon, 20 Jul 2020 14:21:11 +0000 Received: from kernel.org (unknown [87.71.40.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 268A520B1F; Mon, 20 Jul 2020 14:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595254869; bh=HLsnWapSZr1TpttXIYrQQDMJGrH8nj1rqvBMPrAFCRE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XQFs0H8abPDZJviZX+5bTqQNawGqmx/pBTGly2VfVP90WSpMzcMHYQaTLQ4IRVWLD k/TvI13Gi+NhRKv0vTnOIb6rS5YvbMFxFB2Z5aBUzsuJsDlzLpFqI8rMGY5I1SWibn SqtW927tzctc+7dbf6a1ky5SigWZ7PMcfQCFsoO4= Date: Mon, 20 Jul 2020 17:20:53 +0300 From: Mike Rapoport To: Arnd Bergmann Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas Message-ID: <20200720142053.GC8593@kernel.org> References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200720_102110_025788_8955352B X-CRM114-Status: GOOD ( 25.40 ) 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: Peter Zijlstra , Catalin Marinas , Dave Hansen , Linux-MM , "H. Peter Anvin" , Christopher Lameter , Idan Yaniv , Dan Williams , Elena Reshetova , linux-arch , Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , the arch/x86 maintainers , Matthew Wilcox , Mike Rapoport , Ingo Molnar , James Bottomley , linaro-mm-sig@lists.linaro.org, Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Thomas Gleixner , Linux ARM , Linux API , "linux-kernel@vger.kernel.org" , linux-riscv , Palmer Dabbelt , Linux FS-devel Mailing List , Andrew Morton , Sumit Semwal 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, Jul 20, 2020 at 01:30:13PM +0200, Arnd Bergmann wrote: > On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport wrote: > > > > From: Mike Rapoport > > > > Introduce "secretmemfd" 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 secretmemfd system call > > where flags supplied as a parameter to this system call will define the > > desired protection mode for the memory associated with that file > > descriptor. Currently there are two protection modes: > > > > * exclusive - the memory area is unmapped from the kernel direct map and it > > is present only in the page tables of the owning mm. > > * uncached - the memory area is present only in the page tables of the > > owning mm and it is mapped there as uncached. > > > > For instance, the following example will create an uncached mapping (error > > handling is omitted): > > > > fd = secretmemfd(SECRETMEM_UNCACHED); > > ftruncate(fd, MAP_SIZE); > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, > > fd, 0); > > > > Signed-off-by: Mike Rapoport > > I wonder if this should be more closely related to dmabuf file > descriptors, which > are already used for a similar purpose: sharing access to secret memory areas > that are not visible to the OS but can be shared with hardware through device > drivers that can import a dmabuf file descriptor. TBH, I didn't think about dmabuf, but my undestanding is that is this case memory areas are not visible to the OS because they are on device memory rather than normal RAM and when dmabuf is backed by the normal RAM, the memory is visible to the OS. Did I miss anything? > Arnd -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel