Messages in this thread | | | Date | Mon, 17 May 2021 10:23:09 +0300 | From | Mike Rapoport <> | Subject | Re: [PATCH v19 5/8] mm: introduce memfd_secret system call to create "secret" memory areas |
| |
On Fri, May 14, 2021 at 10:50:55AM +0200, David Hildenbrand wrote: > On 13.05.21 20:47, Mike Rapoport wrote: > > From: Mike Rapoport <rppt@linux.ibm.com> > > > > Removing of the pages from the direct map may cause its fragmentation > > on architectures that use large pages to map the physical memory > > which affects the system performance. However, the original Kconfig > > text for CONFIG_DIRECT_GBPAGES said that gigabyte pages in the direct > > map "... can improve the kernel's performance a tiny bit ..." (commit > > 00d1c5e05736 ("x86: add gbpages switches")) and the recent report [1] > > showed that "... although 1G mappings are a good default choice, > > there is no compelling evidence that it must be the only choice". > > Hence, it is sufficient to have secretmem disabled by default with > > the ability of a system administrator to enable it at boot time. > > Maybe add a link to the Intel performance evaluation.
" ... the recent report [1]" and the link below.
> > Pages in the secretmem regions are unevictable and unmovable to > > avoid accidental exposure of the sensitive data via swap or during > > page migration.
...
> > A page that was a part of the secret memory area is cleared when it > > is freed to ensure the data is not exposed to the next user of that > > page. > > You could skip that with init_on_free (and eventually also with > init_on_alloc) set to avoid double clearing.
Right, but for now I'd prefer to keep this explicit in the secretmem implementation. We may add the check for init_on_free/init_on_alloc later on.
> > [1] > > https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/ >
-- Sincerely yours, Mike.
| |