linux-kernel - Re: kaslr relocation incompitable with kernel loaded high

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Apr 2014 21:58:35 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	WANG Chao <chaowang@...hat.com>
Cc:	Kees Cook <keescook@...omium.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Zhang Yanfei <zhangyanfei@...fujitsu.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kaslr relocation incompitable with kernel loaded high

On Mon, Apr 21, 2014 at 8:16 PM, WANG Chao <chaowang@...hat.com> wrote:
> On 04/21/14 at 11:01am, Kees Cook wrote:
>> On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu <yinghai@...nel.org> wrote:
>> > On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao <chaowang@...hat.com> wrote:
>> >> Hi, Kees
>> >>
>> >> When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded
>> >> high, it doesn't boot.
>> >>
>> >> I reserved 128M memory at high with kernel cmdline
>> >> "crashkernel=128M,high crashkernel=0,low", and for which I got:
>> >>
>> >> [    0.000000] Reserving 128MB of memory at 6896MB for crashkernel (System RAM: 6013MB)
>> >>
>> >> Then I load kdump kernel into the reserved memory region, using a local
>> >> modified kexec-tools which is passing e820 in boot_params.
>> >>
>> >> The e820 map of system RAM passed to 2nd kernel:
>> >>
>> >> E820 memmap (of RAM):
>> >> 0000000000001000-000000000009e3ff (1)
>> >> 00000001af000000-00000001b6f5dfff (1)
>> >> 00000001b6fff400-00000001b6ffffff (1)
>> >>
>> >> In which, 2nd kernel is loaded at 0x1b5000000.
>> >>
>> >> After triggerred a system crash, 2nd kernel doesn't boot even with
>> >> "nokaslr" cmdline:
>> >>
>> >> # echo c > /proc/sysrq-trigger
>> >> [..]
>> >>
>> >> I'm in purgatory
>> >> early console in decompress_kernel
>> >> KASLR disabled...
>> >>
>> >> Decompressing Linux... Parsing ELF... Performing relocations...
>> >>
>> >> 32-bit relocation outside of kernel!
>> >
>> > Interesting, when kernel get at "early console in decompress_kernel"
>> > kernel already in 64 bit...
>> >
>> > what does it mean "32-bit relocation outside of kernel" ?
>> >
>> > why 32-bit is involved ?
>>
>> The 64-bit kernel has both 64 and 32 bit relocations (there are two
>> tables at the end of the kernel image). The error means that the
>> resulting relocation is believed to be outside the kernel image:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/misc.c#n283
>>
>> Which means there is likely something wrong with this calculation in
>> your situation:
>>
>> /*
>>  * Calculate the delta between where vmlinux was linked to load
>>  * and where it was actually loaded.
>>  */
>> delta = min_addr - LOAD_PHYSICAL_ADDR;
>>
>
> Probably.

Please check attached that patch that will solve nokaslr.

Somehow I got "KASLR could not find suitable E820 region..."
so i only have "No relocation needed"

will check that later.

View attachment "aslr_1.patch" of type "text/x-patch" (1854 bytes)