linux-kernel - Re: [PATCH] x86, kdump: Set crashkernel

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, 11 Mar 2013 16:12:45 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	WANG Chao <chaowang@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, kdump: Set crashkernel_low automatically

On Mon, Mar 11, 2013 at 12:55:55PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:20 PM, Vivek Goyal wrote:
> > 
> > I find it odd that if a user wants to load a 32bit kernel or use 32bit
> > entry point then he needs to first reboot the kernel and re-reserve
> > the memory.
> > 
> > At installation time, one does not necessarily know what kind of kernel
> > will be used for crashdump. So reserving as high as possible limits
> > the choices.
> > 
> > I would rather prefer that user opt in for higher addresses instead of
> > these being reserved by default.
> > 
> 
> Quite frankly the whole design seems to be held together with chewing
> gum.  At the core, the problem is a tight coupling between kexec-tools
> version, kexec-tools options, and kernel command line options that have
> to be combined in very ugly ways.  Part of the reason is that the kernel
> isn't actually given the information it needs to do the job required.
> 
> As far as "if a user wants to load"... why on Earth should that be the
> default?  How could that *not* be an exceptional case?

Because it breaks existing user cases. We had this limitation so far
that bzImage has to be loaded in first 896MB. And for 32bit bzImage
entry, I think that is still true?

So how can kernel assume that user is always loading a 64bit bzImage
and reserve memory accordingly.

Also in the past we did not have relocatable kernel and memory had to
be reserved at the address new kernel is built. Thankfully that is
no more the case.

Thanks
Vivek
--
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/