Dotaz: zrychleni pomaleho dm-cryptu?

[Bilbo]

Poridil jsem si maly notebook s 4jadrovym Atomem (presneji receno 2 fyzicka jadra s hyperthreadingem) a (jako s kazdym notebookem) na nem dal sifrovani celeho disku (teda krome male partition s /boot) pres dm_crypt. A tady nastal trochu problem s vykonem. Je to pomale. V praxi se to projevuje tak, ze cteni nebo zapis vetsich souboru je dosti pomale. Zkusil jsem "hdparm -t /dev/sda" a dosahuji rychlosti kolem 100 Mb/sec. Ale "hdparm -t /dev/mapper/sda5_crypt" ma za nasledek rychlost cca 16 Mb/sec (holt pomale jadro)

V topu jsem si vsiml, ze kcryptd pouziva jen jedno jadro a zbyla 3 se flakaji.

Zajimalo by mne, jestli lze (za predpokladu, ze cely disk zustane sifrovany) nejak zvysit vykon. Bud nejak prinutit dm-crypt aby vyuzil vsechny 4 dostupna jadra (pokud by pak cteni/zapis bylo 4x rychlejsi tak je to sice porad mene nez se protlaci diskem, ale uz ne takpova tragedie) - existuji na to nejake fungujici patche?, pripadne nasadit nejake jine reseni nez dm-crypt - existuje nejake?

Odpovědi

[Jendа]

Řekl bych, že 20 MB/s je tak ten limit pro AES-256 na Atomu (máš zavedený modul aes_i586?) a víc z toho asi nevyšťavíš. Mně to dává 18 MB/s (Atom N270 @ 1,6 GHz).

Teoreticky by měl být rychlejší AES s kratší klíčem (192 nebo 128 b) nebo jiný algoritmus (Blowfish). O paralelních implementacích jaderného šifrování nevím.

[Jendа]

Ostatně zkus si otestovat různé algoritmy.

openssl speed help

Blowfish je u mně skoro třikrát rychlejší, AES-128 je na tom bledě. Otázkou je, jak je na tom Blowfish s bezpečností, ale pokud máš citlivá data, ke kterým se zas tak moc často nepřistupuje, a systém, na který se hrabe furt, na zvláštním oddíle, zvážil bych šifrování citlivých dat AES a systému BF.

[Bilbo]

To jsem zkusil, ale blowfish je plusminus stejně rychlý (narozdíl od AES ho 64bit CPU moc nezrychlí) a přehození na 192 nebo 128 bitů klíče taky moc nepomůže (ze 22 Mb/sec to vyleze v openssl testu na 26 a 30 Mb/sec)

Jinak aes-i586 modul vubec nemam (asi je jen v 32bit kernelu), mam tam ale misto toho aes_x86_64 (predpokladam ze asi alternativa napsana v assembleru pro 64bit systemy) ktery je zavedeny zjevne automaticky (vylezl v lsmod aniz bych ho tam musel cpat)

Takze snad leda doufat, ze jednoho krasneho dne se tam doplni multithreading a rychlost pak ctyrnasobne vzroste .... a do te doby se holt smirit s pomalym diskem.

[fixinko]

ja len ze nieco taketo dostavam na serveri kde je Via C7 @ 1GHz (cpu starucke par rokov ale ma hw aes).

obelix ~ # hdparm -tT /dev/mapper/storage-array 

/dev/mapper/storage-array:
 Timing cached reads:   414 MB in  2.00 seconds = 206.49 MB/sec
 Timing buffered disk reads:  128 MB in  3.03 seconds =  42.22 MB/sec


obelix ~ # hdparm -tT /dev/sda 

/dev/sda:
 Timing cached reads:   422 MB in  2.00 seconds = 211.03 MB/sec
 Timing buffered disk reads:  200 MB in  3.00 seconds =  66.57 MB/sec
obelix ~ # 

/dev/sda je jeden sata disk, a /dev/mapper/storage-array je LVM zlozene zo 4roch diskov (ziadny raid, vsetko su to postarsie 3-4rocne disky). Na vsetkych je pouzite "aes & cbc-essiv:sha256". Tak neviem ci to je tym ze to nie je multithread, alebo pomalostou/architekturou toho Atomu :).

[Jendа]

Tak neviem ci to je tym ze to nie je multithread, alebo pomalostou/architekturou toho Atomu :).

Že by to bylo tím, že máš v procesoru VIA Padlock?

[fixinko]

ano mam, aj pisem ze to ma hw aes :), len som myslel ze taka feature len v podobe aes-ni je aj v Atome:).

[Bilbo]

Bohuzel neni, AES-NI maj az novejsi intel core i3/i5/i7 na 32nm procesu, ty starsi to nemaj a Atomy taky ne ...

[petr_p]

Nějakou dobu má Linux kompilační volbu CRYPTO_PCRYPT:

This converts an arbitrary crypto algorithm into a parallel algorithm that executes in kernel threads.

Ale mám dojem, že to je jen obálka pro asynchronní rozhraní a že DM_CRYPT by ji nejprve musel umět a pak rozdělit úlohu do více vláken.