Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas
Andrew Morton <[email protected]> Wed, 5 May 2021 12:08:06 -0700
| Newsgroups | org.01.lists.linux-nvdimm,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-api,org.kernel.vger.linux-arch,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport <[email protected]> wrote: > This is an implementation of "secret" mappings backed by a file descriptor. > > 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 be present only in the page table of the owning mm. > > 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. I continue to struggle with this and I don't recall seeing much enthusiasm from others. Perhaps we're all missing the value point and some additional selling is needed. Am I correct in understanding that the overall direction here is to protect keys (and perhaps other things) from kernel bugs? That if the kernel was bug-free then there would be no need for this feature? If so, that's a bit sad. But realistic I guess. Is this intended to protect keys/etc after the attacker has gained the ability to run arbitrary kernel-mode code? If so, that seems optimistic, doesn't it? I think that a very complete description of the threats which this feature addresses would be helpful. _______________________________________________ Linux-nvdimm mailing list -- [email protected] To unsubscribe send an email to [email protected]