Forum Debian Users Gang

nmarx · 2016-05-13 22:51:54

Witam, posiadam nowego cruciala mx200 (250gb) i męczy mnie kwestia ustawień TRIM przy dysku zaszyfrowanym podczas instalacji (LUKS+LVM). Z tego co wyczytałem to aby aktywować TRIM w takiej konfiguracji, należy dodać opcję discard nie tylko w crypttabie ale też w konfiguracji lvm oraz jeszcze w /etc/fstab, przy czym, jeśli chodzi o LUKS obniża się wtedy bezpieczeństwo szyfrowania w jakimś tam sposób (nie wnikam).

Czy jest jakaś alternatywa? A może to olać i po prostu korzystać? Zainteresowało mnie jednak takie zdanie (w wątku SSDOptimization na Wiki Debiana):

"Alternative to setting the "discard" options is to set up an offline-trim cronjob that runs time fstrim -v on the ssd mountpoints periodically"

Ale to chyba dotyczy alternatywy co do umieszczania opcji discard w /etc/fstab a nie całego wcześniejszego procesu (crypttab, lvm)

Jak wy rozwiązujecie kwestie ustawień Trim przy szyfrowanym dysku z LVM-em?

Ostatnio edytowany przez nmarx (2016-05-13 23:01:39)

mati75 · 2016-05-13 23:00:34

Trafiłeś idealnie, to samo 10 minut temu na tym samym dysku robiłem :D

https://wiki.archlinux.org/index.php/Solid_State_Drives#TRIM

Tu jest opis.

nmarx · 2016-05-13 23:09:55

[quote=mati75]Trafiłeś idealnie, to samo 10 minut temu na tym samym dysku robiłem :D

https://wiki.archlinux.org/index.php/Solid_State_Drives#TRIM

Tu jest opis.[/quote]
Hah! :) I jak Ci poszło?

Rozumiem, że dodałeś opcję discard w crypttabie, lvm.conf i /etc/fstab lub skrypt fstrim+cron ew. poprzez systemd?

Tylko właśnie czytałem na wiki debiana, że w przypadku LUKS obniża to bezpieczeństwo szyfrowania.
Więc zastanawiam się czy nie ma innej drogi, ew olać to.

Ostatnio edytowany przez nmarx (2016-05-13 23:10:57)

mati75 · 2016-05-13 23:22:22

Nie mam systemd, tylko openrc a reszta identycznie.

Ostatnio edytowany przez mati75 (2016-05-14 13:26:54)

morfik · 2016-05-14 10:41:08

przy czym, jeśli chodzi o LUKS obniża się wtedy bezpieczeństwo szyfrowania w jakimś tam sposób (nie wnikam).[/quote]
Z tego co ja wiem, to "problem z bezpieczeństwem szyfrowania" dotyczy nagłówków, w których są klucze szyfrujące i zahashowane hasłą. Przykład: jeśli stworzysz nagłówek na dysku SSD i później przyjdzie ci zmienić klucz lub hasło do tego nagłówka, np. dodasz nowy slot albo wyczyścisz stary, to wtedy właśnie przez to równoważenie zużycia komórek, nowy nagłówek (lub tylko jego część) może zostać zapisana w innym miejscu, zostawiając tym samym stary nagłówek nietknięty. W efekcie może i zmieniłeś klucz czy hasło ale w dalszym ciągu na dysku są te stare dane i przy ich pomocy można otworzyć kontener. Czyli w przypadku, gdy ktoś poznał twoje hasło i ty je zmienisz na dysku SSD, to jest niemal pewne, że ten ktoś przy analizie dysku uzyska dostęp posługując się starym hasłem. xD

Można to fixnąć, przez utworzenie tylko jednego nagłówka i niewprowadzaniu do niego żadnych zmian. Wtedy będzie dobrze.

Ostatnio edytowany przez morfik (2016-05-14 10:42:34)

Time (s)	Query
0.00011	SET CHARSET latin2
0.00005	SET NAMES latin2
0.00134	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.138.174.174' WHERE u.id=1
0.00156	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.138.174.174', 1714910634)
0.00050	SELECT * FROM punbb_online WHERE logged<1714910334
0.00076	SELECT topic_id FROM punbb_posts WHERE id=301543
0.00127	SELECT id FROM punbb_posts WHERE topic_id=28618 ORDER BY posted
0.00090	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=28618 AND t.moved_to IS NULL
0.00005	SELECT search_for, replace_with FROM punbb_censoring
0.00108	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=28618 ORDER BY p.id LIMIT 0,25
0.00165	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=28618
Total query time: 0.00927 s

Forum Debian Users Gang

Ogłoszenie

#1 2016-05-13 22:51:54

nmarx - Użytkownik

Luks, Trim, nowy SSD - kilka pytań

#2 2016-05-13 23:00:34

mati75 - Psuj

Re: Luks, Trim, nowy SSD - kilka pytań

#3 2016-05-13 23:09:55

nmarx - Użytkownik

Re: Luks, Trim, nowy SSD - kilka pytań

#4 2016-05-13 23:22:22

mati75 - Psuj

Re: Luks, Trim, nowy SSD - kilka pytań

#5 2016-05-14 10:41:08

morfik - Cenzor wirtualnego świata

Re: Luks, Trim, nowy SSD - kilka pytań

#6 2016-05-14 19:09:48

nmarx - Użytkownik

Re: Luks, Trim, nowy SSD - kilka pytań

#7 2016-05-14 21:08:39

enether - wiecznie niewyspany

Re: Luks, Trim, nowy SSD - kilka pytań

#8 2016-05-16 00:14:38

nmarx - Użytkownik

Re: Luks, Trim, nowy SSD - kilka pytań

#9 2016-05-16 08:31:00

yossarian - Szczawiożerca

Re: Luks, Trim, nowy SSD - kilka pytań

Stopka forum

Informacje debugowania