I'm travelling this week, but I'll try to spend some time on it. -Kees On Mon, May 16, 2016 at 11:25 AM, Thomas Garnier <thgarnie@xxxxxxxxxx> wrote: > Any feedback on the patch? Ingo? Kees? > > Kees mentioned he will take care of the build warning on the KASLR > refactor (the function is not used right now). > > Thanks, > Thomas > > On Thu, May 12, 2016 at 12:28 PM, Thomas Garnier <thgarnie@xxxxxxxxxx> wrote: >> This is PATCH v5 for KASLR memory implementation for x86_64. >> >> Recent changes: >> Add performance information on commit. >> Add details on PUD alignment. >> Add information on testing against the KASLR bypass exploit. >> Rebase on next-20160511 and merge recent KASLR changes. >> Integrate feedback from Kees. >> >> ***Background: >> The current implementation of KASLR randomizes only the base address of >> the kernel and its modules. Research was published showing that static >> memory can be overwitten to elevate privileges bypassing KASLR. >> >> In more details: >> >> 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 base address and padding of three >> major memory sections (physical memory mapping, vmalloc & vmemmap). >> It mitigates exploits relying on predictable kernel addresses. This >> feature can be enabled with the CONFIG_RANDOMIZE_MEMORY option. >> >> 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. >> >> ***Problems that needed solving: >> - The three target memory sections are never at the same place between >> boots. >> - The physical memory mapping can use a virtual address not aligned on >> the PGD page table. >> - Have good entropy early at boot before get_random_bytes is available. >> - Add optional padding for memory hotplug compatibility. >> >> ***Parts: >> - The first part prepares for the KASLR memory randomization by >> refactoring entropy functions used by the current implementation and >> support PUD level virtual addresses for physical mapping. >> (Patches 01-02) >> - The second part implements the KASLR memory randomization for all >> sections mentioned. >> (Patch 03) >> - The third part adds support for memory hotplug by adding an option to >> define the padding used between the physical memory mapping section >> and the others. >> (Patch 04) >> >> Performance data: >> >> Kernbench shows almost no difference (-+ less than 1%): >> >> Before: >> >> Average Optimal load -j 12 Run (std deviation): >> Elapsed Time 102.63 (1.2695) >> User Time 1034.89 (1.18115) >> System Time 87.056 (0.456416) >> Percent CPU 1092.9 (13.892) >> Context Switches 199805 (3455.33) >> Sleeps 97907.8 (900.636) >> >> After: >> >> Average Optimal load -j 12 Run (std deviation): >> Elapsed Time 102.489 (1.10636) >> User Time 1034.86 (1.36053) >> System Time 87.764 (0.49345) >> Percent CPU 1095 (12.7715) >> Context Switches 199036 (4298.1) >> Sleeps 97681.6 (1031.11) >> >> Hackbench shows 0% difference on average (hackbench 90 >> repeated 10 times): >> >> attemp,before,after >> 1,0.076,0.069 >> 2,0.072,0.069 >> 3,0.066,0.066 >> 4,0.066,0.068 >> 5,0.066,0.067 >> 6,0.066,0.069 >> 7,0.067,0.066 >> 8,0.063,0.067 >> 9,0.067,0.065 >> 10,0.068,0.071 >> average,0.0677,0.0677 >> >> Thanks! >> -- 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
