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" <>
To:	Jeremy Fitzhardinge <>
Subject: Re: [RFC][PATCH 1/2] binfmt_elf: FatELF support in the binary

> 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 

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. :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists