Arch rc.sysinit: LUKS parallel

Im Arch Bootscript /etc/rc.sysinit werden u.A. die per /etc/crypttab definierten verschlüsselten Volumes geöffnet und gemountet – sequentiell. Da ein luksOpen-Aufruf generell schon recht lange dauert, kommen bei mehreren solcher Volumes schnell einige Sekunden zusammen.

Auf einer Kiste mit fünf LUKS-Volumes kam mir die Idee, die entsprechende Funktion mal per “&” zu forken und das Ganze so ein wenig zu parallelisieren.

In wie fern das jetzt tatsächlich im messbaren Bereich liegt, sei mal dahingestellt. Ich bilde mir jedenfalls erfolgreich einen Geschwindigkeits-zuwachs ein, und da der Patch meines Erachtens recht unkritisch ist, bleibe ich dabei

Wer es ausprobieren mag:

--- /etc/rc.sysinit.backup      2010-01-24 15:35:12.000000000 +0100
+++ /etc/rc.sysinit             2010-05-04 18:57:53.380890577 +0200
@@ -149,7 +149,7 @@
                        cpass="$3"
                        shift 3
                        copts="$*"
-                       stat_append "${cname}.."
+                       #stat_append "${cname}.."
                        # For some fun reason, the parameter ordering varies for
                        # LUKS and non-LUKS devices.  Joy.
                        if [ "${cpass}" = "SWAP" ]; then
@@ -188,15 +188,16 @@
                        fi
                        if [ $? -ne 0 ]; then
                                csfailed=1
-                               stat_append "failed "
+                               stat_append "${cname} failed "
                        else
-                               stat_append "ok "
+                               stat_append "${cname} ok "
                        fi
                fi
        }
        while read line; do
-               eval do_crypt "$line"
+               eval do_crypt "$line" &
        done </etc/crypttab
+       wait
        if [ $csfailed -eq 0 ]; then
                stat_done
        else

Cryptomania

Aufgrund jüngster Ereignisse konnte ich mich endlich aufraffen, mein Sicherheitskonzept zu überdenken und ein Redesign anzugehen. Schritt 1: Volume Encryption.

Notebook: Hatte ich kürzlich auf LVM umgebastelt, erfüllt schon die neuen Richtlinien. Verschlüsselte home-Partition und verschlüsselter root, swap genauso. Sollte genügen; auf /usr, /var, etc. liegen ja keine persönlichen Daten.

Workstation: Hier bestand der größte Handlungsbedarf, da bis dato vollständig ungesichert. Leider herrscht hier Windoofs vor (ich gestehe ), da hauptsächlich als Gaming-PC genutzt, d.h. LUKS scheidet leider aus. Truecrypt dient als Ersatz. Benchmarks werden zeigen, ob dadurch die Spieleperformance merklich leidet.

Homeserver: Hier killt die Verschlüsselung jeden verbliebenen Rest Power. Die Box (S100) hat nur 700MHz und 128MB SDRAM (embedded device, Seite dazu folgt), zudem eine per SATA-to-IDE angeschlossene Notebookfestplatte und einen als Systemlaufwerk dienenden billig-USB-Stick. Hier wird auch nur die Datenpartition gesichert, der Rest ist eh uninteressant.

Externe Platten: Sind (und waren gottseidank schon immer) verschlüsselt. Bei mehreren TB an Archiven wäre das wohl der größte Brocken Arbeit bzw. Rumsitzen-und-Warten gewesen ^^

XBOX: Dient als Mediaplayer und zum Zocken. Leider geht hier garnichts – aufgrund der ebenfalls schwachen Hardware hatte wohl nie jemand ernsthaftes Interesse, was dafür zu portieren. Ich könnte natürlich Linux draufklatschen und LUKS nutzen, aber Spiele von HDD wären dann nicht mehr möglich – mal überdenken.

Handy, PDA & Co.: Nunja, an dem Punkt war ich schonmal, und habe damals beschlossen, es sein zu lassen. Zu viele Nachteile (z.B Synchronisationsprobleme beim PDA) bei geringem Nutzen. So vertrauenswürdige SMS verschicke ich eh nicht (abgesehen davon würde man die eh beim Provider abfangen) und meine Klausurtermine auf dem PDA dürften auch von keinem größeren Interesse sein

Schritt 2 ist damit eng verknüpft und auch schon angegangen: Passwortrevolution…

Trau’ nicht dem LUKS!

Man sollte meinen, die Fehlermeldung “No key available with this passphrase” für eine mit LUKS verschlüsselte Partition wäre eindeutig und man hat eine falsche Passphrase eingegeben oder das falsche keyfile benutzt. Dem ist aber nicht so, wie ich kürzlich schmerzhaft lernen musste: diese Meldung wird nämlich auch ausgegeben, wenn schlichtweg das Kernelmodul für den Algorithmus fehlt! In meinem Fall hatte ich einfach vergessen, aes-i586 zu laden…

Tja, leider wie gesagt erst nach dem sinnlosen Formatieren (und damit Wegwerfen) einer 500GB-Partition mit nicht ganz unwichtigen Daten bemerkt, nämlich als beim Bootup nach der Neuformatierung das gleiche Problem auftrat und ich langsam misstrauisch wurde. Ein Vergleich der Vorgehensweisen beim Verschlüsseln und Einhängen brachte dann den entscheidenden Unterschied ans Tageslicht – das fehlende Modul…

Die Moral von der Geschicht’: traue Fehlermeldungen nicht!