Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753339AbaDUR4F (ORCPT ); Mon, 21 Apr 2014 13:56:05 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:40596 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752463AbaDUR4D (ORCPT ); Mon, 21 Apr 2014 13:56:03 -0400 MIME-Version: 1.0 In-Reply-To: <20140421105232.GB4564@dhcp-17-89.nay.redhat.com> References: <20140421105232.GB4564@dhcp-17-89.nay.redhat.com> Date: Mon, 21 Apr 2014 10:56:02 -0700 X-Google-Sender-Auth: oCyLdRZU1-SnKXqUT0RPMnd8JSE Message-ID: Subject: Re: kaslr relocation incompitable with kernel loaded high From: Yinghai Lu To: WANG Chao Cc: Kees Cook , "H. Peter Anvin" , Zhang Yanfei , Vivek Goyal , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao 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 ? Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/