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]
Message-ID: <687898.45581.qm@web26907.mail.ukl.yahoo.com>
Date:	Mon, 12 Feb 2007 11:42:21 +0100 (CET)
From:	Etienne Lorrain <etienne_lorrain@...oo.fr>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	vgoyal@...ibm.com, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org
Subject: Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3

--- "Eric W. Biederman" wrote:
> So I really don't care if we move whole real mode section into a note
> or if we just put a pointer to it into a note.  What is important is
> that we use a note to find it.

 Well, we can advertise by a note the section number or the section
name which contains the real-mode code, but finding the section of
type SHT_PROGBITS having SHF_EXECINSTR flags linked at zero is not
that difficult to do: it is what Gujin does right now when it does
not find the program header linked at zero.

> Which means that we could do something goofy in the linker script
> like we do with the current vdso.  So we could give it a virtual
> address of 0 and a physical address in the init code section.

 Gujin loads at the physical address, i.e. kernel is loaded at
0x100000 and not 0xC0100000, is that wrong?
 I am not sure playing these games with addresses is cleaner than
not loading a section which is not in the program header.

> For me the objective is not so much reusing the existing tools
> (although that is a plus) but more to be able to build a unified
> binary that can be used for everything, and will give us the freedom
> to do interesting things with the kernel in the future, and hopefully
> something that is more or less usable by portable bootloaders.  Having
> a different file format and different rules for different
> architectures is a pain.

 For me the objective is to have a reasonable bootloader,
I will not have the time to port back and test with every other
bootloader some transfert of code from Gujin to an ELF looking
like bzImage file.

  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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ