Message-ID: <20090901005120.GB22049@resivo.wgnet.de>
Date:	Tue, 1 Sep 2009 02:51:20 +0200
From:	Jonas Meurer <jonas@...esources.org>
To:	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Cc:	Celejar <celejar@...il.com>,
	Randy Dunlap <randy.dunlap@...cle.com>, 541835@...s.debian.org,
	lkml <linux-kernel@...r.kernel.org>,
	linux-crypto@...r.kernel.org, control@...s.debian.org
Subject: Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration /
 dependencies broken

reopen 541835
thanks

hey,

On 31/08/2009 Sebastian Andrzej Siewior wrote:
> * Jonas Meurer | 2009-08-31 17:52:00 [+0200]:
> 
> >> Could someone please look at initramfs to figure out why those three
> >> modules are not copied in this reduced setup?
> >
> >the reason is simply that no other crypto modules define depends on the
> >listed ones:
> Well yes, but aes cbc is placed in the new initrd. I took a look, read
> below.

as you already discovered, that's because the initramfs hook script for
cryptroot adds some crypto modules manually in debian. currently these
are dm-mod, dm-crypt, cbc, aes, sha256 and all the modules they depend
on.

> >so the following depends should be added/changed:
> >
> >- chainiv should depend o 'krng' instead of 'rng' at least
>    rng is a subsubsystem within crypto. krng is one implementation which
>    provides random numbers. So does ansi_cprng. Another implementation
>    may come.
>
> >- maybe cipher modules like aes,serpent,... should depend on 'cryptomgr'
> >  instead of 'crypto_algapi'
>    This isn't possible without dummy variables because they don't need
>    each other in first place. We could move code but crypto_algapi can
>    live without cryptomgr. However cryptomgr doesn't make sense without
>    crypto_algapi.
>    Lets say you have a VIA CPU which provides cbc(aes) in HW. So you
>    don't need cryptomgr because cbc(aes) is allready available. You need
>    aes_generic but that's another story :)
> 
> >- crypto_algapi should depend on chainiv
>    chainiv is one possible implementation eseqiv is another one. The
>    later is used on async-hw and in 2.6.32+ on SMP afaik.
>    
> >these changes are pure guesses, i don't know the details. but at least
> >additional depends need to be defined for crypto modules, don't you
> >think so?
>
> We have them in Kconfig. All required modules are built and are
> available. However the things aren't that easy. The crypto subsystem is
> very flexible and undocumented and this is the problem here I think.

ok, i see the point that it's not enough to simply add some additional
dependencies in order to fix the problem. seems like an easy solution
doesn't exist.

> So this brings me to the following question: Why are you so picky and you
> don't take all of the modules? sh 2.6.30-1 on various debian archs:
> du -sh              x86_64  i386  powerpc  s390x   mips(r5k-ip32)
> crypto              720K    636K  1.1M     804K    968K
> arch/<arch>/crypto  72K     36K   0        92K     0
> driver/crypto       32K     60K   60K      0       52K
> Total               824K    732K  1.2M     896K    1020
> 
> So all modules together have an average footprint of 941.0K. This isn't
> that much. There is no size limit on initrd unless you are on a system
> with has 32MiB or something like that :)
> With *all* those crypto modules which are selected and built you are
> able to cover all corner cases.
> I took a look at hooks/cryptroot and really and only a few modules are
> included. Right now you don't include HW cipher e.g. VIA's padlock or
> AMD's geode. If you don't load those module while openning the root
> partition (the first request), then the module is never loaded / used.
> The other unhandled case are non default ciphers like xts(aes) which one
> might use. The brand new aes implementation aesni-intel is also not be
> considered. Most modules have _generic in their name if there is
> another implementation available and <name>-arch if there is an assembly
> variant but I would prefer that this does not become part of an ABI
> where one can rely on.
> 
> Would it be okay for you to change the way the crypto modules are picked
> and include the full set?

i don't like the idea to add _all_ crypto modules into the initramfs per
default. the size of crypto and arch/<arch>/crypto will keep on growing
for kernels which do have ship all available modules for ciphers and
implementations. i think that the initramfs should be a _minimal_
system, and detecting the required crypto modules should be possible.

alternative crypto cipher and blockcipher modules are already detected
if required, as information about these are available from the cryptroot
configuration (either luks header or cmdline options given to cryptsetup).

i added cryptomgr, chainiv and krng to the list of required modules in
/usr/share/initramfs-tools/hooks/cryptroot for now.

still i see the point that this solution has it's drawbacks. modules for
crypto hardware and cipher implementations not following the convention to
call modules <cipher>_generic and <cipher>-alias aren't detected by the
current system.

i guess the best solution would be to improve the module dependency
system. cipher meta-modules like 'aes' should depend on all available
implementations. same for ivciphers, hashs, rng implementations etc.

what do you think about it?

greetings,
 jonas

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists