genkernel/LUKS Problem: Crypto-Module werden nicht in die initramfs integriert

Lieber Besucher, herzlich willkommen bei: GentooForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

psh

Anfänger

Beiträge: 10

03.11.2011, 13:03

genkernel/LUKS Problem: Crypto-Module werden nicht in die initramfs integriert

Hallo allerseits,

ich habe das Problem, dass die crypto-Module, die eigentlich per genkernel integriert werden sollten, nicht in der initramfs enthalten sind - zumindest dachte ich, dass es so funktioniert.

Kurz etwas zur Vorgeschichte und wie sich das Problem bemerkbar macht:

Ich habe Gentoo mit dem 20111004 x86 Image neu installiert. Die komplette Festplatte ist verschlüsselt:

	Quellcode
1	cryptsetup -c aes-xts-plain -s 512 luksFormat /dev/hda

Darin enthalten ist ein LVM mit der root-Partition. Der Kernel wurde mit Hilfe von genkernel erstellt:

	Quellcode
1	genkernel --menuconfig --lvm --luks all

In der chroot-Umgebung sehe ich unterhalb des Verzeichnisses /lib/modules/2.6.39-gentoo-r3/kernel die Ordner

arch
crypto
drivers
fs
lib
net
sound

Das initramfs-System zeigt mir an dieser Stelle nur folgenden Ordner an

drivers
fs
net

Und beim Versuch das System zu entschlüsseln erhalte ich folgende Meldung:

Quellcode

# cryptsetup luksOpen /dev/hda luks
Enter passphrase for /dev/hda:
device-mapper: reload ioctl failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/hda.
Check that kernel supports aes-xts-plain cipher (check syslog for more info).
Failed to read from key storage.

Ich freue mich sehr, wenn jemand ein paar Anregungen für mich hat. Evlt. habe ich notwendige Schritte ausgelassen, damit diese Module überhaupt in die initramfs integriert werden.

Vielen Dank im Voraus!

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »psh« (03.11.2011, 15:25)

Zum Seitenanfang

dyle

Erleuchteter

Beiträge: 4 869

03.11.2011, 18:44

Hallo und willkommen im Forum!

Soso ... hast du das http://forums.gentoo.org/viewtopic-t-859682.html vlt. schon gelesen? Was sagt dein /var/log/messages dazu?

http://www.dyle.org
IM-Account (Jabber!) sind auf meiner HP ...
There is no place like /home

http://www.gentooforum.de
http://www.gentoofreunde.org

<div>how to annoy a web developer?</span>

Zum Seitenanfang

psh

Anfänger

Beiträge: 10

04.11.2011, 00:22

Vielen Dank für die Begrüßung!

Auf den genannten Link bin ich bei meiner Lösungssuche auch gestoßen, jedoch erkenne ich darin keine Lösung für mich.

In dem von mir installierten System ist cryptsetup in Version 1.1.3 im Einsatz und ich habe die Verschlüsselung auch mit genau dieser Version angelegt

	Quellcode
1	cryptsetup -c aes-xts-plain -s 512 luksFormat /dev/hda

Das Öffnen von diesem verschlüsselten Container durch die initramfs per cryptsetup luksOpen ... schlägt fehl.
Wenn ich die verlinkte Lösung richtig verstehe, geht es dort aber um eine Lösung für Kompatibilitätsprobleme mit cryptsetup 1.0.x Versionen.

Zum Seitenanfang

dyle

Erleuchteter

Beiträge: 4 869

04.11.2011, 07:29

Ok. Und dein /var/log/messages?

Auch gibt es mit verbose bzw. debug extra Info?

Quellcode

# cryptsetup --help
cryptsetup 1.2.0
Usage: cryptsetup [OPTION...] <action> <action-specific>]
      --version                       Print package version
  -v, --verbose                       Shows more detailed error messages
      --debug                         Show debug messages
...

http://www.dyle.org
IM-Account (Jabber!) sind auf meiner HP ...
There is no place like /home

http://www.gentooforum.de
http://www.gentoofreunde.org

<div>how to annoy a web developer?</span>

Zum Seitenanfang

psh

Anfänger

Beiträge: 10

04.11.2011, 08:22

Oh ja, darauf habe ich ganz vergessen zu antworten, aber es wird keine neuen Erkenntnisse mit sich bringen, denn in der initramfs befindet sich sich unterhalb von /var/ kein log-Ordner und somit auch keine messages-Datei.

Ich werde cryptsetup mal mit verbose bzw. debug aufrufen (dazu komme ich jedoch erst später heute).

Vielen Dank soweit für die Hilfe!

Zum Seitenanfang

psh

Anfänger

Beiträge: 10

05.11.2011, 18:13

Hallo,

so sieht das Ergebnis aus, wenn ich cryptsetup mit dem --debug Parameter starte:

Quellcode

# cryptsetup --debug luksOpen /dev/hda lukslvm
# cryptsetup 1.1.3 processing "cryptsetup --debug luksOpen /dev/hda lukslvm"
# Locking memory.
# Allocating crypt device /dev/hda context.
# Trying to open and read device /dev/hda.
# Initialising device-mapper backend, UDEV is disabled.
# Detected dm-crypt target of version 1.10.0.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Iteration time set to 1000 miliseconds.
# Password verification disabled.
# Trying to load LUKS1 crypt type from device /dev/hda.
# Initialising crypto backend (using secure memory).
# Reading LUKS header of size 1024 from device /dev/hda.
# Activating volume lukslvm [keyslot -1] using [none] passphrase.
# dm status lukslvm OF [16384]
Enter passphrase for /dev/hda:
# Trying to open key slot 0 [3].
# Reading key slot 0 area.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-16636
# dm create temporary-cryptsetup-16636 CRYPT-TEMP-temporary-cryptsetup-16636 OF
# temporary-cryptsetup-16636: Stacking NODE_ADD (253,0) 0:0 0600
# dm reload temporary-cryptsetup-16636 OF [16384]
device-mapper: reload ioctl failed: No such file or directory
# dm remove temporary-cryptsetup-16636 OF [16384]
# temporary-cryptsetup-16636: Stacking NODE_DEL (replaces other stacked ops)
Failed to setup dm-crypt key mapping for device /dev/hda.
Check that kernel supports aes-xts-plain cipher (check syslog for more info).
Failed to read from key storage.
# Releasing crypt device /dev/hda context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 5: Failed to read from key storage.

Die Ausgabe von cryptsetup luksDump /dev/hda sieht soweit auch wie gewollt aus.

Die Ausgabe von dmesg habe ich ein wenig gefiltert:

Quellcode

# dmesg | grep device-mapper
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@readhat.cZu ICom
device-mapper: table: 253:0: crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table

Ich habe parallel zu dieser Installation noch eine virtuelle Testinstallation durchgeführt und bei dieser habe ich

Device mapper support
Crypt target support
XTS support (EXPERIMENTAL)
AES cipher algorithms
AES cipher algorithms (x86_64)
SHA1 digest algorithm
SHA224 and SHA256 digest algorithm
SHA384 and SHA512 digest algorithms

in den Kernel integriert (<*>) und nicht als Modul (<M>) gekennzeichnet. Aber der Fehler ist identisch und per modprobe ist es mir auch nicht möglich aes und xts nachzuladen, da diese nicht vorgefunden werden.

Zum Seitenanfang

dyle

Erleuchteter

Beiträge: 4 869

07.11.2011, 09:52

Hm, knifflig. Ich denke dein ramdisk hat da zu wenig. Wie kommts das ... o.O

Ich sehe in deinem Fall jedenfalls mal das:
http://forums.gentoo.org/viewtopic-t-865395-start-0.html
https://bugzilla.redhat.com/show_bug.cgi?id=433078
https://bugzilla.redhat.com/show_bug.cgi?id=432813

Baue die Treiber bitte als Modul "<M>" und dann knall mal genkernel mit "--all-ramdisk-modules" hin. Ist zwar nicht schön, aber versuchen wir's doch mal mit dem Vorschlaghammer. Hast du dann was an "crytpto" in der ramdisk?

http://www.dyle.org
IM-Account (Jabber!) sind auf meiner HP ...
There is no place like /home

http://www.gentooforum.de
http://www.gentoofreunde.org

<div>how to annoy a web developer?</span>

Zum Seitenanfang

psh

Anfänger

Beiträge: 10

07.11.2011, 13:24

Hallo und ein Danke an dyle für seine tüchtigen Recherchen

Leider haben die letzten Links mir nicht weiter geholfen, aber dennoch habe ich es soeben "geschafft", dass System zu booten. Ich habe

	Quellcode
1	genkernel --lvm --luks --menuconfig all

noch einmal aufgerufen - in der VM-Installation - und musste feststellen, dass

Device mapper support
Crypt target support
XTS support (EXPERIMENTAL)
AES cipher algorithms
AES cipher algorithms (x86_64)
SHA1 digest algorithm
SHA224 and SHA256 digest algorithm
SHA384 and SHA512 digest algorithms

als <M> Module markiert waren und nicht als <*> build-in, so wie ich es zuvor bereits gemacht hatte oder besser gesagt mir 100% sicher war, es gemacht zu haben. Im Anschluss daran hat das System nach Eingabe des LUKS-Kennworts sauber durchgebootet.

Ich werde die genannten Treiber in einem nächsten Schritt noch einmal als Module integrieren und genkernel mit "--all-ramdisk-modules" ausführen. Danach berichte ich wieder.

Zum Seitenanfang

josef.95

OSI Layer 8

Beiträge: 7 674

07.11.2011, 15:13

Hallo

Ich würde auch versuchen auf die aktuellen libata Treiber umzustellen, denn /dev/hd* wird von den aktuellen udev Versionen nicht mehr unterstützt.
Siehe hierzu zb auch im Thread/Beitrag Libata Migration
Ich hab keine Ahnung ob dein aktuelles Problem damit zusammenhängt, doch wenn möglich stelle besser auf die libata Treiber um ;)

Zum Seitenanfang

psh

Anfänger

Beiträge: 10

07.11.2011, 18:51

Hallo josef.95,

danke für deinen Hinweis, ich sollte das auf jeden Fall bei der nächsten Installation berücksichtigen. Die erste Testinstallation habe ich mit einem recht alten Notebook gemacht, welches noch nicht über eine SATA-Festplatte verfügt, daher vermutlich die automatische Erkennung als hdx-Device.

In meiner zweiten Testinstallation in einer virtuellen Maschine wurden die Festplatten dann ja auch als sdx-Device erkannt und die durchgeführten Installationsschritte waren (eigentlich) 1:1 identisch.

Zum Seitenanfang

irata

Anfänger

Beiträge: 1

07.11.2011, 19:28

In das Problem bin ich auch geschlittert. Zugegeben, es ist meine erste Gentoo-Installation, so hat es auch fast einen Tag gedauert, mich durch die Init-Scripte von Gentoo zu wuseln und das System komplett zu verstehen (komme von Debian).
Lösung:
1. initramfs entpacken

	Quellcode
1 2	root@vogone ~ # mkdir initramfs; cd initramfs root@vogone ~/initramfs # cat /boot/initramfs-genkernel-$(uname -m)-$(uname -r) \| gzip -d \| cpio -H newc -i

2. Überprüfen der Module in der initramfs:
Folgende Module sollten existieren (hier in der 64Bit-Variante für aes-cbc-essiv:sha256) - alle im Unterverzeichnis der entpackten initramfs:
lib/modules/$(uname -r)/kernel/crypto/aes_generic.ko
lib/modules/$(uname -r)/kernel/crypto/sha256_generic.ko
lib/modules/$(uname -r)/kernel/arch/x86/crypto/aes-x86_64.ko

Falls nicht vorhanden, reinkopieren (aus entsprechendem /lib-Unterverzeichnis) oder entprechend genkernel mit --all-ramdisk-modules bauen und wieder zu Schritt 1 (initramfs entpacken).

3. Crypto-Module laden:
In der initramfs unter etc/modules eine Datei crypto mit folgendem Inhalt erstellen:

	Quellcode
1 2 3 4	dm_crypt aes_generic aes-x86_64 sha256_generic

Diese muss in etc/initrd.defaults in die Variable MY_HWOPTS (letzte Zeile) eingetragen werden:

	Quellcode
1	MY_HWOPTS="${MY_HWOPTS} crypto keymap "

4. Initramfs wieder packen:

	Quellcode
1	root@vogone ~/initramfs # find . \| cpio -H newc -o \| gzip > /boot/initramfs-genkernel-$(uname -m)-$(uname -r)

5. Neu booten und daran denken, daß in der Busybox das Standard-Keyboard-Layout auf US steht (es sei denn, man hat den genkernel mit --do-keymap-auto gebaut). cryptsetup läuft nun problemlos durch und mapped das unter /dev/mapper/root

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »irata« (07.11.2011, 20:40)

Zum Seitenanfang

psh

Anfänger

Beiträge: 10

08.11.2011, 00:12

Zitat

Baue die Treiber bitte als Modul "" und dann knall mal genkernel mit "--all-ramdisk-modules" hin. Ist zwar nicht schön, aber versuchen wir's doch mal mit dem Vorschlaghammer. Hast du dann was an "crytpto" in der ramdisk?

Ich habe genkernel --lvm --luks --menuconfig --all-ramdisk-modules all ausgeführt und die entsprechenden Treiber als Modul <M> eingebaut. Nach der erfolgreichen Passworteingabe in der initramfs bekam ich die gleichen Fehler zu sehen, mit denen ich zu Beginn konfrontiert wurde.

Kurzerhand shell eingeben und dort dann folgende Befehle ausgeführt:

	Quellcode
1 2 3	# modprobe xts # modprobe aes_generic # cryptsetup luksOpen /dev/sda lukslvm

Diese drei Befehle haben reibungslos funktioniert.

Soweit so gut. Wie geht es denn nun weiter? Diese Treiber befinden sich nun zwar als Module in der initramfs (kurze Frage: Wann spricht man von initramfs und wann von ramdisk?), aber sie werden nicht automatisch geladen. So ist die Erkenntnis doch nun, oder? Ist es mit genkernel nicht möglich, die Treiber so zu integrieren, dass sie als Module hinzugefügt und automatisch geladen werden?
Ist es nur auf dem manuellen Weg möglich, so wie irata es beschrieben hat? Also manuelle Anpassung der initramfs?