On Tue, Jun 26, 2018 at 05:22:42PM +0300, Kirill A. Shutemov wrote: > The kernel needs to have a way to access encrypted memory. We have two > option on how approach it: > > - Create temporary mappings every time kernel needs access to encrypted > memory. That's basically brings highmem and its overhead back. > > - Create multiple direct mappings, one per-KeyID. In this setup we > don't need to create temporary mappings on the fly -- encrypted > memory is permanently available in kernel address space. > > We take the second approach as it has lower overhead. > > It's worth noting that with per-KeyID direct mappings compromised kernel > would give access to decrypted data right away without additional tricks > to get memory mapped with the correct KeyID. > > Per-KeyID mappings require a lot more virtual address space. On 4-level > machine with 64 KeyIDs we max out 46-bit virtual address space dedicated > for direct mapping with 1TiB of RAM. Given that we round up any > calculation on direct mapping size to 1TiB, we effectively claim all > 46-bit address space for direct mapping on such machine regardless of > RAM size. > > Increased usage of virtual address space has implications for KASLR: > we have less space for randomization. With 64 TiB claimed for direct > mapping with 4-level we left with 27 TiB of entropy to place > page_offset_base, vmalloc_base and vmemmap_base. > > 5-level paging provides much wider virtual address space and KASLR > doesn't suffer significantly from per-KeyID direct mappings. > > It's preferred to run MKTME with 5-level paging. Why not make this a config dependency then?
