Obciążenie we / wy urządzenia z szyfrowaniem DM?


10

Jaki byłby narzut odczytu / zapisu przy użyciu dm-crypt (LUKS) jako pełnego szyfrowania dysku (w tym partycji root) na Linux-Desktop (Ubuntu)? Planuję tak to ułożyć: LUKS> LVM> ext4 Procesor użyty w systemie to Core2 Duo 2.1 GHz z 4 GB pamięci RAM.

  • Czy szyfrowanie takiego systemu spowodowałoby wielki / zauważalny narzut?
  • Czy w sieci można znaleźć jakieś nowe testy porównawcze? Jakie jest twoje osobiste doświadczenie?
  • Czy mogę wprowadzić jakieś ustawienia, aby poprawić wydajność?

Dziękuję za pomoc.

Odpowiedzi:


12

Nie ma narzutu we / wy zaangażowanego w dm-crypt - tylko narzut procesora ...;)

Na przykład na dwurdzeniowym systemie Athlon 64 2,6 GHz mogę kopiować z jednego dysku dm-crypt na inny z ~ 40 MB / s (jądro 2.6.26, dyski SATA 1,5 TB Seagate).

Dla wydajności upewnij się, że załadowany jest moduł zoptymalizowany pod kątem architektury, np

$ lsmod | grep aes
aes_x86_64             12416  6 
aes_generic            32552  1 aes_x86_64

Jeśli chodzi o bezpieczeństwo danych, nie ma potrzeby wyłączania pamięci podręcznej zapisu z powodu dm-crypt. Stare wersje nie obsługiwały barier zapisu, ale od 2010 roku (jądro 2.6.31 lub więcej) dm-crypt je obsługuje (odpowiednio wymuszanie dostępu do jednostek - FUA).

Przy okazji można argumentować, że szyfrowanie partycji root nie ma sensu.

Jednak szyfrowanie wymiany ma sens.


1
Można również argumentować, że bałagan w hdparm, gdy nie wiesz, co robisz (lub tylko myślisz, że wiesz), może uszkodzić dyski twarde.
— amfetamachina

Szyfrowanie partycji root ma sens, jeśli Twój model zagrożenia obejmuje możliwość uzyskania przez przeciwnika tymczasowego dostępu fizycznego i rozruchu w trybie pojedynczego użytkownika lub z dysku USB i zainstalowania złośliwego oprogramowania, takiego jak rejestrator kluczy lub rootkit. Dla zwykłych użytkowników oznacza to również, że nie musisz się martwić zapomnieniem szyfrowania /tmp(jeśli nie jest zamontowane z `tmpfs) i innymi katalogami, które mogą wyciec prywatne dane.
— Anthony Geoghegan,

1
@AnthonyGeoghegan, być może jest to skuteczne przeciwko niektórym przeciwnikom. Jednak w celu ochrony przed opisanym modelem zagrożenia musisz również zabezpieczyć program ładujący (np. Za pomocą oprogramowania układowego, które kryptograficznie sprawdza program ładujący przed jego uruchomieniem).
— maxschlepzig

@maxschlepzig Ta myśl przyszła mi do głowy, kiedy napisałem wcześniej komentarz, ale nie chciałem przesadzać z zastrzeżeniami i zastrzeżeniami w małym polu komentarza. Drugi powód jest prawdopodobnie ważniejszy: korzystam z FDE (na moim 10-letnim laptopie), więc nie muszę się martwić (tyle) o dane uwierzytelniające i klucze prywatne /etclub inne poufne dane, które są w jakiś sposób logowane /var/(pozytywnie, BTW ).
— Anthony Geoghegan,

0

Ext4 może być złym wyborem systemu plików, jeśli planujesz wykonywanie migawek LVM. Radzę przeprowadzić znaczne sprawdzenie wydajności dysku przed uruchomieniem, eksperymentując z rozmiarami bloków zarówno w FS, jak i LVM. Moje doświadczenie dotyczyło Ext3, ale inne artykuły, które wtedy widziałem, sugerowały, że Ext4 miał podobne problemy.

Rozwiązałem go, używając XFS jako systemu plików.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.