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

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

[Mr Dash Four]

I am currently trying to modify dracut (I am on up-to-date FC13 x86_64) 
so that it enables me to use my smartcard token to unlock (and use) a 
boot partition. As a secondary task I would then try and automate a 
similar process (through the smartcard event manager - pkcs11_eventmgr) 
when the card is inserted to automatically ask for pin and unlock LUKS 
partitions.

That was the reason I have stumbled across this patch - 
http://www.spinics.net/lists/linux-initramfs/msg01402.html and the 
subsequent response that it has been included in the repository for 
dracut. That was a couple of months ago.

Could you tell me whether this feature is already implemented in 
FC13/FC14 repositories and if not what are the plans? I am also 
interested to see whether there are plans (or, indeed attempted 
implementations) to introduce smartcard support to LUKS partitions (boot 
or not)? Many thanks

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

Excerpts from Mr Dash Four's message of Tue Oct 19 15:54:48 +0200 2010:
> I am currently trying to modify dracut (I am on up-to-date FC13
> x86_64) so that it enables me to use my smartcard token to unlock (and
> use) a boot partition. As a secondary task I would then try and
> automate a similar process (through the smartcard event manager -
> pkcs11_eventmgr) when the card is inserted to automatically ask for
> pin and unlock LUKS partitions.
> 
> That was the reason I have stumbled across this patch -
> http://www.spinics.net/lists/linux-initramfs/msg01402.html and the
> subsequent response that it has been included in the repository for
> dracut. That was a couple of months ago.
>
> Could you tell me whether this feature is already implemented in
> FC13/FC14 repositories and if not what are the plans?

Experimental support is in Dracut 007.  In future 008 it will be even
better (see my latest patches).  There are some improvements I'm working
on.  Although I'm not sure which version Fedora supports, will support
and when.


> I am also interested to see whether there are plans (or, indeed
> attempted implementations) to introduce smartcard support to LUKS
> partitions (boot or not)? Many thanks

I haven't planned that and haven't heard of anybody planning that, but
if I would have such a gadget I'd probably be happy to implement support
for it soon or later.
-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Mr Dash Four]

> Experimental support is in Dracut 007.  In future 008 it will be even
> better (see my latest patches).
Where are they? FC Rawhide or somewhere else?

>   There are some improvements I'm working
> on.  Although I'm not sure which version Fedora supports, will support
> and when.
>   
Glad to see there is progress made. What are the plans? As I pointed out 
I am currently interested in making dracut work with external key files 
and tokens (the latter is a much-pressing need on my as I am going to 
rely on it heavily!).

>> I am also interested to see whether there are plans (or, indeed
>> attempted implementations) to introduce smartcard support to LUKS
>> partitions (boot or not)? Many thanks
>>     
>
> I haven't planned that and haven't heard of anybody planning that, but
> if I would have such a gadget I'd probably be happy to implement support
> for it soon or later.
>   
I am still in a learning curve as far as dracut is concerned - hence why 
I was glad when I found your patch as I intend to use it as a template 
to implement token support.

It won't be easy as there are dependencies on (at least) 3 packages, but 
if I finally manage to overcome these the 'login' is very similar to the 
'password' authentication currently present - once the password (PIN 
token in this case) is captured then there is a program (pkcs11-tool 
and/or pkcs15-tool) which reads the relevant key data and which then 
could present it to luksOpen (as a pipe, i.e. 'cat keydata | cryptsetup 
luksOpen --key-file=-') without further need for input from the user.

I have 'manually' done this (via command line shell script) and it works 
without a problem, so once I get to grips with dracut and find out how 
to install dependancies/packages in the initramfs image then it won't be 
difficult.

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

[Mr Dash Four]

OK, I've had a bit of time to look through the available dracut docs and 
have a couple of queries and a few ideas (below):

1. 'dracut -I' option 'installs' the files specified, but does it 
install all dependencies? For e.g. if I want to install 
'/usr/bin/pkcs11-tool' does it install all other libraries/files on 
which this program depends (i do not mean just .ko files!)?

2. Currently the proposed rd_LUKS_KEYPATH and rd_LUKS_KEYDEV_UUID allow 
me to specify key path and device to look for the key with which to open 
the LUKS-encrypted drive/partition. If I want to open another LUKS disk 
with a different key located in a different path/file how is this 
handled? By specifying another pair of rd_LUKS_KEYDEV_UUID and 
rd_LUKS_KEYPATH?

3. Following from 2 above: if smartcard module/enhancements are going to 
be implemented then there is a possibility that there may be a conflict 
(for example if I want to open drive A with keypath/file and drive B 
with a token - how does dracut know which is which?).

So, I have an idea: instead of using rd_LUKS_UUID, rd_LUKS_KEYDEV_UUID & 
rd_LUKS_KEYPATH (and possibly also rd_LUKS_TOKEN for reading keys from 
tokens) why can't we have one unified and much simpler format:

  a) for LUKS-encrypted drives (file/path keys): 
rd.luks.<luks_uuid>=<keypath_uuid>:<fs>:<path>

For example 
rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=3de247f3-5de4-4a44-afc5-1fe179750cf7:ext3:/crypto/key_file 
opens LUKS drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, using 
key drive UUID 3de247f3-5de4-4a44-afc5-1fe179750cf7, mounting ext3 file 
system and looking for file /crypto/key_file.

  b) for LUKS-encrypted drives (using token keys): 
rd.luks.<luks_uuid>=<reader_id>:<slot_id>:<token_id>:<token_status>

For example rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=0:0:12:private 
opens LUKS drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, reading 
key token using reader=0, slot=0 and looking for token data stored with 
application_id=12, where:
     - reader_id: reader ID to use (not mandatory - if omitted the 
'default' reader is used);
     - slot_id: slot ID to look for when reading the token (it could 
also be omitted in which case the first available slot will be used);
     - token_id: the (application) ID of the token as stored in the 
smartcard;
     - token_status: 'public' if the token is stored in the smartcard as 
'public' (i.e. no PIN login required - similar to the key path scenario 
above); or 'private' if the key token is stored as a private token and 
smartcard PIN is required to read the token data;

What do you think?

My main concern is handling of all dependencies when installing the core 
programs, which are going to do the 'dirty work': pkcs15-tool and 
pkcs11-tool (possibly pkcs15-init also, though this program may have to 
be used in extremely rare circumstances, if at all).

I've looked through the dependencies and the package scripts though 
there are, among other things, udev rules and config files, which could 
complicate matters. Following this I have another query: Does dracut 
have (at least read) access to the /boot partition where the initramfs 
image is?

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 4979 bytes --]

Excerpts from Mr Dash Four's message of Wed Oct 20 03:24:35 +0200 2010:
> 1. 'dracut -I' option 'installs' the files specified, but does it
> install all dependencies? For e.g. if I want to install
> '/usr/bin/pkcs11-tool' does it install all other libraries/files on
> which this program depends (i do not mean just .ko files!)?

'-I' option are for user to include single files.  If you'd like to
merge files into initramfs with its dependencies, you use '*inst*'
family functions.  See 'dracut-functions' file.


> 2. Currently the proposed rd_LUKS_KEYPATH and rd_LUKS_KEYDEV_UUID
> allow me to specify key path and device to look for the key with which
> to open the LUKS-encrypted drive/partition. If I want to open another
> LUKS disk with a different key located in a different path/file how is
> this handled? By specifying another pair of rd_LUKS_KEYDEV_UUID and
> rd_LUKS_KEYPATH?

First of all rd_LUKS_KEYDEV_UUID will be changed to 'rd.luks.keydev' and
allow to specify devices by filename in /dev, LABEL or UUID.

It's done a bit more flexible.  You can specify 'rd_LUKS_KEYDEV_UUID'
(later 'rd.luks.keydev') and 'rd_LUKS_KEYPATH' (later 'rd.luks.keypath')
several times.  For every 'rd.luks.keydev' ALL 'rd.luks'keypaths' are
checked.  I know that such approach have some flaws.  I'll consider your
proposition (quoted below) for specifying that.


> 3. Following from 2 above: if smartcard module/enhancements are going
> to be implemented then there is a possibility that there may be a
> conflict (for example if I want to open drive A with keypath/file and
> drive B with a token - how does dracut know which is which?).
>
> So, I have an idea: instead of using rd_LUKS_UUID, rd_LUKS_KEYDEV_UUID
> & rd_LUKS_KEYPATH (and possibly also rd_LUKS_TOKEN for reading keys
> from tokens) why can't we have one unified and much simpler format:
>
>   a) for LUKS-encrypted drives (file/path keys):
>   rd.luks.<luks_uuid>=<keypath_uuid>:<fs>:<path>
>
> For example
> rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=3de247f3-5de4-4a44-afc5-1fe179750cf7:ext3:/crypto/key_file
> opens LUKS drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, using
> key drive UUID 3de247f3-5de4-4a44-afc5-1fe179750cf7, mounting ext3
> file system and looking for file /crypto/key_file.
>
>   b) for LUKS-encrypted drives (using token keys):
>   rd.luks.<luks_uuid>=<reader_id>:<slot_id>:<token_id>:<token_status>
>
> For example
> rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=0:0:12:private opens LUKS
> drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, reading key
> token using reader=0, slot=0 and looking for token data stored with
> application_id=12, where: - reader_id: reader ID to use (not mandatory
> - if omitted the 'default' reader is used); - slot_id: slot ID to look
> for when reading the token (it could also be omitted in which case the
> first available slot will be used); - token_id: the (application) ID
> of the token as stored in the smartcard; - token_status: 'public' if
> the token is stored in the smartcard as 'public' (i.e. no PIN login
> required - similar to the key path scenario above); or 'private' if
> the key token is stored as a private token and smartcard PIN is
> required to read the token data;
>
> What do you think?

  rd.luks.key=<key_path>:<key_dev>:<luks_dev>

Why this order?  <key_path> is always required (obvious).  <key_dev>
doesn't have to be required, because it's easy to perform search for
device (and it's done know, it works pretty well, at least with my
latest not yet accepted patch which needs more improvement :-)).  The
last is optional too.  Forcing user to write down all UUID-s is not
ethical. ;-)  It should be automated as far as it makes sense.

Examples:
  rd.luks.key=/some/file.key:LABEL=cool_keys:UUID=00aabc
  rd.luks.key=/some/file.key::UUID=00aabc
  rd.luks.key=/some/file.key:LABEL=cool_keys
  rd.luks.key=/some/file.key

And probably I'll introduce this scheme in patches I'm improving
recently.  Does it satisfy you? :-)  And for token it would be:

  rd.luks.token=…

Might be?


> My main concern is handling of all dependencies when installing the
> core programs, which are going to do the 'dirty work': pkcs15-tool and
> pkcs11-tool (possibly pkcs15-init also, though this program may have
> to be used in extremely rare circumstances, if at all).

'inst*' functions family as I mentioned in previous e-mail.


> I've looked through the dependencies and the package scripts though
> there are, among other things, udev rules and config files, which
> could complicate matters. Following this I have another query: Does
> dracut have (at least read) access to the /boot partition where the
> initramfs image is?

No, no.  You don't need access to /boot.  You put everything in
initramfs using installation functions provided by 'dracut-functions'.
See 'install' and 'check' scripts in some module's directory.
-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Mr Dash Four]

> '-I' option are for user to include single files.  If you'd like to
> merge files into initramfs with its dependencies, you use '*inst*'
> family functions.  See 'dracut-functions' file.
>   
Thanks, I'll have a good look.


> First of all rd_LUKS_KEYDEV_UUID will be changed to 'rd.luks.keydev' and
> allow to specify devices by filename in /dev, LABEL or UUID.
>
> It's done a bit more flexible.  You can specify 'rd_LUKS_KEYDEV_UUID'
> (later 'rd.luks.keydev') and 'rd_LUKS_KEYPATH' (later 'rd.luks.keypath')
> several times.  For every 'rd.luks.keydev' ALL 'rd.luks'keypaths' are
> checked.  I know that such approach have some flaws.  I'll consider your
> proposition (quoted below) for specifying that.
>
> [...]
>   rd.luks.key=<key_path>:<key_dev>:<luks_dev>
>
> Why this order?  <key_path> is always required (obvious).  <key_dev>
> doesn't have to be required, because it's easy to perform search for
> device (and it's done know, it works pretty well, at least with my
> latest not yet accepted patch which needs more improvement :-)).  The
> last is optional too.  Forcing user to write down all UUID-s is not
> ethical. ;-)  It should be automated as far as it makes sense.
>   
Bugger, I forgot about drive labels :-\

In which case using separate rd.luks=<luks_dev> (for password 
identification), rd.luks.key for external dev/key authentication and 
rd.luks.token for token authentication makes sense. I would reverse the 
order though.

The way I see it if you reverse the order to be 
<luks_dev>:<key_dev>:<fs>:<key_path> (don't forget the file system, 
otherwise how would you know how to mount it to read the key - you may 
'assume' that it is either ext2/3, but it might be something else - HFS, 
ReifeiserFS etc.) it makes it more consistent with the Fedora's own 
Kickstart options (see http://fedoraproject.org/wiki/Anaconda/Kickstart 
- scroll further until you find 'ks=').


> Examples:
>   rd.luks.key=/some/file.key:LABEL=cool_keys:UUID=00aabc
>   rd.luks.key=/some/file.key::UUID=00aabc
>   rd.luks.key=/some/file.key:LABEL=cool_keys
>   rd.luks.key=/some/file.key
>
> And probably I'll introduce this scheme in patches I'm improving
> recently.  Does it satisfy you? :-)  And for token it would be:
>
>   rd.luks.token=…
>
> Might be?
>   
I'll be happy if you reverse the order and add a file system type as 
well - it makes it more consistent with the Fedora Kickstart format, 
otherwise is a bit confusing.



>> I've looked through the dependencies and the package scripts though
>> there are, among other things, udev rules and config files, which
>> could complicate matters. Following this I have another query: Does
>> dracut have (at least read) access to the /boot partition where the
>> initramfs image is?
>>     
>
> No, no.  You don't need access to /boot.  You put everything in
> initramfs using installation functions provided by 'dracut-functions'.
> See 'install' and 'check' scripts in some module's directory.
>   

That could spell trouble as for just running pkcs11-tool that requires 2 
configuration files which reflect the specific token type and various 
parameters. Although 90% of all cases fall into the 'default' mode 
scenario there are the rest 10% which do not and have to be properly 
catered for.

The parameters and attributes in these files are complex and cannot be 
specified in the kernel command line in grub.conf. If these 2 
configuration files are embedded into initrd they cannot be changed, 
which means that initrd has to be custom-built for each client 
configuration which makes this whole exercise largely impractical.

The other possible scenario, as I already mentioned, is to use 
configuration files which are outside initrd (separate device or located 
in /boot are two possible alternatives)

One other query related to this: if I want to use crypttab for my root 
(/) partition how is that handled by dracut?

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 3241 bytes --]

Excerpts from Mr Dash Four's message of Wed Oct 20 16:44:31 +0200 2010:
> > Examples:
> >   rd.luks.key=/some/file.key:LABEL=cool_keys:UUID=00aabc
> >   rd.luks.key=/some/file.key::UUID=00aabc
> >   rd.luks.key=/some/file.key:LABEL=cool_keys
> >   rd.luks.key=/some/file.key
> >
> > And probably I'll introduce this scheme in patches I'm improving
> > recently.  Does it satisfy you? :-)  And for token it would be:
> >
> >   rd.luks.token=…
> >
> > Might be?
> >   
> I'll be happy if you reverse the order and add a file system type as
> well - it makes it more consistent with the Fedora Kickstart format,
> otherwise is a bit confusing.

"rd.luks.key=::/some/file.key" is much more confusing.  I bet that some
user will curse us when he forget about double colon.  I think that
required parameters should be first and less useful last.  It's all
Dracut wonder that it doesn't require many parameters.

When you're mounting device are you always specifying "-t fs_type"? :-)
Disk is mounted readonly, so even if mount performs wrong guess, nothing
bad happens.  This is rare case.  Although maybe we can add it… :-) Then
it would be:

  rd.luks.key=<key_path>:<key_dev>:<key_dev_fs>:<luks_dev>


> >> I've looked through the dependencies and the package scripts though
> >> there are, among other things, udev rules and config files, which
> >> could complicate matters. Following this I have another query: Does
> >> dracut have (at least read) access to the /boot partition where the
> >> initramfs image is?
> >>     
> >
> > No, no.  You don't need access to /boot.  You put everything in
> > initramfs using installation functions provided by
> > 'dracut-functions'.  See 'install' and 'check' scripts in some
> > module's directory.
> >   
> 
> That could spell trouble as for just running pkcs11-tool that requires
> 2 configuration files which reflect the specific token type and
> various parameters. Although 90% of all cases fall into the 'default'
> mode scenario there are the rest 10% which do not and have to be
> properly catered for.
> 
> The parameters and attributes in these files are complex and cannot be
> specified in the kernel command line in grub.conf. If these 2
> configuration files are embedded into initrd they cannot be changed,
> which means that initrd has to be custom-built for each client
> configuration which makes this whole exercise largely impractical.
> 
> The other possible scenario, as I already mentioned, is to use
> configuration files which are outside initrd (separate device or
> located in /boot are two possible alternatives)

Maybe 10% can embed the file? :-)  Well you maybe can specify additional
config same way as key for luks is specified.  Maybe it would make sense
to have such a general feature to grab files during runtime from
removable devices?

But would be cool if you get idea how to do it without extra configs
from outside.  Maybe it's possible to perform some settings guesses on
run-time?


> One other query related to this: if I want to use crypttab for my root
> (/) partition how is that handled by dracut?

Password support only for now, but I'm gonna extended it.
-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Mr Dash Four]

>   rd.luks.key=<key_path>:<key_dev>:<key_dev_fs>:<luks_dev>
>   
I still think the reversed form makes it better (when you look for a 
file you first look for a device, then a directory and then the file 
itself, not the other way around), but you are the rd.luks.key expert so 
it is up to you really how you are going to organise it. :-)

That's my two pence worth.


> But would be cool if you get idea how to do it without extra configs
> from outside.  Maybe it's possible to perform some settings guesses on
> run-time?
>   
I'll see what I can do - there are (at least) two additional processes 
which need to be running (that is it in addition to 
pkcs11-tool/pkcs15-tool which is responsible for fetching the key data 
from the token itself) and they are all dependant on what is in those 
two config files as that would require different modules (.ko files) to 
be loaded in order for this operation to succeed.

I have to spend some time and determine what I can leave out (i.e. run a 
bare-bones system configuration and start from there). As of right now, 
my hunch is that it *may* be possible to specify some core parameters to 
be included as part of the rd.luks.token syntax, but I am not at all 
sure if that is going to be enough - further analysis is needed, which I 
would probably do over the weekend when I have more time (I am not a 
student as you, unfortunately ;-) ) ...


>> One other query related to this: if I want to use crypttab for my root
>> (/) partition how is that handled by dracut?
>>     
>
> Password support only for now, but I'm gonna extended it.
>   
That is the problem though - there is no way you can have crypttab for 
root as there is nowhere to put it in, other than outside initrd or 
hard-code it in initrd in which case once there it cannot be changed. 
For all other partitions the solution is simple - use root, but for 
(encrypted) root itself the options are rather limited.

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

Excerpts from Mr Dash Four's message of Wed Oct 20 17:37:07 +0200 2010:
> That is the problem though - there is no way you can have crypttab for 
> root as there is nowhere to put it in, other than outside initrd or 
> hard-code it in initrd in which case once there it cannot be changed. 
> For all other partitions the solution is simple - use root, but for 
> (encrypted) root itself the options are rather limited.

It's not hard-coding.  Please look at "--hostonly" option and see its
consequences. I've explained it a bit by the way in

  dracut/modules.d/10i18n/README

Reading this file might give you some light on how we deal with
configuration files and so.  Please also switch to 007 version or better
- git, because you sometimes mention things already solved there.
--
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Karel Zak]

On Wed, Oct 20, 2010 at 05:17:22PM +0200, Amadeusz Żołnowski wrote:
> When you're mounting device are you always specifying "-t fs_type"? :-)
> Disk is mounted readonly, so even if mount performs wrong guess, nothing
> bad happens.  This is rare case.  Although maybe we can add it… :-) Then
> it would be:
> 
>   rd.luks.key=<key_path>:<key_dev>:<key_dev_fs>:<luks_dev>

 The LABEL and UUID are always stored in filesystem specific
 superblock (or root directory) on the device. It means that your
 system has to be able to detect FS type before it's able to read
 LABEL/UUID from the device.  The <key_dev_fs> is unnecessary.

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 http://karelzak.blogspot.com

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

[Mr Dash Four]

>>   rd.luks.key=<key_path>:<key_dev>:<key_dev_fs>:<luks_dev>
>>     
>
>  The LABEL and UUID are always stored in filesystem specific
>  superblock (or root directory) on the device. It means that your
>  system has to be able to detect FS type before it's able to read
>  LABEL/UUID from the device.  The <key_dev_fs> is unnecessary.
>   
If I have HFS drive (Mac) or even HPFS (OS/2) and have the keys there 
how would I be able to retrieve them then if I do not use labels/UUID - 
by using /dev/sdXX?

I think specifying the target file system is important because by just 
executing 'mount' without indicating the target file system when I have, 
for example, HFS or HPFS mount just won't happen. I am also not certain 
that by just executing 'mount' it would automatically map NTFS either, 
without specifying that the target system is NTFS (the command in 
question for mounting NTFS partitions is ntfs-3g isn't it?). Same goes 
for ReiserFS (I think) as well as cidr/smb partitions/drives (although I 
admit the latter case is a bit special as it needs network access and a 
bit more options to be configured in order to make it work).

The 'guessing' of the file systems by mount also comes with a health 
warning, which has to be respected: "Warning: the probing uses a 
heuristic (the presence of appropriate 'magic'), and could recognize the 
wrong filesystem type, possibly with catastrophic consequences. If your 
data is valuable, don't ask mount to guess."

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

[Karel Zak]

On Thu, Oct 21, 2010 at 02:54:54PM +0100, Mr Dash Four wrote:
>
>>>   rd.luks.key=<key_path>:<key_dev>:<key_dev_fs>:<luks_dev>
>>>     
>>
>>  The LABEL and UUID are always stored in filesystem specific
>>  superblock (or root directory) on the device. It means that your
>>  system has to be able to detect FS type before it's able to read
>>  LABEL/UUID from the device.  The <key_dev_fs> is unnecessary.

Well, rephrasing: The <key_dev_fs> is unnecessary if you want to use
UUID or LABEL.

> If I have HFS drive (Mac) or even HPFS (OS/2) and have the keys there  
> how would I be able to retrieve them then if I do not use labels/UUID -  
> by using /dev/sdXX?

HFS, HPFS and NTFS support labels and uuids

> I think specifying the target file system is important because by just  
> executing 'mount' without indicating the target file system when I have,  
> for example, HFS or HPFS mount just won't happen.

Why? My mount(8) is able to detect HFS or HPFS.

# losetup --show -f /home/images/filesystems/hfs.img
/dev/loop0

# mount /dev/loop0 /mnt/test

# grep loop0 /proc/mounts 
/dev/loop0 /mnt/test hfs rw,relatime,uid=0,gid=0 0 0


> I am also not certain  
> that by just executing 'mount' it would automatically map NTFS either,  
> without specifying that the target system is NTFS (the command in  
> question for mounting NTFS partitions is ntfs-3g isn't it?).

 $ ll /sbin/mount.ntfs
 lrwxrwxrwx 1 root root 13 Oct  8 10:32 /sbin/mount.ntfs -> mount.ntfs-3g

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 http://karelzak.blogspot.com

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

[Mr Dash Four]

> Well, rephrasing: The <key_dev_fs> is unnecessary if you want to use
> UUID or LABEL.
>   
I see.


>> I think specifying the target file system is important because by just  
>> executing 'mount' without indicating the target file system when I have,  
>> for example, HFS or HPFS mount just won't happen.
>>     
>
> Why? My mount(8) is able to detect HFS or HPFS.
>   
I have no such luck when trying to mount my (Macbook Pro) laptop 
partition, nor when I try to mount my OS/2 Warp (v3.01) server disk 
drive, hence why I always specify the target file system - then it works 
every time.

My point still stands though - leaving the 'guessing' of the target file 
system to mount is not a good idea and <key_dev_fs> should not be 
removed as a parameter (it may not be mandatory, but should always be 
catered for). I would also add that both <key_dev> and <luks_dev> should 
be able to support the Linux drive notation (sdXX, hdXX etc) in addition 
to label and uuid.

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

This thread is becoming huuuge. :-)


Excerpts from Mr Dash Four's message of Thu Oct 21 17:48:03 +0200 2010:
> My point still stands though - leaving the 'guessing' of the target file 
> system to mount is not a good idea and <key_dev_fs> should not be 
> removed as a parameter (it may not be mandatory, but should always be 
> catered for).

File system is mounted read-only, so even on wrong guess nothing bad may
happen.  I think Karel has made good point about <key_dev_fs> parameter.

But if you need to insist on having it, we might introduce following
syntax:

  rd.luks.key=<key_path>[:<key_dev>[:<luks_dev>]]

Unfolding <key_dev> in BNF:

  <key_dev> ::= "UUID=" <uuid> | "LABEL=" <label> | <path_part>
  <path_part> ::= "FS=" <fs> "=" <path> | <path>

Where <path> matches following regular expression:

  ^/dev/.*

Hope everything's clear and that will satisfy you. :-)

Karel, what do you think about it?


> I would also add that both <key_dev> and <luks_dev> should be able to
> support the Linux drive notation (sdXX, hdXX etc) in addition to label
> and uuid.

It does already with my latest not yet merged patch.  Hope to work on it
this weekend to be merged on Monday.
--
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Karel Zak]

On Thu, Oct 21, 2010 at 04:48:03PM +0100, Mr Dash Four wrote:
>>> I think specifying the target file system is important because by 
>>> just  executing 'mount' without indicating the target file system 
>>> when I have,  for example, HFS or HPFS mount just won't happen.
>>>     
>>
>> Why? My mount(8) is able to detect HFS or HPFS.
>>   
> I have no such luck when trying to mount my (Macbook Pro) laptop  
> partition, nor when I try to mount my OS/2 Warp (v3.01) server disk  
> drive, hence why I always specify the target file system - then it works  
> every time.

 Hmm.. I'd like to fix this problem. Please, send me 1MiB from the beginning
 of the device(s).

    # dd if=<dev> of=file.img bs=1MiB count=1

 Thanks.

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 http://karelzak.blogspot.com

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

Excerpts from Mr Dash Four's message of Tue Oct 19 16:33:33 +0200 2010:
> Glad to see there is progress made. What are the plans? As I pointed
> out I am currently interested in making dracut work with external key
> files and tokens (the latter is a much-pressing need on my as I am
> going to rely on it heavily!).

Improve part responsible for getting keys from removable media.  Now
it's done synchronously and it implies some issues.  I'm gonna correct
it to use udev soon.

Next thing is give possibility to put keys inside initramfs.

Later future is support for crypto related things which will get into my
hands, since I'm just a student right now. :-)


> >> I am also interested to see whether there are plans (or, indeed
> >> attempted implementations) to introduce smartcard support to LUKS
> >> partitions (boot or not)? Many thanks
> >>
> >
> > I haven't planned that and haven't heard of anybody planning that,
> > but if I would have such a gadget I'd probably be happy to implement
> > support for it soon or later.
> >
> I am still in a learning curve as far as dracut is concerned - hence
> why I was glad when I found your patch as I intend to use it as a
> template to implement token support.
>
> It won't be easy as there are dependencies on (at least) 3 packages,
> but if I finally manage to overcome these the 'login' is very similar
> to the 'password' authentication currently present - once the password
> (PIN token in this case) is captured then there is a program
> (pkcs11-tool and/or pkcs15-tool) which reads the relevant key data and
> which then could present it to luksOpen (as a pipe, i.e. 'cat keydata
> | cryptsetup luksOpen --key-file=-') without further need for input
> from the user.
>
> I have 'manually' done this (via command line shell script) and it
> works without a problem, so once I get to grips with dracut and find
> out how to install dependancies/packages in the initramfs image then
> it won't be difficult.

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.
-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Mr Dash Four]

> 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).

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

You're fast! :-)


Excerpts from Mr Dash Four's message of Wed Oct 20 16:06:32 +0200 2010:
> > 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.

It does not.  You can have kernel and initramfs on removable media.  You
have this media secure and don't need separate media for keys.  It's
even more secure than having kernel and initramfs on harddrive because
it protects you from case when someone replaces your initramfs to stole
the key (e.g. sends to some remote machine).

And of course keys inside initramfs will be optional extra solution.


> > 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)?

I hope I've answered to your concerns above in previous e-mail.


> 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>[=]

You don't have to specify anything for password scenario. root=<dev> is
just enough.  Have you tried using crypt module?
-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Mr Dash Four]

>> 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.
>>     
>
> It does not.  You can have kernel and initramfs on removable media.  You
> have this media secure and don't need separate media for keys.  It's
> even more secure than having kernel and initramfs on harddrive because
> it protects you from case when someone replaces your initramfs to stole
> the key (e.g. sends to some remote machine).
>
> And of course keys inside initramfs will be optional extra solution.
>   
Good point - I haven't thought of that, it makes sense then.


> I hope I've answered to your concerns above in previous e-mail.
>   
I did a reply - there are 2 configuration files in order to run/read 
tokens and these configuration files should be easily tailored to each 
user's settings without the need to rebuilt initrd.



>> 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>[=]
>>     
>
> You don't have to specify anything for password scenario. root=<dev> is
> just enough.  Have you tried using crypt module?
>   
I am using dracut-006 (I think - the last which comes out of FC13 
repository) and currently I have to specify rd_LUKS_UUID=luks-<UUID> in 
order to make it work, which is not very convenient.

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

You're like a machine. ;-)


Excerpts from Mr Dash Four's message of Wed Oct 20 16:48:19 +0200 2010:
> I am using dracut-006 (I think - the last which comes out of FC13 
> repository) and currently I have to specify rd_LUKS_UUID=luks-<UUID> in 
> order to make it work, which is not very convenient.

Much have changed in dracut-007, a bit changed in git repo, and more
will change soon, so track and use git/repo. :-)  You might be
interested in my current work <http://github.com/aidecoe/dracut> where
things go first before reaching Harald's official Dracut repo:

  git://dracut.git.sourceforge.net/gitroot/dracut/dracut
-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Mr Dash Four]

> You're like a machine. ;-)
>   
My friends call me T1000 8-)


> Much have changed in dracut-007, a bit changed in git repo, and more
> will change soon, so track and use git/repo. :-)  You might be
> interested in my current work <http://github.com/aidecoe/dracut> where
> things go first before reaching Harald's official Dracut repo:
>
>   git://dracut.git.sourceforge.net/gitroot/dracut/dracut
>   
Thanks for the links - I'll have a good look when I get home tonight.

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

[Mr Dash Four]

>> I am using dracut-006 (I think - the last which comes out of FC13 
>> repository) and currently I have to specify rd_LUKS_UUID=luks-<UUID> in 
>> order to make it work, which is not very convenient.
>>     
>
> Much have changed in dracut-007, a bit changed in git repo, and more
> will change soon, so track and use git/repo. :-)  You might be
> interested in my current work <http://github.com/aidecoe/dracut> where
> things go first before reaching Harald's official Dracut repo:
>
>   git://dracut.git.sourceforge.net/gitroot/dracut/dracut
>   
It turns out that I am actually on dracut-005-3.fc13.noarch 
(dracut-tools-005-3.fc13.noarch), which is even worse - that is the 
'latest' version which comes out of FC13 repositories.

I've spend a bit of time looking through the various files dracut 
uses/generates and have a query: there is a group of scripts in the 
50plymouth directory which also deals with encrypted partitions, so 
which one takes precedence (I presume plymouth as it has a lower number, 
is that right?)? If I modify/enhance the scripts in 90crypt would that 
be futile as plymouth will already be done with it?

I am also trying to figure out how to resolve/satisfy all the 
dependencies for the various tools I need to run in order to read a 
smartcard token and, at present, I am a bit stuck as the dependencies go 
very deep - one requirement is to have, among other things, dbus-libs 
(D-Bus) and hal-libs (HAL - that was supposed to be deprecated in favour 
of udev a long time ago!). To be frank, as things stand, I am not sure I 
am going to be able to satisfy all dependencies as the system on which 
initrd runs is very limited.

One other alternative is to build a stripped-down version of the tool I 
need, which implements just a single function: reads a specified token 
from the smartcard (log in, specifying the card PIN, if necessary), 
display it on the console and exit. This way, some/most of the 
dependencies which currently exist may not be needed and installation 
can proceed. I've posted on the dev forum to see if this can be done, so 
fingers crossed!

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

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

Excerpts from Mr Dash Four's message of Fri Oct 22 13:50:32 +0200 2010:
> >> I am using dracut-006 (I think - the last which comes out of FC13 
> >> repository) and currently I have to specify rd_LUKS_UUID=luks-<UUID> in 
> >> order to make it work, which is not very convenient.
> >>     
> >
> > Much have changed in dracut-007, a bit changed in git repo, and more
> > will change soon, so track and use git/repo. :-)  You might be
> > interested in my current work <http://github.com/aidecoe/dracut> where
> > things go first before reaching Harald's official Dracut repo:
> >
> >   git://dracut.git.sourceforge.net/gitroot/dracut/dracut
> >   
> It turns out that I am actually on dracut-005-3.fc13.noarch 
> (dracut-tools-005-3.fc13.noarch), which is even worse - that is the 
> 'latest' version which comes out of FC13 repositories.

Switch to git version.  Don't be afraid.  It's quite stable. :-)


> I've spend a bit of time looking through the various files dracut 
> uses/generates and have a query: there is a group of scripts in the 
> 50plymouth directory which also deals with encrypted partitions, so 
> which one takes precedence (I presume plymouth as it has a lower number, 
> is that right?)? If I modify/enhance the scripts in 90crypt would that 
> be futile as plymouth will already be done with it?

This was a problem.  It was solved by  Matt Smith some time ago, but
after 007 release, so again… see git version. :-)


> One other alternative is to build a stripped-down version of the tool I 
> need, which implements just a single function: reads a specified token 
> from the smartcard (log in, specifying the card PIN, if necessary), 
> display it on the console and exit. This way, some/most of the 
> dependencies which currently exist may not be needed and installation 
> can proceed. I've posted on the dev forum to see if this can be done, so 
> fingers crossed!

Maybe there's already such simplified tool?
--
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Mr Dash Four]

> Switch to git version.  Don't be afraid.  It's quite stable. :-)
>   
I did, thank you. Compiled it as a package and found a bug in the 
dracut.spec file - the following 2 lines should be added, otherwise the 
rpm build fails:

+%{_datadir}/dracut/modules.d/95fstab-sys
+%{_datadir}/dracut/modules.d/96insmodpost

Also, building the --host initrd image was an unmitigated disaster of 
epic proportions!

It does not like hibernation at all - after I used hibernate and then 
switched the PC back on even though the 'restore' worked I've completely 
lost all my usb connections (mouse, keyboard and an extended hard disk) 
and upon reboot the kernel crashed and then as a result of that crash I 
had to repair the root (/) partition and restore a vital lib file, 
which, for some reason, was damaged and Linux won't boot without it (the 
entire system just died!).

Building the 'standard' dracut also has some quirks and also doesn't 
like hibernation, though the system 'only' crashed twice (out of 7 
tests). Upon restart after hibernation, with the standard initrd (from 
fedora, not dracut) I normally get the system restoring itself straight 
away (bypassing grub!), which is the right way to do.

With the dracut-built initramfs that is no longer the case - I am seeing 
the grub menu and I have the usual choice of my bootup options, which is 
a VERY DANGEROUS thing as if I forget that I've hibernated a Linux 
system and boot another (which happens to use the same swap space) when 
I later on attempt to restart the old (previously hibernated) system 
there will be an almighty crash which will most definitely result in a 
corruption of my entire system.


> Maybe there's already such simplified tool?
>   
That is the ONLY alternative, sadly! I tried to see if I could fit in 
the various binaries without installing a large group of dependencies, 
but I was frustrated by failure!

The pcscd daemon (which is essential for reading token data) depends on 
both HAL and D-Bus running (at least that is the case with my FC13 
system). That means I have to install an additional set of about 23 
packages in order to make this work - a futile exercise!

So, in conclusion - until there is either a stripped-down version of 
pkcs11-tool or another similar program which does not require large 
number of dependencies to run and read a token data from a smartcard, 
installing such a module is nigh impossible!

dracut

[Mr Dash Four]

Is it possible to build dracut for system/architecture which is 
different from the host on which dracut is run?

I have been looking through the various functions dracut provides 
(inst_binary in particular) and it seems that dracut picks-up 
dependencies/libraries/kernel modules and files on the host machine when 
building the initrd image, which to me indicates that the resulting 
initrd image is tied to the current kernel/architecture on which the 
host is run and cross-building won't be possible.

Re: dracut

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

Excerpts from Mr Dash Four's message of Fri Oct 22 13:35:47 +0200 2010:
> Is it possible to build dracut for system/architecture which is 
> different from the host on which dracut is run?

Architecture? - No.  Different system configuration? - Yes.  See
"--hostonly" option description in dracut(8) manual.
--
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: dracut

[Harald Hoyer]

On 10/22/2010 01:35 PM, Mr Dash Four wrote:
> Is it possible to build dracut for system/architecture which is different from
> the host on which dracut is run?
>
> I have been looking through the various functions dracut provides (inst_binary
> in particular) and it seems that dracut picks-up dependencies/libraries/kernel
> modules and files on the host machine when building the initrd image, which to
> me indicates that the resulting initrd image is tied to the current
> kernel/architecture on which the host is run and cross-building won't be possible.

kernel/architecture, yes

Cross building for other architectures is difficult, because all the tools like 
"ldd", "modprobe", etc. would have to be cross tools.

Kernel could be solved by specifying the kernel version and having that version 
installed.

Re: dracut

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Excerpts from Harald Hoyer's message of Tue Oct 26 13:09:25 +0200 2010:
> On 10/22/2010 01:35 PM, Mr Dash Four wrote:
> > Is it possible to build dracut for system/architecture which is different from
> > the host on which dracut is run?
> >
> > I have been looking through the various functions dracut provides (inst_binary
> > in particular) and it seems that dracut picks-up dependencies/libraries/kernel
> > modules and files on the host machine when building the initrd image, which to
> > me indicates that the resulting initrd image is tied to the current
> > kernel/architecture on which the host is run and cross-building won't be possible.
> 
> kernel/architecture, yes

But we cannot do this with Dracut itself, if Mr Dash Four was asking
about it.  We need to compile all binaries we're including for specified
architecture.  Similar tool has such a feature - Gentoo's Genkernel.
But it uses sources and compilies them specially for initramfs with
hardcoded instructions.
--
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: dracut

[Mr Dash Four]

> But we cannot do this with Dracut itself, if Mr Dash Four was asking
> about it.  We need to compile all binaries we're including for specified
> architecture.  Similar tool has such a feature - Gentoo's Genkernel.
> But it uses sources and compilies them specially for initramfs with
> hardcoded instructions.
>   
That would be my preference too!

Relying on what is currently installed on client's desktop machines is 
NOT a good idea as I found out to my cost - most of the 'standard' and 
already-compiled smartcard core libraries will NOT work on initramfs at 
all and need to be pre-compiled with certain options in order to strip 
down the dependencies to the bare minimum and allow them to function in 
initramfs environment.

As I already pointed out in my previous post just picking up those 
libraries from the client desktop machines will NOT work. I spent two 
days tearing my hair apart to come to this conclusion, but the good news 
is that I made the smartcard module WORK, so I am currently fine-tuning 
it and stripping the dependencies even further, though this module will 
have to be architecture (and therefore kernel) dependent!

Re: dracut

[Mr Dash Four]

> Cross building for other architectures is difficult, because all the 
> tools like "ldd", "modprobe", etc. would have to be cross tools.
>
> Kernel could be solved by specifying the kernel version and having 
> that version installed.
That isn't the best, though I understand the rationale behind this now.

There was another reason I asked this: the module which I am currently 
developing for login to LUKS with smartcard tokens requires the core 
modules (smartcard udev drivers as well as core executables) to be 
compiled/build with certain options (the standard/desktop-related builds 
will NOT work - i.e. using inst_* from dracut_functions on these on the 
already installed libraries/executables will NOT work), so for this 
module I need to carry quite a few .so and executable files, which will 
be architecture-dependent and have to be compiled in advance.

Re: dracut

[Mr Dash Four]

>
>> Cross building for other architectures is difficult, because all the 
>> tools like "ldd", "modprobe", etc. would have to be cross tools.
>>
>> Kernel could be solved by specifying the kernel version and having 
>> that version installed.
> That isn't the best, though I understand the rationale behind this now.
>
> There was another reason I asked this: the module which I am currently 
> developing for login to LUKS with smartcard tokens requires the core 
> modules (smartcard udev drivers as well as core executables) to be 
> compiled/build with certain options (the standard/desktop-related 
> builds will NOT work - i.e. using inst_* from dracut_functions on 
> these on the already installed libraries/executables will NOT work), 
> so for this module I need to carry quite a few .so and executable 
> files, which will be architecture-dependent and have to be compiled in 
> advance.
A bit further on this.

I was able to build initramfs, which is for a different architecture 
from the host by using image built with kickstart.

Kickstart used dracut resources on the host, but built all the 
dependencies within the image itself which had a different architecture 
(my development host is on FC13 and x86_64, the image built was for 
P2-specific machine using custom-built-and-heavily-patched kernel, i.e. 
i686 architecture). It runs beautifully - cross-building is indeed 
possible!

In my new module I did insert architecture-probing code to install 
different architecture-dependent libraries, which isn't ideal, but it 
does the trick - for now.

Re: dracut

[Ambroz Bizjak]

On Fri, Oct 22, 2010 at 1:35 PM, Mr Dash Four
<mr.dash.four-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> Is it possible to build dracut for system/architecture which is different
> from the host on which dracut is run?

I have been interested in this before. However I decided it would be
too much work to add this functionality to dracut. Instead I wrote my
own initramfs generator which can do that by design.
It is very basic compared to dracut (can only boot from physical
disks), but I don't need anything else.
If anyone is interested, take a look at http://code.google.com/p/ainitramfs/ .

My generator, like dracut, takes all binaries from the existing
system. In my opinion, building software is out of scope for an
initramfs generator.
If some software doesn't work as intended when used inside the
initramfs, it should be updated to work, or, a seperate version should
be built specifically for use in the initramfs (but by the package
manager, not the generator).

Re: dracut

[Mr Dash Four]

>> Is it possible to build dracut for system/architecture which is different
>> from the host on which dracut is run?
>>     
>
> I have been interested in this before. However I decided it would be
> too much work to add this functionality to dracut. Instead I wrote my
> own initramfs generator which can do that by design.
>   
I succeeded in incorporating initramfs for a different architecture from 
the building host yesterday - by using kickstart. See my previous post 
on this very thread.