On Fri, Apr 26, 2013 at 2:51 PM, Yinghai Lu <ying...@kernel.org> wrote: > On Fri, Apr 26, 2013 at 12:03 PM, Kees Cook <keesc...@chromium.org> wrote: >> This chooses the largest contiguous RAM region for the KASLR offset >> to live in. >> >> Signed-off-by: Kees Cook <keesc...@chromium.org> >> --- >> v2: >> - make sure to exclude e820 regions outside the 32-bit memory range. > > Do you need to execlude range that is used for initrd and possible > command_line and boot_param ?
Yeah, and while doing a stress test here, I realized there's another problem. In the original version of this, the stack and heap are set up after relocation. In the C port, they're set up before, so there's even more to avoid. To illustrate... here's a CONFIG_RELOCATABLE=n boot: LOAD_PHYS:0x0000000001000000 input: 0x0000000001dfe24d-0x00000000023db865 output: 0x0000000001000000-0x00000000023c98c0 heap: 0x00000000023e0740-0x00000000023e8740 stack: 0x00000000023ec698 chosen: 0x0000000001000000 (stack is just cheating and reporting sp in decompress_kernel) And a CONFIG_RELOCATABLE=y and "noaslr" boot: LOAD_PHYS:0x0000000001000000 input: 0x000000000108b25e-0x00000000016b3e96 output: 0x0000000000200000-0x00000000016a1db8 heap: 0x00000000016b9600-0x00000000016c1600 stack: 0x00000000016c5558 chosen: 0x0000000000200000 In that case, it's just so far under LOAD_PHYSICAL_START that it's safe. But if KASLR picks an area overlapping input, heap, or stack it's hosed. :) -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
