lkml.org 
[lkml]   [2018]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv4 15/18] x86/mm: Calculate direct mapping size
    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?

    \
     
     \ /
      Last update: 2018-07-09 20:35    [W:7.027 / U:0.328 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site