This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: loading of shared objects and executables
- From: "Bolshakov, Roman" <Roman dot Bolshakov at emc dot com>
- To: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Cc: Michael Zintakis <michael dot zintakis at googlemail dot com>
- Date: Sat, 27 Oct 2012 19:05:22 +0000
- Subject: RE: loading of shared objects and executables
- References: <508BE980.9020903@googlemail.com>
> Currently, I am torn between adopting two quite different approaches
> (still have quite a bit to catch up on on the good reference Roman was
> kind enough to provide though): 1. attach all verification data at the
> end of a given executable/.so file (by "verification data" I mean, at
> the very least, a hash on the entire executable/.so file, calculated
> using a private key, and a signature ID - as text - for the public key
> to be used to verify that hash); or 2. create a separate header/section
> (called ".security" for example) and attach that verification data there.
As Linux uses ELF, I personally like the second approach as it's much more consistent.
> I'm inclined to use the second approach, not least because it could
> survive any potential stripping, though it would be more involved as I
> would have to, somehow, instruct the linker to create this additional
> section and also include the verification data just after the
> executable/.so file is built (in other words, to invoke the creation of
> the verification data as part of the linking process). If I adopt this
> route, I am still to figure out how to go about this as my knowledge of
> the gcc linker doesn't go that deep (yet!).
To make a custom section layout you can use linker scripts (http://sourceware.org/binutils/docs/ld/Scripts.html).