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:0.168 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site