On 04/15/2013 03:38 PM, Yinghai Lu 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.
That seems really, really odd. > so the decompressed image is not moved high? This really seems wrong in so many ways. If you relocate pre-decompression the amount of memory you need is given by init_size: #define ZO_INIT_SIZE (ZO__end - ZO_startup_32 + ZO_z_extract_offset) #define VO_INIT_SIZE (VO__end - VO__text) #if ZO_INIT_SIZE > VO_INIT_SIZE #define INIT_SIZE ZO_INIT_SIZE #else #define INIT_SIZE VO_INIT_SIZE #endif init_size: .long INIT_SIZE # kernel initialization size In real life, VO_INIT_SIZE dominates almost every time. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/