SSD i Full Disk Encryption

[cisco]

Pre nego se iskesiram (posto izgleda da firma nece) hteo sam da proverim kako se slazu FDE i SSD. Ocekivao sam probleme obzirom da je za SSD dobro da uvek ima slobodnog prostora, a kriptovani diskovi su u principu puni random podataka cak i kada na njima nema mnogo korisnickih podataka. Googlao sam malo ali nema bas nesto kvalitetnih informacija o uticaju FDE na performanse SSD-a.

Neki zakljucak koji sam izvukao iz procitanog je da bechmark programi pokazuju zestoko usporenje (pogotovo upisa) i prema bechmark programima kriptovani SSD je na nivou performansi nekriptovanog hard diska (ili cak i gori). S druge strane, korisnicka percepcija je da se usporenje nakon enkripcije primeti, ali i dalje "sve leti" u odnosu na klasican hard disk.

Nesto bechmarka/iskustava:

http://img41.imageshack.us/img41/2379/vertexwithtruecryptbencm.png
http://anthonyvance.com/blog/security/ssd_encryption/
http://www.madshrimps.be/articles/article/965/

Da li je neko probao i kakva su iskustva? Koji disk sa kojim FDE softverom? Hvala

 

[alfaunits]

Sam FDE ne utice na sam SSD (osim SandForce kontrolere).
Medjutim, ovde je CPU bottleneck

Ja sam upravo isprobao C300 kroz TrueCrypt i nisam nesto zadovoljan mada su rezultati OK.
Random 4K: Prepolovljena brzina otprilike. Posto je u pitanju eSATA povezivanje trenutno (laptop, nemam ga gde inace), mislim da je to OK. Pre TC: ~20MB/s, sa TC-em: 9MB/s. Manje ali opet te cifre nisu lose
Random 4K @ QD32: Ufff.... 20MB/s Ovo je vec nekoliko puta prepolovljeno. Inace su oko 100MB/s (na desktopu su >200MB/s ali ovde je eSATA rack u pitanju).
Seq.: Tacno prepolovljene: ~110MB/s obicno, ~45-50MB/s sa TC-em.

CPU moze da radi ~100MB/s encrypt/decrypt AES-a koji i koristi TC za ovaj primer.

Situacija je verovatno extremno bolja za procesore koji imaju AES-NI ili AMD X6 (ako se ne varam, Nedjo je negde bash prikazao koliko X6 rastura za AES).

 

[cisco]

Ako dobro shvatam, testirao si eksterni disk (ono sto mi je bitno, nije sistemski). Jesi li koristio bas FDE ili kontejner encryption? Posto u slucaju FDE, disk je fakticki pun i uvek se koristi read-modify-write, TRIM i ostali trikovi ne pomazu.

Kakav je subjektivan osecaj, da li je kriptovani SSD jos uvek (znacajno) brzi od nekriptovanog harda (ako mozes to da uporedis)?

Hvala u svakom slucaju.

 

[alfaunits]

Ako dobro shvatam, testirao si eksterni disk (ono sto mi je bitno, nije sistemski).

Nije "externi" vec na eSATA. Performanse (posto je laptop u pitanju trenutno) su iste kao da se poveze na onboard port.
Nije sistemski.

Jesi li koristio bas FDE ili kontejner encryption? Posto u slucaju FDE, disk je fakticki pun i uvek se koristi read-modify-write, TRIM i ostali trikovi ne pomazu.

FDE particije - sto bi po performansama trebalo biti kao i da je FDE diska, ali se drugacije enkriptuje na pocetku.
TRIM bi trebao da radi ovde! Posto NTFS salje TRIM disku, FDE bi trebalo da to prosledi direktno. U source-u nisam video da ista radi sa TRIM-om. Da je u pitanju WRITE samo onda bi to bilo bez TRIM-a naravno.

Kakav je subjektivan osecaj, da li je kriptovani SSD jos uvek (znacajno) brzi od nekriptovanog harda (ako mozes to da uporedis)?

Naravno. Mnogo brze.

 

[cisco]

Hvala na odgovorima, u principu mi je dovoljno i ovo poslednje sto si rekao

Ali meni neke stvari nisu jasne pa bih hteo sebi da razjasnim:

TRIM bi trebao da radi ovde! Posto NTFS salje TRIM disku, FDE bi trebalo da to prosledi direktno. U source-u nisam video da ista radi sa TRIM-om. Da je u pitanju WRITE samo onda bi to bilo bez TRIM-a naravno.

Ili se ne razumemo ili ja ne shvatam sta to TRIM treba da radi. Dakle, po mom shvatanju (ispravi me ako lupam), pojednostavljeno receno, TRIM brise onaj deo diska koji se ne upotrebljava (za razliku od obelezavanja prostora koji je slobodan, ovde se bitovi zaista inicijalizuju na pocetnu vrednost koja dozvoljava "brzi" upis). Poenta je da kada treba da su upise neki podatak, jedan deo diska je prazan i spreman za "brzi" upis. Cak i modifikacija postojeceg podatka se radi tako sto se nova vrednost upise na novo mesto na disku, a staro mesto se markira kao slobodno (pa ce se kasnije u nekom praznog hodu inicijalizovati na pocetne vrednosti). Ako sam se nalupao ovde, slobodno me ispravi (a ako te mrzi, posalji me da citam dalje ,) )

Medjutim, kada se koristi FDE, ceo disk je kriptovan, ukljucujuci i prazan prostor - TRIM nema sta brise, ne postoji niz nula na disku jer je FDE kriptovao i nule i dobijamo nesto sto lici na slucajan niz brojeva... Dakle, za kontroler je disk pun i on nema sta da TRIM-uje. Sve ovo do sada sam zakljucio iz ono malo materijala sto sam izguglao (dakle nista moje iskustvo).

E onda se otvara pitanje da li je resenje problema da se radi FDE particije, ali tako da particija bude 10-20% manja od diska da bi kontroler imao neko mesto na raspolaganju za TRIM-ovanje? Ili mozda onih 7-28% prostora koje proizvodjaci ostavljaju "sa strane" sluzi za TRIM-ovanje i sve radi savrseno i kada je disk "pun", odnosno kada je particija pune velicine diska? Na ovo poslednje nisam nasao nikakav odgovor.

 

[alfaunits]

TRIM sluzi da se prostor obelezi slobodnim kada se neki file obrise. Ako je ceo blok slobodan (512KB tipicno), mislim da se odmah ceo blok erase-uje.
Kad se stranica (page od 4KB tipicno) markira kao slobodna, SSD je nece citati ako file system trazi podatke sa tog prostora nego ce vratiti predefinisane podakte (sve jedinice u slucaju OCZ diskova, ne znam za druge).

FDE ovde ne bi trebalo da se mesa, jer TRIM ne salje nikakve podakte koji se pisu na sam disk, vec salje komandu da se prostor markira kao prazan. Kazem, koliko sam video u TC source code-u TC ne radi nista po tom pitanju, pa TRIM komande verovatno stizu do diska bez problema.