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, HEADER_FROM_DIFFERENT_DOMAINS,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 89AFFC433E2 for ; Mon, 20 Jul 2020 14:39:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5453E22482 for ; Mon, 20 Jul 2020 14:39:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5453E22482 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A8B8A8D0001; Mon, 20 Jul 2020 10:39:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A39D16B0008; Mon, 20 Jul 2020 10:39:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 928A08D0001; Mon, 20 Jul 2020 10:39:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id 7ACCD6B0005 for ; Mon, 20 Jul 2020 10:39:39 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EDD3147F2551 for ; Mon, 20 Jul 2020 14:39:37 +0000 (UTC) X-FDA: 77058712794.28.son59_62019f926f25 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id BDC812E375B for ; Mon, 20 Jul 2020 14:34:32 +0000 (UTC) X-HE-Tag: son59_62019f926f25 X-Filterd-Recvd-Size: 6993 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 14:34:31 +0000 (UTC) Received: from mail-io1-f46.google.com ([209.85.166.46]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MzQbw-1kjsIQ0Tgm-00vRjD for ; Mon, 20 Jul 2020 16:34:30 +0200 Received: by mail-io1-f46.google.com with SMTP id y2so17817595ioy.3 for ; Mon, 20 Jul 2020 07:34:29 -0700 (PDT) X-Gm-Message-State: AOAM533Shz0SVXzPSfos2sdTuaLydi5fw9wlnJ9P7IfAoBxxtDtpqUfI c6iC7VBISHRRjIOGkq1eTwj/dPTzd3DPS3lspD8= X-Google-Smtp-Source: ABdhPJwIxgAdvjUjPU+4jzybDNb2QFZAVcL3HMLlxw2RLgRPrBNFIwh83Ml0UJm/YApy5c7tnsKEhhbWEGttCx/g1AI= X-Received: by 2002:a37:b484:: with SMTP id d126mr21885286qkf.394.1595255668502; Mon, 20 Jul 2020 07:34:28 -0700 (PDT) MIME-Version: 1.0 References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> <20200720142053.GC8593@kernel.org> In-Reply-To: <20200720142053.GC8593@kernel.org> From: Arnd Bergmann Date: Mon, 20 Jul 2020 16:34:12 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas To: Mike Rapoport 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 Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:a094iUyx4F9PptXs3b/Uet+zKN69v4H/BgVJs4a2Sy/sJ4Tmju2 hCDtu70pd1ifw3t5Y1mOjU7XG5Z6VxQPRnWc1VyXlzeSfs+HaE3zJA8u8lLXxehvYS4kfbt 3OSjIo6pCD3hxBHNfMk2p4de5BaEDgQAtymQPpOW1MQNOaERzgNN0/naCVMCEPblZ0gnYad 5t9dQoKPPZW0byMQSvVEQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:wh1w5ErV7rw=:W0TEX9LjpK4pPIM2cy0gio dRt9tMCZBeL4OvwNAGHqVsRmuHS+rU3dH2O99FIImG6ePbsaSO8+rW6AdlTR87p83QlE+IdTi +s3LVTxdtVDkOaaH5b/b5h0EBqGyHqFSBuW4BLYxiij+W1yCnvE6bdNj4pYvkCFslm15cTyx8 YZxUWYonfRw92CUyYWDjHzeBrr+oJQ/Y5k9u8WUom7Ie4VaDRb5FWiIZdTrL6fPKvRLQMh0An tZjshv8apoxePnsmJgfQzhE33XJYyTeVMNIWU32IeZquC+0qOOmXEXH1qH1fLXCFitmzb4X7d BNWWMwXrOOZMDmUJ0doKEd6vXCjbsFpL9W6vNtDeqibDwKpv0Re+IeXmFAiDXVhUl6K9DypOr M7WDiMomIwQi2tR1oDY/JDx6Xdnwljo3e5lnqMhm1WGhs01A3+bqC4U50+9QxbBOkVLI0NgZg MExguB/hui4EYsFPVKyXLUMeE2VviXQHkq+j9EfUgf4BLOEyJHtOjWQcIevLvW72IGICOcVWL Ksdyci1uE3fNw/lHgwsr+AzkK61H64B2Sep67hZNRxmwIP0tQC4AnXj05N33/oKaP26EffFur //yUex+xUqU0X85KUiNHeBgqPxV1W65XzyKnxP0NIxIcoOTpfiKcIbBCz3O85RpJ0depyYERf 6XQxrt5JXtfVshb94wim1UCNZeRv3ik1JFoL9micvFaiLGirysyueoHNGx3hAZtLIa2ffoh5M Q9hwyEwW+j06dftjpsO0WF9X1rYsJE7lDYW2J+jQ7VFqlabWrboNK4b5uLvQlLQzwytq5AIMm Mx4Pnc1HicqlBjkxrlgP5ePevPCx5wXnKw2BsNEO3E9v03bhLKH8/WD+8t+P3zyb4rS6xUHAv rsiA0uWEhZGM/4hPdBH4KfzBhGuoEINxcqjsiWyF/WPHs6ORtpLpxAlYfpYpaC5GlQz/bhVt0 VMLHlnPItBJohPJsJg80cYK/0fBhOPmrJWNKJXAp1Ik6oD65dmz36 X-Rspamd-Queue-Id: BDC812E375B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: On Mon, Jul 20, 2020 at 4:21 PM Mike Rapoport wrote: > 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. No, dmabuf is normally about normal RAM that is shared between multiple devices, the idea is that you can have one driver allocate a buffer in RAM and export it to user space through a file descriptor. The application can then go and mmap() it or pass it into one or more other drivers. This can be used e.g. for sharing a buffer between a video codec and the gpu, or between a crypto engine and another device that accesses unencrypted data while software can only observe the encrypted version. Arnd