Re: [PATCH] 90crypt: keys on external devices support

[Mr Dash Four <mr.dash.four-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]

> Next thing is give possibility to put keys inside initramfs.
>   
I don't think this is such a good idea as having the crypto keys reside 
in the same place as the kernel would completely defeats the purpose of 
using crypto devices.


> If you'd like to write support for smartcard, I'd be glad to see it as
> a separate module.  Don't hesitate to post your progress on ml for our
> review.
>   
I am not sure it would be as a separate module though (may be, at a 
later stage) - for now I'll try to use the existing module/framework in 
place and extend its functionality, hence why I posted some of my ideas 
late last night to canvass an opinion - from what I can gather, as you 
and Harald are the two main contributors to the crypto side of dracut it 
is good to know what you think?

The way I see it simplifying the various kernel parameters (particularly 
those designed to deal with luks-related partitions) is the way forward.

The one issue I am facing right now before I can even begin coding 
smartcard support in dracut is that I am not at all clear how it deals 
with the various dependencies when I ask a program to be installed 
(using the '-I' option) as 'pkcs11-tool' for example, would need at 
least 2 more executables available (with half-a-dozen other .ko library 
files) and at least two configuration files present and available at the 
time of execution.

The configuration files present another challenge in itself - most 
(default) settings work in about 90% of all cases, but for the rest 
these settings have to be changed (card reader types, various attributes 
set etc) and for that there are two options: either 1) create initrd 
image which is tailored to a specific configuration (and therefore these 
configuration files are embedded, so to speak, into the initrd image 
itself); or 2) take these configuration files out of the initrd 
altogether and make them available in the /boot directory/partition (in 
/boot/dracut for example!) when dracut is instantiated (hence why I 
asked in my previous post does dracut have at least 'read' access to 
that directory/partition)?

One other thing I forgot to mention in my last post that with the 
proposed parameter changes there is a third possible scenario with the 
password authentication, in which case, the format of the parameter in 
the kernel would simply be:

c) rd.luks.<luks_uuid>[=]

The equal sign (=) would not be mandatory and may not be specified. For 
example 'rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c' will opens LUKS 
drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c after asking for a 
password at the console (as is the case now).