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 8B82BC433E8 for ; Mon, 20 Jul 2020 14:27:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5072722B4D for ; Mon, 20 Jul 2020 14:27:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="XQFs0H8a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5072722B4D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D75678D0001; Mon, 20 Jul 2020 10:27:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFD5A6B0008; Mon, 20 Jul 2020 10:27:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC7288D0001; Mon, 20 Jul 2020 10:27:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id A5AC66B0007 for ; Mon, 20 Jul 2020 10:27:34 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6ABA74A841E4 for ; Mon, 20 Jul 2020 14:27:34 +0000 (UTC) X-FDA: 77058682428.14.crib97_3c1761926f25 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id B87AF181A8B34 for ; Mon, 20 Jul 2020 14:21:10 +0000 (UTC) X-HE-Tag: crib97_3c1761926f25 X-Filterd-Recvd-Size: 4818 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 14:21:10 +0000 (UTC) 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: X-Rspamd-Queue-Id: B87AF181A8B34 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 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.