linux-kernel - Re: [RFC][PATCH 1/2] binfmt_elf: FatELF support in the binary loader.

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 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]

Date:	Tue, 20 Oct 2009 00:43:09 -0400 (EDT)
From:	"Ryan C. Gordon" <icculus@...ulus.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/2] binfmt_elf: FatELF support in the binary
 loader.

> The idea seem interesting, but does it need to be ELF-specific?  What
> about making the executable a simple archive file format (possibly just
> an "ar" archive?) which contains other executables.  The archive file
> format would be implemented as its own binfmt, and the internal
> executables could be arbitrary other executables.  The outer loader
> would just try execing each executable until one works (or it runs out).

I'm not sure the added flexibility is worth the extra complications. 
FatELF solves a specific problem: merging multiple ELF targets into one 
file, the most compelling use-case being to glue x86_64 and i686 binaries 
together.

What you're describing would definitely be the route I'd have chosen if, 
say, a.out files were still in widespread use and actively competed with 
ELF for mindshare.

> That is, what you have here, but without hacking up binfmt_elf more.

I like to think of it as art, like a chef carving a fine piece of meat. :)

--ryan.

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