geli auf glabel per loader.conf konfigurieren?

T

TCM

Well-Known Member
Hi,

ich versuche grade, http://markmail.org/message/utccwfccusus6l6r nachzubauen, aber es funktioniert nicht.

Code: 
geom_eli_load="YES"

geli_label_testdisk_keyfile0_load="YES"
geli_label_testdisk_keyfile0_type="label/testdisk:geli_keyfile0"
geli_label_testdisk_keyfile0_name="/boot/keys/test.key"

Boot per PXE und tftpd. Der Key wird vom tftp-Server geladen, /dev/label/testdisk existiert nach dem Boot auch, aber das geli nicht.

Irgendwas Offensichtliches, was ich übersehe?
 
Ist zwar nicht so toll, aber wenn keine Keyfile benutzt wird, funktioniert es, da keine device-abhängigen Einträge benötigt werden.
Aber wenn die Keyfile eh auf der Boot Partition liegt, ist das vllt eh kein Sicherheitsverlust.
 
Woran erkennst Du dann dass "geli geht nicht"? Oder "es funktioniert nicht"? Das sind keine ausreichenden Fehlerbeschreibungen um Dir helfen zu können.
 
Die anderen Disks, die ich ohne label konfiguriere, erscheinen im dmesg, noch bevor er das rootfs mountet:
Code: 
GEOM_ELI: Device da3.eli created.
GEOM_ELI: Encryption: AES-CBC 128
GEOM_ELI:  Crypto: hardware
Trying to mount root from zfs:rpool/root []...

Die Disks mit label erscheinen halt einfach nicht und sind nach dem Boot auch nicht konfiguriert. Der Plan war, auch den rpool auf gelabelten Disks zu haben und nicht auf "da2" und "da3".

In die Kiste gehen 24 Platten, da will ich unbedingt eine Abtraktionsebene haben und nicht alle Platten von vornherein auf ihren Controller-Platz festnageln, und überall das gleiche Keyfile wollte ich auch nicht haben.
 
Manche RAID-Controller schreiben Metadaten am Ende der Disk und zwar da wo typischerweise der GPT-Backup oder die GEOM-Metadaten sind und machen alles kaputt. Das kann man auch oft nicht abschalten. Der Adaptec-Controller, den ich habe lässt sich nicht dazu überreden, die Platten in Ruhe zu lassen, auch wenn ich ihm sage, dass er im HBA-Modus laufen soll.

Zweitens, ZFS hat die Eigenart, alle Devices, die nach Disks aussehen zu untersuchen, ob sie zu einem Pool gehören. Bei mir führt das dazu, dass der Server einmal die Devices (daX) in den Pool aufnimmt. Ein anderes Mal nimmt er sie per GPTID auf. Das ist sehr verwirrend und kann u.U. zu solchen Situationen führen, in denen etwas klemmt.

Drittens, Du benutzt Disks als "dangerously dedicated disks" (ohne Partitionsschema). Das führt dazu, dass die verschlüsselten Sektoren so aussehen könnten, wie die, die GEOM zur Erkennung benutzt (insbesondere im Falle der Verschlüsselung ist es halt Zufall was da an den Stellen steht was GEOM beim Erkennen "schmeckt"). Und dann kommen da zusätzlich noch die Probleme, die ich schon oben mit RAID-Controllern erwähnt habe.

Boote mal von einem Live-System (CD/DVD/USB) und analysiere was GEOM in der "Schmeck"-Phase (GEOM taste) da erkennt. Am besten Du fängst an, bevor ZFS noch geladen ist und guckst, ob die Label noch überlebt haben.
 
RAID-Controller ist nicht im Einsatz.

ZFS spielt überhaupt keine Rolle, solange die Disks nicht entschlüsselt sind. Außerdem existiert nur eine einzige Instanz, auf der ZFS irgendwelche Daten finden kann: das entschlüsselte geli device. Von daher spielt der Punkt, dass evtl. mehrere Devices existieren können, auf denen ZFS die gleichen Daten findet, hier überhaupt keine Rolle.

Der letzte Sektor ist vom glabel Metadatenblock belegt, der vorletzte vom geli Metadatenblock. Da sind keine Zufallsdaten. Die Zufallsdaten fangen einen Sektor vor dem geli Metadatenblock an.

Die letzten beiden Blöcke der Disk sehen so aus:

Code: 
00001800  47 45 4f 4d 3a 3a 45 4c  49 00 00 00 00 00 00 00  |GEOM::ELI.......|
[...]
00001a00  47 45 4f 4d 3a 3a 4c 41  42 45 4c 00 08 00 00 00  |GEOM::LABEL.....|
[...]

Manuell kann ich das geli device natürlich einwandfrei konfigurieren, also seh ich die ganzen Einwände mal als unbegründet an. Bei dem Typen in http://markmail.org/message/utccwfccusus6l6r funktionierts ja angeblich.
 
(Eine Sache noch: was funktioniert und was richtig ist, sind zwei Paar Schuhe.)

Ok. Jetzt verstehe ich es. Die Metablöcke scheinen also heil zu sein. Mit dieser Info komme ich weiter. Die Plattendaten scheinen intakt zu sein, dann kann man dem Kernel (oder den Kerneleinstellungen) die Schuld zuschieben.

Der Punkt ist, dass ELI schon geschmeckt wird bevor das Label geschmeckt wird. Ich habe diesen Fall noch nie gesehen. Kann man da vielleicht irgendwo den Boot-Vorgang verbose für GEOM schalten? Es erfordert, dass man genau sieht wie GEOM die Platten den GEOM-Modulen zuordnet.

Und zu ZFS: ZFS ist sehr aggressiv beim Suchen nach seinen Pool-Platten (es findet die Platten nicht doppelt, sondern nimmt die ersten als Pool-Member, die gerade den Plausibilitätscheck passieren, also einmal daX anderes mal /dev/gptid/xxxx). Allerdings ist das hier nicht relevant, weil GEOM vor ZFS alles einstellen sollte und das tut es nicht. Das Fehlverhalten von ZFS ist also nur ein Symptom/Konsequenz des Fehlverhaltens von GEOM.
 
Welches Fehlverhalten von ZFS denn? Davon hab ich nie was geschrieben. Vergiss einfach ZFS. Das ist für das Problem überhaupt nicht von Belang. Ich will das geli fertig konfiguriert vor mir haben, wenn der Kernel fertig mit Booten ist, ob da Daten draufliegen oder nicht, spielt bis hierhin keine Rolle.
 
Achso. Dann gibt es da noch mehr Meldungen? Kommt ZFS nochmal zurück mit "Pool konnte nicht importiert werden" oder sowas?

Ja. Deswegen habe ich oben ja gesagt, dass ZFS hier nicht relevant ist (lies bitte richtig) und dass Du den Boot verbose schalten sollst, damit man sieht, was GEOM eigentlich da macht.
 
Code: 
da0 at mpt0 bus 0 scbus2 target 0 lun 0
da0: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 32768MB (67108864 512 byte sectors: 255H 63S/T 4177C)
da0: Delete methods: <NONE(*)>
GEOM: new disk da0
da1 at mpt0 bus 0 scbus2 target 1 lun 0
da1: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
da1: 300.000MB/s transfers
da1: Command Queueing enabled
da1: 1024MB (2097152 512 byte sectors: 64H 32S/T 1024C)
da1: Delete methods: <NONE(*)>
cd0 at ata0 bus 0 scbus0 target 0 lun 0
cd0: <NECVMWar VMware IDE CDR00 1.00> Removable CD-ROM SCSI-0 device
cd0: Serial Number 00000000000000000001
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
pass0 at ata0 bus 0 scbus0 target 0 lun 0
pass0: <NECVMWar VMware IDE CDR00 1.00> Removable CD-ROM SCSI-0 device
pass0: Serial Number 00000000000000000001
pass0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
pass1 at mpt0 bus 0 scbus2 target 0 lun 0
pass1: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
pass1: 300.000MB/s transfers
pass1: Command Queueing enabled
pass2 at mpt0 bus 0 scbus2 target 1 lun 0
pass2: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
pass2: 300.000MB/s transfers
pass2: Command Queueing enabled
nfs_diskless: no NFS handle
TSC timecounter discards lower 1 bit(s)
Timecounter "TSC-low" frequency 1200000000 Hz quality 1000
acpi_acad0: acline initialization start
acpi_acad0: On Line
acpi_acad0: acline initialization done, tried 1 times
GEOM: new disk da1
GEOM: new disk cd0

Code: 
# ls /dev/label/
testdisk

Label ist da, geli nicht.

EDIT: *ARGH* Die Disk war nicht mit -b initialisiert.

Code: 
  -b  Ask for the passphrase on boot, before the
  root partition is mounted.  This makes it pos-
  sible to use an encrypted root partition.  One
  will still need bootable unencrypted storage
  with a /boot/ directory, which can be a CD-ROM
  disc or USB pen-drive, that can be removed
  after boot.

Jetzt gehts. Ich geh kaputt.

Code: 
Timecounter "TSC-low" frequency 1200000000 Hz quality 1000
GEOM_ELI: Device label/testdisk.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:  Crypto: hardware
 
Zuletzt bearbeitet:
Oh. Ich bin davon ausgegangen, dass Du mit einer Schlüsseldatei entsperrst und nicht mit einem Passwort. Ja, wenn Du Passwort hast, dann wird ohne -b beim Booten nicht nach einem Passwort gefragt.
 
Das -b ist auch bei einer Schlüsseldatei nötig, wie es aussieht. Es scheint eher ein generisches Flag zu sein, welches dem Kernel sagt, er soll das device automatisch einrichten. Das könnte auf jeden Fall besser dokumentiert sein.

Meine Disk hat auf jeden Fall nur ein Keyfile und kein Passwort.
 
Noch eine Frage... bevor man sich da wieder lächerlich macht... Du hast auch -P bei "geli init" angegeben, sodass ELI auch nur wirklich den Key will und ihn nicht mit leerem Passwort entschlüsseln will?
 
Ja, init war vorher:

Code: 
geli init -B none -e AES-XTS -K <keyfile> -l 256 -P -s 4096 /dev/label/[...]

Jetzt halt durch -b ergänzt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben