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.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 EB986C433E7 for ; Mon, 20 Jul 2020 18:09:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BDA6B2070A for ; Mon, 20 Jul 2020 18:09:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BDA6B2070A 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 273F96B0002; Mon, 20 Jul 2020 14:09:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FD726B0005; Mon, 20 Jul 2020 14:09:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 075E76B0006; Mon, 20 Jul 2020 14:09:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id DEF376B0002 for ; Mon, 20 Jul 2020 14:09:07 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7730C8248047 for ; Mon, 20 Jul 2020 18:09:07 +0000 (UTC) X-FDA: 77059240734.03.dolls18_600716b26f26 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 32186264D7C for ; Mon, 20 Jul 2020 18:09:05 +0000 (UTC) X-HE-Tag: dolls18_600716b26f26 X-Filterd-Recvd-Size: 6861 Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 18:09:04 +0000 (UTC) Received: from mail-qt1-f182.google.com ([209.85.160.182]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MNbxN-1kDAE123tD-00P6yA for ; Mon, 20 Jul 2020 20:09:02 +0200 Received: by mail-qt1-f182.google.com with SMTP id w27so13880223qtb.7 for ; Mon, 20 Jul 2020 11:09:02 -0700 (PDT) X-Gm-Message-State: AOAM532p2aCptq4iRpUUbxQejnA+8sqBi7o/vI+dgp5glgOiQlMvH0IN tPxigXN7qnTxneihfA83+G3tEAB5XriwZ+3lBlg= X-Google-Smtp-Source: ABdhPJxk8AXvQoaaSyG6TPpWGlRFg6r3NFnqCF1QtWJiuwzUOgkiVS3DL9DQU7SzABQpPR/Um1zIkILDDVb8zZFAISI= X-Received: by 2002:a37:b484:: with SMTP id d126mr22851253qkf.394.1595268540113; Mon, 20 Jul 2020 11:09:00 -0700 (PDT) MIME-Version: 1.0 References: <20200720092435.17469-1-rppt@kernel.org> <20200720092435.17469-4-rppt@kernel.org> <1595260305.4554.9.camel@linux.ibm.com> In-Reply-To: <1595260305.4554.9.camel@linux.ibm.com> From: Arnd Bergmann Date: Mon, 20 Jul 2020 20:08:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas To: "James E.J. Bottomley" Cc: Mike Rapoport , "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 , "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:NynxKGg6vkzJp6ZRYmxXS2gHbfqKcv5rj0o2hao3vn6c0HZQewR lM0y976GeM0t3oGPKDFKXsAKjZQuvFlevbEitLfHfVENZ5GJIGi2AGaT8ZTSqrRDqxG1OCU mkoCFYYHgxa/Kk22rURAXx/HG0oTK7uFydZ2zcqH+zDcsQotV6sS+ydswLUaPiyMzSUblqc GxCVN4Nc6xSSkh0vEG0Uw== X-UI-Out-Filterresults: notjunk:1;V03:K0:UpkK5/UD0bI=:ZdaVfblW3uT05nv0l7ne+u j5lP3HU6HiQdHHK/Ye2QMthKgUj9xgwh6AQij9/Wqtv5vBGHn1D+2J8MPZpS+8JfKbJXL2CZs uTE1WMgIbT0dklFUrmBdfkpsDwTGrXusZaoQ+ZzA1jgHQ0JTEMRm0z/TCAwNnsGVC8ZdSMB+7 99A7QbsRGpCyS1y2KI5Sgjj8Spd/Bx3GpkDqYAAwGbEkq1lxjV19n2rlPOcvic7CQ7gVPxoKM fs3aCLSmZPjr1pGd8EMkf9AxA+XoAmtOFZ0KVds03qKDIeicfKbCDCtxT3el08ZhiqQ3AWqL4 RGq0WrwnCXAfvRKwnxV7ui6S8dTh3XqrKMLKeVZvLgmW4Ft3VdTWFBYoJngHHsnlItx1nX7WY C90gM/IN959EVWmBDhUcD0fu86q+tUZdHc3ZVjPDQIxGhEUOjbNqpqbxeoG4z7QUhpVCIFyY/ uSmLNdeOQffiIbteKxvsyBFqxdXXeYAg+WZsvcJfGg+4htdw1gsqAFIzngFmAAnozrr0IgYx+ RVqD8IR8zfdmQx/Mx94eqGdJn6KDt0c7qZzxeVZhToZK/+nDtHvU5aiblI0FU0QUOxsT0tRT6 ARvTmyp9Rwvcs+gvKBNrAO63OxMYbI5Bx7O1aYJ1vLezPW83N3OZvE0yH+Bblivl/KQTaYjE5 bKd4Rs1eyctpbDQeSuVnzQYgECEMHiN21/xjfObjqRXkvCVZ31sd4t0KLxHgXrz6b3P3KZlWm nHHLS/DloOYhCy9Yh44atQeyD2MA9zDNmJ20QdEH87eQ7XsINxdglelum8usWskAMMp5/fszl iJGhebPzXZNuQnyKtvFr9QWcQG8jS7a+BzEi/o3hFldl99sGccvmJtxHk8uvhUa/GzyLgZ3/5 1BCs/Qlz+sY6hgEn/MaKvvr06rl7T4sAcMhEdKv80MiplzQ51zsuuH5hAM46gLL823WIwjnl9 22iuSqKR7yHF/9Hkizfff0aX9ibgb8UMGBvZIco9cz+6nIBO5NFI9 X-Rspamd-Queue-Id: 32186264D7C 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 5:52 PM James Bottomley wrote: > On Mon, 2020-07-20 at 13:30 +0200, Arnd Bergmann wrote: > > I'll assume you mean the dmabuf userspace API? Because the kernel API > is completely device exchange specific and wholly inappropriate for > this use case. > > The user space API of dmabuf uses a pseudo-filesystem. So you mount > the dmabuf file type (and by "you" I mean root because an ordinary user > doesn't have sufficient privilege). This is basically because every > dmabuf is usable by any user who has permissions. This really isn't > the initial interface we want for secret memory because secret regions > are supposed to be per process and not shared (at least we don't want > other tenants to see who's using what). > > Once you have the fd, you can seek to find the size, mmap, poll and > ioctl it. The ioctls are all to do with memory synchronization (as > you'd expect from a device backed region) and the mmap is handled by > the dma_buf_ops, which is device specific. Sizing is missing because > that's reported by the device not settable by the user. I was mainly talking about the in-kernel interface that is used for sharing a buffer with hardware. Aside from the limited ioctls, anything in the kernel can decide on how it wants to export a dma_buf by calling dma_buf_export()/dma_buf_fd(), which is roughly what the new syscall does as well. Using dma_buf vs the proposed implementation for this is not a big difference in complexity. The one thing that a dma_buf does is that it allows devices to do DMA on it. This is either something that can turn out to be useful later, or it is not. From the description, it sounded like the sharing might be useful, since we already have known use cases in which "secret" data is exchanged with a trusted execution environment using the dma-buf interface. If there is no way the data stored in this new secret memory area would relate to secret data in a TEE or some other hardware device, then I agree that dma-buf has no value. > What we want is the ability to get an fd, set the properties and the > size and mmap it. This is pretty much a 100% overlap with the memfd > API and not much overlap with the dmabuf one, which is why I don't > think the interface is very well suited. Does that mean you are suggesting to use additional flags on memfd_create() instead of a new system call? Arnd