| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 23, 2010 20:10 UTC (Wed) by gnb (subscriber, #5132)In reply to: SELF: Anatomy of an (alleged) failure by Kamilion Parent article: SELF: Anatomy of an (alleged) failure
One thing I may have missed in the original lkml discussion of FatELF is why this required any significant kernel work. ELF allows a file to contains plenty of sections, the section naming is flexible and the file can specify its own interpreter. So why what does a new file format achieve that can't be done by installing an ELF program loader that knows how to find the sections for the correct arch, and a standard ELF file that includes section data for all the supported arches and a .interp section that names said loader as its interpreter?
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 15:03 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
Or, even if a new format IS necessary, using binfmt_misc to load its custom dynamic linker that chooses the correct sections for the architecture? That strikes me as the obvious solution.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 16:39 UTC (Thu) by Spudd86 (guest, #51683) [Link]
FatELF isn't a new format, it's just ELF with special section set up for multi-arch stuff, the kernel needs to understand this so it can load them properly
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 19:05 UTC (Thu) by gnb (subscriber, #5132) [Link]
That's the bit I don't understand. Why can't it just hand the thing off to a custom program loader, either by specifying one in the .interp section or, as others have said, by using binfmt support?
|
|||||||||||||