Re: [gentoo-user] Re: Full disk encryption

[David W Noon]

On Thu, 1 Dec 2011 11:41:50 -0500, Michael Mol wrote about Re:
[gentoo-user] Re: Full disk encryption:

> On Wed, Nov 30, 2011 at 8:23 PM, David W Noon <dwnoon@××××××××.com>
> wrote:
> > On Wed, 30 Nov 2011 19:39:11 -0500, Michael Mol wrote about "Re:
> > [gentoo-user] Re: Full disk encryption":
> >
> > [snip]
> >>Stupid question...Would using LZMA and a tarball reduce the size of
> >>your initeamfs?
> >
> > Not really.  I am already using gzip -9, and binaries don't compress
> > especially well.  Moreover, the archiver *must* be cpio, not tar.
>
> I don't understand initrd that well, but I understand you run an
> init-type script inside it.
>
> My thought was:
> 1) Include enough in your cpio blob to extract a .tar.xz file. Even
> better if you can use a self-extracting, statically-linked LZMAball.
> 2) launch a second-stage init sequence from the
> subsequently-extracted data.
>
> Large groups of binaries can compress pretty well, but, obviously, it
> depends greatly on the data in question.

The initramfs is already a compressed archive.  It can be compressed
using gzip, bzip2 or lzma/xz.  All of these give only modest reduction
in size.

> Also, wasn't there an ELF-specific compressor making the rounds a few
> months ago? And I take it there are no existing tools to take a
> dynamically-linked binary, pack in all the pulled-in files, rewrite
> symbol tables to include only the symbols used, pull the thing all
> into a single now-statically-linked binary, and perform something like
> COMDAT folding to remove duplicate functions? It would seem possible,
> at least.

The problem with that is that internal references within a .so library
are somewhat ambiguous, because the address constants have already been
partially relocated, eliminating symbol dictionary lookups (i.e.
references that were originally external have been made internal by
symbol dictionary lookup and then the symbol converted into an offset
within the load library).

In contrast, an ar-format library is simply a collection of object
decks (old mainframe term) indexed by their external symbols.  Thus the
linker is forced to keep doing symbol dictionary lookups and object
code extraction from libraries until all the external references have
been resolved.  There are no unresolved external references left in a
correctly linked .so library, so this process cannot be repeated.

The only feasible option I can think of is to use a full delinker on
the main program. [I wrote one of these delinkers for the IBM mainframe
back in the 1980s, so it's a technology I understand fairly well.] This
would reverse all the partially relocated addresses back to external
references by a reverse lookup in the symbol dictionary and relocation
dictionary.  This could restore the original object deck(s) of the main
program and it/they could be relinked using the static libraries (if
they exist).
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@××××××××.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*