Tag: dragonflybsd

È passato diverso tempo dall’ultima volta che abbiamo parlato di sviluppi interessanti su DragonFlyBSD, ma la scorsa settimana è stato introdotto dm_target_crypt_ng, un’implementazione di nuova generazione del loro codice DM-crypt per la crittografia dei dischi.

Lo sviluppatore di DragonFlyBSD, Michael Neumann, ha riprogettato il codice DM-crypt per questo sistema operativo BSD, trasformandolo in un’implementazione trasparente per la crittografia dei dischi compatibile con dm-crypt di Linux.

Michael Neumann ha spiegato nel commit iniziale questo codice di nuova generazione:

“dm_target_crypt_ng – Aggiunta implementazione di nuova generazione.

* Non utilizziamo più opencrypto o cryptodev. Erano asincroni e causavano molte (!) complicazioni al codice.

 

 

* Invece, utilizziamo il nostro set di cifrari crittografici implementati in crypto_cipher.{c,h}, che è un’API semplificata per utilizzare cifrari a blocchi simmetrici. Richiama principalmente le implementazioni effettive degli algoritmi crittografici contenute in sys/crypto.

 

 

* L’interattività è notevolmente migliorata! Quando si esegue “blogbench” con il vecchio modulo dm_target_crypt, “blogbench” sostanzialmente “blocca” il sistema a circa 400 blog (Nb). Il cursore del mouse si blocca continuamente per circa 1 secondo. Mentre il computer diventa più lento durante l’esecuzione di dm_target_crypt_ng, non si osserva alcun ritardo del mouse. Il risultato finale delle prestazioni di “blogbench” rimane pressoché invariato. Ad esempio:

 

 

# dm_target_crypt (vecchio)
Punteggio finale per le scritture: 2136
Punteggio finale per le letture: 200584

 

 

# dm_target_crypt_ng (nuovo)
Punteggio finale per le scritture: 2265
Punteggio finale per le letture: 203668

* I BIO vengono elaborati da due worker pool, ciascuno con un set di thread associati a una CPU specifica. Le richieste di lettura devono essere decrittografate, mentre le richieste di scrittura devono essere crittografate. Avere un worker pool separato per le richieste di lettura e scrittura dovrebbe garantire maggiore equità. Le richieste vengono schedulate ai worker tramite round-robin e “struct bio” viene utilizzato per concatenare le “richieste” da elaborare dai worker thread. I worker di lettura non necessitano di ulteriore allocazione di memoria per decrittografare i blocchi. I worker di scrittura utilizzano un mpipe condiviso come in precedenza, poiché è necessario copiare il buffer di scrittura prima di crittografarlo.

 

 

* Attualmente, dm_target_crypt_ng supporta solo AES-CBC e AES-XTS. Twofish e Serpent non sono supportati. Si dice che siano più sicuri, ma anche più lenti e non supportano l’hardware. Dovrebbe essere facile reinserirli in crypto_ciphers.{c,h}.

 

 

* Se si desidera provare il nuovo modulo, aggiungere la seguente riga a /boot/loader.conf:

dm_target_crypt_ng_load=YES

 

Questo potrebbe non funzionare con “swapon” poiché tenta di caricare manualmente “dm_target_crypt”.

 

 

* Il mio piano è di rendere “dm_target_crypt_ng” l’impostazione predefinita e rimuovere il vecchio “dm_target_crypt” dopo test e feedback più approfonditi.

Dal commit iniziale di qualche giorno fa, sono state aggiunte ulteriori patch per dm_target_crypt_ng. Le patch successive hanno rifattorizzato i cifrari crittografici, migliorato l’API dei cifrari crittografici e introdotto i cifrari Twofish/Serpent CBC/XTS. Alcuni interessanti miglioramenti per chi desidera utilizzare la crittografia del disco con DragonFlyBSD.

Dato che sono trascorsi più di due anni dalla precedente versione di questo sistema operativo, DragonFlyBSD 6.4, si spera che la prossima versione si concluda presto con questo target DM-crypt di nuova generazione e i molti altri miglioramenti che si sono aggiunti nel tempo.

Articolo originale su Phoronix