Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751918AbaBGXQl (ORCPT ); Fri, 7 Feb 2014 18:16:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45968 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbaBGXQk (ORCPT ); Fri, 7 Feb 2014 18:16:40 -0500 Date: Sat, 8 Feb 2014 07:16:26 +0800 From: Dave Young To: Vivek Goyal Cc: "H. Peter Anvin" , Kees Cook , Cong Ding , Richard Weinberger , Kexec Mailing List , Linux Kernel Mailing List , Mathias Krause , Michael Davidson , Wei Yongjun , Thomas Gleixner , "H. Peter Anvin" , Yinghai Lu , Ingo Molnar , Linus Torvalds , Ingo Molnar Subject: Re: [GIT PULL] x86/kaslr for v3.14 Message-ID: <20140207231626.GA3840@dhcp-16-126.nay.redhat.com> References: <201401201647.s0KGlZdh004167@tazenda.hos.anvin.org> <52E5EFAF.3060609@linux.intel.com> <52E601DA.7010605@zytor.com> <20140130220708.GP9951@redhat.com> <20140207144914.GA5949@redhat.com> <52F503FD.8080607@linux.intel.com> <20140207162408.GD6967@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140207162408.GD6967@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/07/14 at 11:24am, Vivek Goyal wrote: > On Fri, Feb 07, 2014 at 08:04:13AM -0800, H. Peter Anvin wrote: > > On 02/07/2014 06:49 AM, Vivek Goyal wrote: > > > > > > Hi Kees, > > > > > > Dave Young is testing kdump with kaslr enabled. He is facing some issues. > > > > > > One issue he mentioned is that when second kernel boots, it might be > > > placed in an area which is outside the reserved area for second kernel. > > > > > > We reserve a certain memory for second kernel. And modify memory map of > > > second kernel using memmap=exactmap parameter. Looks like kernel placement > > > is happening before memmap=exactmap takes effect. And that seems to be > > > the reason that second kernel can be placed outside the reserved memory. > > > > > > IOW, memmap=exactmap and kaslr don't work together. Is it possible to > > > first let memmap=exactmap take affect and then kaslr does its job. Or it > > > is too late by the time memmap=exactmap is parsed. > > > > > > As a workaround, Dave is currently using "nokaslr" command line parameter > > > for second kernel. He is still facing issues where makedumpfile segment > > > faults. He is looking into it further. > > > > > > I thought I will atleast bring up with issue of memmap=exactmap and kaslr > > > being incompatible. > > > > > > > Yes, because memmap=exactmap gets parsed too late; kaslr assumes that > > the e820 information passed to it is actually correct. > > > > Yet another cause of breakage caused by the decision on the part of > > kdump to rely on command-line options. > > [CC kexec mailing list] > > Ok, I think this is high time we change kexec-tools to not use > memmap=exactmap and start passing modified memory map in bootparams. I > think only concern with that change was backward compatibility of > kexec-tools with older kernels. > > IIUC, only thing which will be impacted by this change is users of > saved_max_pfn which determine the highest accessible pfn in first > kernel. Some calgary IOMMU code seems to be the only user of it now. > > So may be we can create a new command line option say --pass-memmap-cmdline > to kexec-tools which forces old behavior and by default we pass memmap > in bootparams. > > Or create --do-not-pass-memmap-cmdline and new users will use it. Default > will be old behavior. Hi Vivek, Chaowang is looking into passing setup_data SETUP_E820_EXT instead of using exactmap. Previously Thomas Renninger tried passing them in e820. I did not find the old thread, but I remember it's not enough because of the 128 entries limitation. In case for kaslr, I agree that it do not make sense for kdump kernel. IMHO it's better to disable it automaticlly for kdump kernel but we can use the nokaslr as workaround for now. Thanks Dave -- 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/