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 21C13C433E5 for ; Mon, 20 Jul 2020 20:06:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E07092080D for ; Mon, 20 Jul 2020 20:06:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E07092080D 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 1D26E8D0005; Mon, 20 Jul 2020 16:06:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 184318D0003; Mon, 20 Jul 2020 16:06:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 072538D0005; Mon, 20 Jul 2020 16:06:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E601F8D0003 for ; Mon, 20 Jul 2020 16:06:42 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2F4CC183E46E2 for ; Mon, 20 Jul 2020 20:06:42 +0000 (UTC) X-FDA: 77059537044.27.rate94_4d0782826f27 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id E7F989A566 for ; Mon, 20 Jul 2020 20:06:00 +0000 (UTC) X-HE-Tag: rate94_4d0782826f27 X-Filterd-Recvd-Size: 6937 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 20:06:00 +0000 (UTC) Received: from mail-qt1-f169.google.com ([209.85.160.169]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MKuGD-1kFxkJ2VOH-00LHaV for ; Mon, 20 Jul 2020 22:05:58 +0200 Received: by mail-qt1-f169.google.com with SMTP id e12so14265460qtr.9 for ; Mon, 20 Jul 2020 13:05:58 -0700 (PDT) X-Gm-Message-State: AOAM530f41BQPusUowfhBZbYC398Z4mBJTor81mwOiaEpVlbGY5Uxxcn vFwptnl1edm5W7hHChdKIsyrUR0mZVy8NoG2GVQ= X-Google-Smtp-Source: ABdhPJzP8ED75eP/64ZTWgc8CqM8513IRGly4LjDrHp/zECs6vcVhK6MaJY0JaFbbN4kfnMI9cRAMEvStsrfDJyQR1k= X-Received: by 2002:ac8:7587:: with SMTP id s7mr25919753qtq.304.1595275555970; Mon, 20 Jul 2020 13:05:55 -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> <1595272585.4554.28.camel@linux.ibm.com> In-Reply-To: <1595272585.4554.28.camel@linux.ibm.com> From: Arnd Bergmann Date: Mon, 20 Jul 2020 22:05:39 +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:t9hbFa2R/bKH6qRQzSEAGwFcMjil9z8V4dAx0ImFm3v77Wl3vpr J2KqL2geOzffMAJKZr/JrzD/qn3G++bNdD9X1ufvUKLLoVSgpz8I2USggPSSaHUWdHE/P1n VU04UpcnsorxLArQRBIywz2yVUqErjDA8v7ood9sZxv7pZoHNSaVZzr1n45rp9SQBEd01r2 NZGCJA2xjhjepyVY7y5xQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:NIOPP4Zuq+E=:21rYSL79Wyz7CwWZwkmzL6 pxIwQITrjOyYFgF9QvRYPtF1NrSSMabrYgT3iGn+q5sSwerNJR0MTHYFHXQMI492PXeuVEh80 MIA8HTP4xh6gqOY3DpXJhxinoKqpI7pk0/bSn+vwSlnTkXU/OpsqQ9H9aQrD2GRK9eD+tRuAp xp7yY4IG+H8AyDy02sVXEH8juNyFlnEonBu6T4Vwnx/8c7xm8mpgzdWOcZ5MOjaEbJLSzyK7Z UWDtm+19DePGArNfYOSQarBvF0mrcCgq3+rF6u+Iswkn8KV2Y9fIseSQMsYHM1df4TxkK64yF UA4hXvT7sR2gxuH0vzJTGxvw/RwCj72avRy4+Zn7OKa5yCLCdcVjqUVw3F03ll46H1Uv+EnjY 3XcnsXkhX+dyd7Vql83Z5N6SbmFwh+oneFvyxUUfZfbccVQJ0vv7+chob1aNpUdTv49x+5Y7n hyXQQEAbW0+5Cv+SIeTktK3T3b2DuTGUjHY3YumjoXwEp4j3EJf8voG0SSlp9SAY+9jxkG6qT /eXBAWarie0dgPClfYJTipVolzsxQlYjZuAgOJKxi4FG9XbUBqfIlAl7sxY6bJ3hezlsa/ghu g8Zumgsc+pEpAYUWXkk24vznvxdZrVhD/H5J0doZF8xOcvUJAUbdkh5DdE9ejgcxqCGTGOeYV Wq1XFjhFA5tJX5H45pzpce1065OXeORlhcWpZEBsSW+HnA9+BQVe99d75TPM7C9K4F8q6gu+F 8cYp2eVDNurDAobva+xcSn0697i6wXLDCtebQrXV4N6OF2wgOQhYY3vZlOpfS5jChN+46JHq8 rtJ5nGhZW0F/IxsAIe8PxWSENZqje8A0SUrbSzG4/Twwv9lzaaSx8A8n7sscCyW6mHunUO9oH ragSuc2dGNNNVFR0rVQWWbH9uHInrMQHt8MNrcOisXNj8kM8E35p7x6FZvkSmax41yq2FpvDw 6IG6UA0pXIorY2TQzpq2NgQk7He0RIjrap/zzJpCdy01G4LVj+2Ep X-Rspamd-Queue-Id: E7F989A566 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 9:16 PM James Bottomley wrote: > On Mon, 2020-07-20 at 20:08 +0200, Arnd Bergmann wrote: > > On Mon, Jul 20, 2020 at 5:52 PM James Bottomley > > > > 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. > > Never say never, but current TEE designs tend to require full > confidentiality for the entire execution. What we're probing is > whether we can improve security by doing an API that requires less than > full confidentiality for the process. I think if the API proves useful > then we will get HW support for it, but it likely won't be in the > current TEE of today form. As I understand it, you normally have two kinds of buffers for the TEE: one that may be allocated by Linux but is owned by the TEE itself and not accessible by any process, and one that is used for communication between the TEE and a user process. The sharing would clearly work only for the second type: data that a process wants to share with the TEE but as little else as possible. A hypothetical example might be a process that passes encrypted data to the TEE (which holds the key) for decryption, receives decrypted data and then consumes that data in its own address space. An electronic voting system (I know, evil example) might receive encrypted ballots and sum them up this way without itself having the secret key or anything else being able to observe intermediate results. > > > 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? > > Well, that was what the previous patch did. I'm agnostic on the > mechanism for obtaining the fd: new syscall as this patch does or > extension to memfd like the old one did. All I was saying is that once > you have the fd, the API you use on it is the same as the memfd API. Ok. I suppose we could even retrofit dma-buf underneath the secretmemfd implementation if it ends up being useful later on, Arnd