On Tue, Jun 21, 2016 at 8:46 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > This is v7 of Thomas Garnier's KASLR for memory areas (physical memory > mapping, vmalloc, vmemmap). It expects to be applied on top of the > x86/boot tip. > > The current implementation of KASLR randomizes only the base address of > the kernel and its modules. Research was published showing that static > memory addresses can be found and used in exploits, effectively ignoring > base address KASLR: > > The physical memory mapping holds most allocations from boot and > heap allocators. Knowning the base address and physical memory > size, an attacker can deduce the PDE virtual address for the vDSO > memory page. This attack was demonstrated at CanSecWest 2016, in > the "Getting Physical: Extreme Abuse of Intel Based Paged Systems" > https://goo.gl/ANpWdV (see second part of the presentation). The > exploits used against Linux worked successfuly against 4.6+ but fail > with KASLR memory enabled (https://goo.gl/iTtXMJ). Similar research > was done at Google leading to this patch proposal. Variants exists > to overwrite /proc or /sys objects ACLs leading to elevation of > privileges. These variants were tested against 4.6+. > > This set of patches randomizes the base address and padding of three > major memory sections (physical memory mapping, vmalloc, and vmemmap). > It mitigates exploits relying on predictable kernel addresses in these > areas. This feature can be enabled with the CONFIG_RANDOMIZE_MEMORY > option. (This CONFIG, along with CONFIG_RANDOMIZE may be renamed in > the future, but stands for now as other architectures continue to > implement KASLR.) > > Padding for the memory hotplug support is managed by > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. The default value is 10 > terabytes. > > The patches were tested on qemu & physical machines. Xen compatibility was > also verified. Multiple reboots were used to verify entropy for each > memory section. > > Notable problems that needed solving: > - The three target memory sections need to not be at the same place > across reboots. > - The physical memory mapping can use a virtual address not aligned on > the PGD page table. > - Reasonable entropy is needed early at boot before get_random_bytes() > is available. > - Memory hotplug needs KASLR padding. > > Patches: > - 1: refactor KASLR functions (moves them from boot/compressed/ into lib/) > - 2: clarifies the variables used for physical mapping. > - 3: PUD virtual address support for physical mapping. > - 4: split out the trampoline PGD > - 5: KASLR memory infrastructure code > - 6: randomize base of physical mapping region > - 7: randomize base of vmalloc region > - 8: randomize base of vmemmap region > - 9: provide memory hotplug padding support > > There is no measurable performance impact: > > - Kernbench shows almost no difference (-+ less than 1%). > - Hackbench shows 0% difference on average (hackbench 90 repeated 10 times). Hi again, Just a friendly ping -- I'd love to get this into -tip for wider testing. Thanks! -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
