linux-kernel - Re: kdump broken on 2.6.37-rc4

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:	Thu, 16 Dec 2010 11:22:55 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Stanislaw Gruszka <sgruszka@...hat.com>,
	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Maxim Uvarov <muvarov@...il.com>, linux-kernel@...r.kernel.org,
	Neil Horman <nhorman@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: kdump broken on 2.6.37-rc4

On Thu, Dec 16, 2010 at 08:16:41AM -0800, H. Peter Anvin wrote:
> On 12/16/2010 02:00 AM, Stanislaw Gruszka wrote:
> > On Wed, Dec 15, 2010 at 08:29:01PM -0800, Yinghai Lu wrote:
> >> please check
> >>
> >> [PATCH] x86, crashkernel, 32bit: only try to get range under 512M
> >>
> >> Steanishlaw report kdump is 32bit is broken.
> > LOL
> > 
> >> in misc.c for decompresser, it will do sanity checking to make sure heap
> >> heap under 512M.
> >>
> >> So limit it in first kernel under 512M for 32bit system.
> >>
> >> Reported-by: Stanislaw Gruszka <sgruszka@...hat.com>
> >> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
> > 
> > Patch fix problem on my T-60 laptop.
> > 
> > As expected patch does not help on my other T-500 x86_64 system,
> > kdump not work there, but perhaps this is a different problem,
> > I'm going to check it.
> > 
> 
> I think limiting kdump below 512 MiB on 32 bits may make sense; perhaps
> even on 64 bits.  It's pretty conservative, after all...
> 
> Opinions?

Actually it will be good to know why 512MB. I know in the past we have
been talking of reserving memory in higher memory regions and Neil Horman
had been trying to boot bzImage in 64 bit mode so that it can be run
from higher addresses. 

So right now limiting it is easy but it is desirable to be able to run
bzImage from as high a address as possible and knowing why to limit it
to 512MB can help see if there is a way to get rid of that limitation.

I probably would not worry about 32bit systems but for 64 bit, I
cerntainly want to make it boot from higher addresses (if it is possible
technically).

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/