On 03/24/17 at 10:24am, Ingo Molnar wrote: > > * Dave Young <dyoung@xxxxxxxxxx> wrote: > > > > > So I applied this kexec fix and extended the changelog to clearly show why > > > > this fix matters in practice. > > > > > > I thought it only impacts kexec, but Dave thought it will impact 1st kenrel > > > either. > > > > Yes, I think no need to mention kexec, it is a general issue. > > > > First, the space is reserved for EFI, so kernel should not use it for kaslr. > > It's the kernel's EFI code, and we map whatever address we want (and then pass > that to the EFI runtime), so wether it's randomized or not is the Linux kernel's > policy decision... > > So that's my question: can these memory regions include security sensitive data, > and if yes, how can we best randomize it while kexec and other kernel and EFI > features still work? It doesn't corrupt kernel possibly because: 1) there's espfixup stack region between them if CONFIG_X86_ESPFIX64 is enabled, then the upper limit of kaslr VA space for randomization could be ESPFIX_BASE_ADDR. Fedora default to enable ESPFIX_BASE_ADDR. ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) ... unused hole ... ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB) ... unused hole ... ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks ... unused hole ... ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space 2) Though ESPFIX_BASE_ADDR is disabled, efi region is included into kaslr mm va space, efi is allocated top-down in 64G, while vmemmap is 1T large and allocated bottom-up, it rarely used up 1TB space to map struct page. 3) most of the time, it might not randomize vmemmap to occupy the efi region. So up to now, no corruption is heard about this bug. Thanks Baoquan