On Mon, Apr 15, 2013 at 3:38 PM, Yinghai Lu <ying...@kernel.org> wrote: > On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook <keesc...@chromium.org> wrote: >> On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu <ying...@kernel.org> wrote: >>> also do not overlap with boot_param, command_line, and initrd. >>> >>> and need to double check setup_header.init_size to make sure bss and >>> etc will not >>> fall into memory hole or reserved area in e820. >>> >>> also may need to setup page table for target position as bootloader may only >>> has ident mapping only for loaded bzImage 64 areas. >>> >>> looks you are trying redo the work for bootloader to pick loaded phys addr. >> >> aslr.S's select_aslr_address uses z_extract_offset as the upper bound. > > so the decompressed image is not moved high?
No, I mean the size of the relocated image is using z_extract_offset as the end size of the relocated memory. See select_aslr_address. It takes the chosen aslr offset plus the location of z_extract_offset and keeps reducing the offset until it's inside the physical end of memory. -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/
