linux-kernel - Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.02.1209101053320.28681@xanadu.home>
Date:	Mon, 10 Sep 2012 11:00:07 -0400 (EDT)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 02/31] arm64: Kernel booting and initialisation

On Mon, 10 Sep 2012, Arnd Bergmann wrote:

> On Monday 10 September 2012, Nicolas Pitre wrote:
> > On Mon, 10 Sep 2012, Arnd Bergmann wrote:
> > > On Monday 10 September 2012, Catalin Marinas wrote:
> > > > On Mon, Sep 10, 2012 at 06:53:39AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > I think a bunch of other architectures can have relocatable kernels, which
> > > is useful e.g. for kdump. It does imply a small runtime cost and may have
> > > other disadvantages though.
> > 
> > Relocatable in physical space is what kdump actually needs, and that's 
> > what we already have here (as well as on ARM32 for that matter with 
> > CONFIG_ARM_PATCH_PHYS_VIRT).  Relocatable in the virtual space is costly 
> > and we shouldn't need to go there.
> 
> Ah, I see. I thought that the other architectures (powerpc and x86)
> doing this were actually building with -fPIC, but they do the same
> kind of early patching that we do.

This being said, on ARM we don't take advantage of this physically 
relocatable attribute with kdump.  Granted, PATCH_PHYS_VIRT was 
introduced after kdump support, therefore the kernel had to be copied at 
its expected physical location after the memory content there had been 
preserved.  These days the only thing that kdump would need to do is to 
just boot the kdump kernel in place with its reserved memory range and 
let it ioremap the previous kernel's memory for analysis.


Nicolas
--
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/