linux-kernel - Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3

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-next>] [day] [month] [year] [list]

Message-ID: <848486.58910.qm@web26907.mail.ukl.yahoo.com>
Date:	Wed, 7 Feb 2007 14:55:39 +0000 (GMT)
From:	Etienne Lorrain <etienne_lorrain@...oo.fr>
To:	vgoyal@...ibm.com
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3

Vivek Goyal wrote:
>How do I know which program header is real mode code and the boot loader
> is not supposed to load it? May be PT_LOAD header with physical addr 0?
> What happens if changes happen and down the line we start compiling 
> real mode code for non-zero address?

 Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
different (like with virtual address at 0xC0000000) is Linux protected mode.
Considering the linker used it is always the 4th program header, before there
were only 3 program header,third one stay the NOTE one.

> Hence I think keeping real mode code out of vmlinux might prove to be a good idea.

 Well, ELF is a format made to describe what to load, at which addres, and I assume
everyone recognise that some ELF section shall not be loaded, like the debug information.
Gujin accepts having the real-mode treated like a program text and so in the program header,
or like extra memory block with content like the symbol table used by a debugger, I do not
know what is best so have implemented the two.

> Secondly, if you compile real mode code with vmlinux, what would be the
> entry point for this ELF file? Real mode entry? Then I have not way to
> find out from ELF headers where is the protected mode entry point and
> I can not do use this vmlinux with kexec/kdump.

 I did not touch the kernel entry point, the real mode entry point is at offset zero
in the real-mode program header/section table.

> OTOH, now bzImage is relocatable. Is this image going to be relocatable?
> How do we take care of that?

 Just I did not completely understand why you need relocation (and the announce
was when I was in holidays far away). I know a simple kernel is needed to do
some debugging when the main kernel has crashed, this kernel is better loaded
at for instance 16 Mbytes. You probably do not want the same kernel as the main
one because it may crash the same way, and you start a loop - and even then
if you have exactly the same kernel it is easier to use the same write-protected
block of memory with different data sections.
 But I probably do not understand the problem so do not know what to write.

  Thanks,
 Etienne.

___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com
-
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/