On Thu 29-03-18 15:37:12, Kirill A. Shutemov wrote: > On Thu, Mar 29, 2018 at 01:20:34PM +0200, Michal Hocko wrote: > > On Wed 28-03-18 19:55:32, Kirill A. Shutemov wrote: > > > Modify several page allocation routines to pass down encryption KeyID to > > > be used for the allocated page. > > > > > > There are two basic use cases: > > > > > > - alloc_page_vma() use VMA's KeyID to allocate the page. > > > > > > - Page migration and NUMA balancing path use KeyID of original page as > > > KeyID for newly allocated page. > > > > I am sorry but I am out of time to look closer but this just raised my > > eyebrows. This looks like a no-go. The basic allocator has no business > > in fancy stuff like a encryption key. If you need something like that > > then just build a special allocator API on top. This looks like a no-go > > to me. > > The goal is to make memory encryption first class citizen in memory > management and not to invent parallel subsysustem (as we did with hugetlb). How do you get a page_keyid for random kernel allocation? > Making memory encryption integral part of Linux VM would involve handing > encrypted page everywhere we expect anonymous page to appear. How many architectures will implement this feature? -- Michal Hocko SUSE Labs
