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: <20070212135802.27041.qmail@web26910.mail.ukl.yahoo.com>
Date:	Mon, 12 Feb 2007 14:58:02 +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" <ebiederm@...ssion.com> wrote:
> What I was thinking is that in the not we place the physical address
> and length that we load the real mode code at.  My assumption being
> that we have marked the real mode code __init or the equivalent,
> so we always load and just ignore it later on.

 But Gujin need the real-mode part linked at zero and there isn't
anything linked at this address in the current Linux kernel, no
section at all. If you ask to do a separate link then I loose all
the symbols and the ELF standard tools are a lot less useable.

> Playing the games with the addresses does allow the existing debugging
> tools to work without problem because the end users of the code all
> examine the virtual not the physical address.

 The linker also resolve relocation in virtual addresses so this part
 needs virtual address = 0.

> I agree I want a reasonable bootloader as well.
>  [snip]
> ELF should make it much easier for people implementing simple
> stand-alone executables for testing.  As you don't even need a linker
> script or any fancy games if you don't take arguments.   Similarly
> the switch from linux to multi-boot that almost standard is just
> supporting a different argument passing format.

 There is plenty of possible future, but right now I have a simple
(OK, not perfect, but code is shown) solution which works.
I can modify bits, but there is no point complexifying the system
for possible theoretical problems - by experience you always miss
important future problem while overdesigning for some problem which
never appear.
If someone can show me a real problem - then I'd like to hear from him,
but ELF compatibility will not be up to the point where the user will
be able to run the kernel from a Xterm command line.

  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