archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <>
To: "James E.J. Bottomley" <>
Cc: Mike Rapoport <>,
	"" <>,
	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-riscv <>,
	"the arch/x86 maintainers" <>,,
	Sumit Semwal <>
Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas
Date: Mon, 20 Jul 2020 20:08:43 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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?


  reply	other threads:[~2020-07-20 18:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20  9:24 [PATCH 0/6] mm: introduce secretmemfd system call to create "secret" memory areas Mike Rapoport
2020-07-20  9:24 ` [PATCH 1/6] mm: add definition of PMD_PAGE_ORDER Mike Rapoport
2020-07-20  9:24 ` [PATCH 2/6] mmap: make mlock_future_check() global Mike Rapoport
2020-07-20  9:24 ` [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas Mike Rapoport
2020-07-20 11:30   ` Arnd Bergmann
2020-07-20 14:20     ` Mike Rapoport
2020-07-20 14:34       ` Arnd Bergmann
2020-07-20 17:46         ` Mike Rapoport
2020-07-20 15:51     ` James Bottomley
2020-07-20 18:08       ` Arnd Bergmann [this message]
2020-07-20 19:16         ` James Bottomley
2020-07-20 20:05           ` Arnd Bergmann
2020-07-21 10:59   ` Michael Kerrisk (man-pages)
2020-07-20  9:24 ` [PATCH 4/6] arch, mm: wire up secretmemfd system call were relevant Mike Rapoport
2020-07-26 17:44   ` Palmer Dabbelt
2020-07-20  9:24 ` [PATCH 5/6] mm: secretmem: use PMD-size pages to amortize direct map fragmentation Mike Rapoport
2020-07-20  9:24 ` [PATCH 6/6] mm: secretmem: add ability to reserve memory at boot Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).