On Thu, Sep 24, 2020 at 07:34:28PM -0700, Andrew Morton wrote: > On Thu, 24 Sep 2020 16:28:58 +0300 Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > > From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > > > Hi, > > > > This is an implementation of "secret" mappings backed by a file descriptor. > > I've dropped the boot time reservation patch for now as it is not strictly > > required for the basic usage and can be easily added later either with or > > without CMA. > > > > ... > > > > The file descriptor backing secret memory mappings is created using a > > dedicated memfd_secret system call The desired protection mode for the > > memory is configured using flags parameter of the system call. The mmap() > > of the file descriptor created with memfd_secret() will create a "secret" > > memory mapping. The pages in that mapping will be marked as not present in > > the direct map and will have desired protection bits set in the user page > > table. For instance, current implementation allows uncached mappings. > > > > Although normally Linux userspace mappings are protected from other users, > > such secret mappings are useful for environments where a hostile tenant is > > trying to trick the kernel into giving them access to other tenants > > mappings. > > > > Additionally, the secret mappings may be used as a mean to protect guest > > memory in a virtual machine host. > > > > For demonstration of secret memory usage we've created a userspace library > > [1] that does two things: the first is act as a preloader for openssl to > > I can find no [1]. Oops, sorry. It's https://git.kernel.org/pub/scm/linux/kernel/git/jejb/secret-memory-preloader.git/ > I'm not a fan of the enumerated footnote thing. Why not inline the url > right here so readers don't need to jump around? > > -- Sincerely yours, Mike.
