Obsługa TRIM przez dm-crypt / device-mapper

Kupię jutro nowy laptop z dyskiem SSD. Muszę wiedzieć o bieżącym stanie dm-crypt i TRIM. Widziałem kilka sprzecznych raportów, a większość działań wokół tego pytania wydaje się mieć> 1 rok. Niektórzy twierdzą, że przekazywanie TRIM dm-crypt zostało uwzględnione w wielu najnowszych wersjach jądra (co nie jest dla mnie problemem, ponieważ używam Arch). Niektórzy twierdzą, że wsparcie wciąż nie istnieje. Czy mogę uzyskać jasną, rzetelną odpowiedź na temat statusu obsługi TRIM DM-Crypt? git commits lub ogłoszenia na liście mailingowej, które wspominają o tej funkcji, byłyby idealne.

Odpowiedź na to pytanie ma duży wpływ na sposób, w jaki tworzę dyski mojego nowego laptopa. Mamy nadzieję, że niektórym innym przyda się przyzwoita, aktualna odpowiedź.

Dla przypomnienia, ta funkcja NIE istniała, kiedy po raz pierwszy opublikowałem to pytanie. Zapytałem na liście mailingowej i zostałem poinformowany przez Milan Broz, że odrzucanie przekazywania dla celów dm-crypt wciąż nie zostało zaimplementowane. Milan wskazał, że zamierza to wdrożyć w pewnym momencie, ale nie stwierdził, kiedy.

Po przeszukaniu w dm-crypt.c i powiązanych plikach przez jakiś czas okazało się, że dodanie TRIM byłoby dość proste. Napisałem listę, prosząc o ogólne porady na temat zadania, zanim wskoczyłem. Następnego dnia Milan przesłał łatkę, która implementuje przekazywanie TRIM na dm-crypt, i zostało to ustawione w systemie Linux-next. Powinien być zawarty w jądrze Linux 3.1.

Przekazywanie TRIM musi być jawnie włączone. Istnieją potencjalne problemy z bezpieczeństwem podczas korzystania z TRIM na urządzeniu z szyfrowaniem dm, ponieważ TRIM wysyła informacje o użyciu bloku do oprogramowania układowego na urządzeniu, które następnie oznacza ostatnio zwolnione obszary jako użyteczne (w każdym razie tak rozumiem). Oznacza to, że zainteresowana strona może uzyskać informacje o wzorcach użycia dysku. Na przykład postulowano, że osoba atakująca może prawie na pewno dowiedzieć się, jaki system plików był używany na zaszyfrowanym nośniku za pośrednictwem tych danych. Osoba atakująca może również uzyskać więcej przydatnych informacji, na przykład, że do niedawna zapisano wiele dużych plików (duże ciągłe bloki TRIM'd).

Zobacz te wątki w celach informacyjnych:

http://www.redhat.com/archives/dm-devel/2011-June/msg00093.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00042.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00088.html

tl; dr: Obsługa przekazywania TRIM dla celów dm-crypt będzie istniała w Linuksie> = 3.1, ale musi być włączona ręcznie przez cryptsetup i / lub dmsetup z powodu wycieku danych, który może umożliwić profilowanie w oparciu o wzorce wykorzystania dysku.

Począwszy od jądra 3.2.x, dm-crypt + brtfs powinien być bezpieczny. Zobacz odpowiedź na moje pytanie od Chrisa Masona:

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15554 i http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15564

Zgodnie z tym postem ...

Moje pytanie brzmi: co się stanie, jeśli warstwa dm-crypt znajduje się między systemem plików a rzeczywistym urządzeniem blokowym? Czy wykończenie zostanie przepuszczone, czy zostanie odrzucone?

Chyba przejdzie. Używam btrfs na dysku SSD, który jest szyfrowany za pomocą LUKS / dmcrypt i działa świetnie. Btrfs dość długo używa ata trim.

Możesz także potrzebować discardopcji montowania systemu plików.

cóż, jest ten wątek

https://bbs.archlinux.org/viewtopic.php?id=114924

i to narzędzie

http://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684

Jeszcze go nie użyłem, ale interesuje mnie również ten problem.