[LSF/MM ATTEND] Memory encryption, Large VA, pte helpers, THP

[LSF/MM ATTEND] Memory encryption, Large VA, pte helpers, THP

[Kirill A. Shutemov]

Hi,

I would like to attend upcoming summit.

There are few topics I would like to discuss:

- Memory encryption

Future Intel CPUs would have support of hardware memory encryption[1] --
Multi-Key Total Memory Encryption (MKTME below).

The feature allows to have several encryption domain. Each domain may have
own key (provided by user or generated by CPU). Few bits of PFN in PTE is
claimed to specify KeyID of the page.

I would like to make encrypted memory a first-class citizen in the kernel
memory management.

There are a number of challenges coming with the enabling:

  - API has to be generic enough to cover different HW implementations and
    flexible enough to cover functionality provided by HW.

    We need two interfaces: to setup keys and to setup encrypted memory
    mappings.

  - Page allocator has to be modified to flush CPU cache when changing
    encryption KeyID for the page. With MKTME, the same page with mapped
    with different KeyID may allias in cache.

  - Kernel cannot access encrypted memory via direct map. It's not
    feasible to modify direct map to always have correct KeyID for the
    page. We would need to find other way to access encrypted pages.

    I think of re-using kmap() interface (yay! hihgmem is back!) for this,
    but without highmem zone.

  - For kmap() to work we would need a way to map a page to a KeyID.

    There's no way we would be able to find enough space struct page for
    this.

    At the moment my idea is to stash KeyID into anon_vma.

- Future extension to large virtual address space

Aneesh wanted to discuss the topic. I'm interested in the topic, but don't
have anything specific to bring right now.

- Page table manipulation primitives

The API we have for page table manipulation is outdated. It wasn't
designed to handle situation that are common nowadays: huge page, variable
number of page table levels (run-time or compile-time swichable). Just
adding new page table level is painful.

The cumbersome API also leads to stupid mistakes. During 5-level paging
enabling I had few very bug that can be attributed to poor API.
Manipulation of top-level page table is especially painful. See
sync_global_pgds() on x86-64 for instance.

We need to come up with something better before we would need 6-level
paging :)

I'll try to come up with a toy prototype for a new data types and API
before the summit.

- THP

Unfortunately, I had no time to do anything substantial in the area this
year, but I would like to attend any discussion on the topic.

[1] https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>