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 39A96C433E1 for ; Mon, 20 Jul 2020 11:30:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 095A420656 for ; Mon, 20 Jul 2020 11:30:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 095A420656 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 7C5166B0006; Mon, 20 Jul 2020 07:30:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 777678D0001; Mon, 20 Jul 2020 07:30:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6640B6B0008; Mon, 20 Jul 2020 07:30:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id 4D5C16B0006 for ; Mon, 20 Jul 2020 07:30:34 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A1941184B28F9 for ; Mon, 20 Jul 2020 11:30:33 +0000 (UTC) X-FDA: 77058236346.05.pear64_381394f26f24 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 77B55184AE5C3 for ; Mon, 20 Jul 2020 11:30:33 +0000 (UTC) X-HE-Tag: pear64_381394f26f24 X-Filterd-Recvd-Size: 5859 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 11:30:32 +0000 (UTC) Received: from mail-qt1-f177.google.com ([209.85.160.177]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mvbr4-1knfRg3ibu-00sh9T for ; Mon, 20 Jul 2020 13:30:31 +0200 Received: by mail-qt1-f177.google.com with SMTP id e12so12589038qtr.9 for ; Mon, 20 Jul 2020 04:30:30 -0700 (PDT) X-Gm-Message-State: AOAM531z+tG5zKYJeJ6Wm3U0tCULV1XSItkDUqGDhac0gdk4hV+u/SJV DDZ5O9v2V3vd1ernVKHNJJMY3nWyAOjF9cEiuZE= X-Google-Smtp-Source: ABdhPJybaWn8qrmG7q01lgvZCZBti2IcqiiH7/UJUKpkh5l1pzukFrbCvJJFdRaOz1n0M6O3nf2Yvp55077wbmpCEEY= X-Received: by 2002:a05:620a:1654:: with SMTP id c20mr20996310qko.138.1595244629225; Mon, 20 Jul 2020 04:30:29 -0700 (PDT) MIME-Version: 1.0 References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> In-Reply-To: <20200720092435.17469-4-rppt@kernel.org> From: Arnd Bergmann Date: Mon, 20 Jul 2020 13:30:13 +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:BkQCEVGXyGKTEYcMrKXycrucco0fcEL1G7vfjRoGqVNzAVdl16A c0NcHqhtItdqxe6DYF32KdVP4lV3yw8q0N2xm4t7Getb+Xlod/t9dGoRQjnwZgMYD1yLzsF eSnMt92uL4tx2EYX1zvWMP1+icbk26XmHUEYOS/So+o0qf++wBfqhPk0ykGHmMLvpBhCiIM D2XAnYWycMHT+UIo80ZyQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:AqCHMJg5s88=:tlnKTAs57Mf4wsOEqgfqE+ oLOXQUYQOSOdxWVJG6oZ/qEBd8sMN764JQ3GZwWyNrgw50PSrXmAM5k3gmVtq+ZEEzWz4WxNT EQ1KZIXGANZW18mOYX3+KJ1BsoTU4goljf+RmEhZkUjdn+g/m5HLJJLkg1xJO/+c4Rh9d+6rr WiPRanr7AqGNxVgnIzglL0dJDKXOxShdGARnGgPOer8oDHzj3H5ZpzdScXE0BwpFwOJuSEmN5 lBwZac1vHLF/5NH6XUFoccugWUAQCIxIUMOCGbt9AW+PEFs0EbpIm+GzSEwd2EfkhvfQZUTGl A7uEuC6AiAWNwIBIG8I4ImZwQlyiWGoG2CJkIcUGmz30ZXh0J6LUZEnSJcVaMTkpPHYdBVuyh CledTFnFWhobi6RhWsAyIn3e9mvfyspXagSlwuVTVMSZKJBr49XgLZHq498TZOx5pE/voI00J hl0EF7ZfwVPmJL+bYqCUzJTrxyeXV7Hziz0dXGGtB9F3Jx+r+gh0ootSdnW5BbIARGc/qHHsX Yl9ljhhjZOxErUH+ccuWjumgU0NRRvOGZnCBgho6BJMRpiOaNk0LEogSvV5hGCG7jR6cprIE0 bw5bBIUn0HWoWj2IwwMNKSEtEE44vKVfWszzrTAuo+zFxf/7ttlX0NLjfL9MZzUPFh36Nbflm 9JcIsBZW+fTNzsYp2NvH/9ex5dEuGbd2Dr5mOpxo0tz6L2JqELdL7DEwBz412Q87Rh0nUf/oH 8bv3BClV8cxOitl0JL5Zwz5f/ZUEeWi/4phF6o+tq6AbpkGP2R6F0RdrM7o6qsujWOM11fNGJ 69Iq7XcTukFFsKJzprloGBjlozX+MbVThVjpcBPNmWz1GDXOIY6vmma/RZpNiKGQL0ZnbRhlw b4aFGWd2V3hnxOQTEOgwd/cvke/3npZ2Hdk1AU+uS+RWvAYphNpiHt86Ifs+Uswvuyd1IzuiN Hd4jN6X2hrIVIqJtVLWiQhq0LYtTj4LajY1Zvr8ticFnxsAxB8H/v X-Rspamd-Queue-Id: 77B55184AE5C3 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 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. Arnd