From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RWFdU-0008Ra-2x for garchives@archives.gentoo.org; Thu, 01 Dec 2011 23:01:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CC66721C069; Thu, 1 Dec 2011 23:01:38 +0000 (UTC) Received: from karnak.local (cpc2-lutn10-2-0-cust603.9-3.cable.virginmedia.com [81.97.90.92]) by pigeon.gentoo.org (Postfix) with ESMTP id 677A621C024 for ; Thu, 1 Dec 2011 23:00:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by karnak.local (Postfix) with ESMTP id 7159D3003 for ; Thu, 1 Dec 2011 23:00:22 +0000 (GMT) X-Virus-Scanned: amavisd-new at local Received: from karnak.local ([127.0.0.1]) by localhost (karnak.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEB76cKB1Y6M for ; Thu, 1 Dec 2011 23:00:20 +0000 (GMT) Received: from karnak.local (localhost [127.0.0.1]) by karnak.local (Postfix) with ESMTP id 5AAD33002 for ; Thu, 1 Dec 2011 23:00:20 +0000 (GMT) Date: Thu, 1 Dec 2011 23:00:14 +0000 From: David W Noon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Full disk encryption Message-ID: <20111201230014.6049d618@karnak.local> In-Reply-To: References: <20111130152753.176a9a08@hactar.digimed.co.uk> <4ED67664.1060302@gmail.com> <20111130202828.34f30c74@karnak.local> <20111130214733.19888eb1@digimed.co.uk> <20111130220735.5105ba14@karnak.local> <20111130232656.45b21f47@digimed.co.uk> <20111201002706.5a77f2fd@karnak.local> <20111201012312.385dcf5c@memphis.local> Organization: Luton Operatic Society X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/KpMoiDXF8H96cIZyvnQ/K.J"; protocol="application/pgp-signature" X-Archives-Salt: 89b9dc44-40ca-4da8-a14f-aef4a1e51376 X-Archives-Hash: d2929f8187d381427013e6623d4cc461 --Sig_/KpMoiDXF8H96cIZyvnQ/K.J Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 > 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. =C2=A0I am already using gzip -9, and binaries don't compre= ss > > especially well. =C2=A0Moreover, the archiver *must* be cpio, not tar. >=20 > I don't understand initrd that well, but I understand you run an > init-type script inside it. >=20 > 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. >=20 > 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). --=20 Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwnoon@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* --Sig_/KpMoiDXF8H96cIZyvnQ/K.J Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7YBwQACgkQc9/LpQ70v4+KiACfdwqtnu6bze6D2OS2nuWmh6EU QAYAoKgtJJ7F0hDgDqOGBECOKa7YtVHW =dWxN -----END PGP SIGNATURE----- --Sig_/KpMoiDXF8H96cIZyvnQ/K.J--