| 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
| ||
|
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/
Powered by blists - more mailing lists