linux-kernel - why the decompressed procedure move kernel from address 0x100000(1M) to 0x1000000(16M) +x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 May 2012 13:56:07 +0800
From:	hacklu <embedway.linux@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: why the decompressed procedure move kernel from address 0x100000(1M)
 to 0x1000000(16M) +x

hi all,
recently, I got some puzzle when I read source code of the system boot. 
I need some help.

at the end of src/arch/x86/boot/header.S,  kernel jump to 0x100000(where 
is the src/arch/x86/boot/compressed/head_32.S).
in __this__ head_32.S, I found the kernel is move to 0x1000000(mostly is 
to here) +x. the x distance is used for decompressed buf.  must leave 
some distance for decompressing without overlap.

after the move, kernel is decompressed at 0x1000000(16m). and jump to it.

so why not decompressed kernel at 0x100000(1M) to 0x1000000(16m) 
directly without moving?

is the move necessary?

thanks for reading above.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/