linux-kernel - Re: [PATCH 12/12] i386 boot: Add an ELF header to bzImage

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:	Wed, 4 Oct 2006 16:48:29 -0400
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...l.org>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Reloc Kernel List <fastboot@...ts.osdl.org>, ak@...e.de,
	horms@...ge.net.au, lace@...kratochvil.net, magnus.damm@...il.com,
	lwang@...hat.com, dzickus@...hat.com, maneesh@...ibm.com
Subject: Re: [PATCH 12/12] i386 boot: Add an ELF header to bzImage

On Wed, Oct 04, 2006 at 01:27:49PM -0700, H. Peter Anvin wrote:
> Vivek Goyal wrote:
> >
> >Eric/Peter,
> >
> >How about just extending bzImage format to include some info in real mode
> >kernel header. Say protocol version 2.05. I think if we just include two
> >more fields, is kernel relocatable and equivalent of ELF memsz, then 
> >probably
> >this information should be enough for kexec bzImage loader to load and run
> >a relocatable kernel from a different address.
> >
> 
> What would be the exact semantics of the "equivalent of ELF memsz"?  I 
> have balked on that one in the past, because the proposed semantics were 
> unsafe.
> 

memsz will contain the memory required to load the kernel image. And
probably should also include the memory used by kernel in initial boot
up code which is unaccounted and unbounded.

> I suspect we need at least one more piece of data, which is the required 
> alignment of a relocated kernel.

Now with the introduction of config option CONFIG_PHYSICAL_ALIGN, it
should be easy to get.

>  Either which way, it seems clear that 
> there is some re-engineering that needs to be done, and I think we need 
> to better understand *why* the proposed patch failed.
> 
> Can this failure be reproduced in a simulator?

I will try to reproduce in a simulator. May be qemu? Any suggestions?

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/