Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net
El 7/12/20 a les 22:05, Eloi ha escrit:
> El 5/12/20 a les 9:48, Narcis Garcia ha escrit:
>> El 5/12/20 a les 7:22, Àlex ha escrit:
>>> El 5/12/20 a les 6:59, Àlex ha escrit:
>>>> El 4/12/20 a les 18:00, Narcis Garcia ha escrit:
>>>>> Tinc un ordinador amb unitat SSD i, quan executo aquesta instrucció:
>>>>> $ sudo fstrim -a -v
>>>>>
>>>>> Em diu:
>>>>> /boot: 766,7 MiB (803893248 bytes) trimmed on /dev/sda1
>>>>> /: 243,1 GiB (261022449664 bytes) trimmed on /dev/mapper/sda2_crypt
>>>>>
>>>>> Algú sap quin és el problema i com resoldre'l ?
>>>>> Algú sap si hi ha programari per a fer anàlisi detallat d'aquest tema?
>>>> Narcís,
>>>>
>>>> Crec que fstrim en general no augmenta gaire el rendiment del disc,
>>>> però
>>>> pot donar problemes si s'utilitza molt freqüentment i sobretot si
>>>> s'utilitza sobre volums encriptats. Per exemple:
>>>>
>>>> https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
>>>>
>>>> Si vols millorar rendiment, passa de fstrim, posa la informació
>>>> confidencial en una partició a banda i encripta només aquesta partició,
>>>> no tota l'arrel /
>>>>
>>>> Salutacions
>>>>
>>>> Àlex
>>>>
>>> https://www.spinics.net/lists/raid/msg40916.html
>>>
>>> https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems
>>>
>> No vull augmentar la velocitat de la unitat, sinó recuperar-la com era
>> al principi.
>> L'arrel està encriptada perquè les dades són confidencials. Allò què fa
>> l'usuari és confidencial (i es revela a /tmp /var/tmp i altres
>> ubicacions) juntament amb còpies temporals de documents que es poden
>> obrir i eines que poden treballar a /opt , apart de què: Veure quines
>> aplicacions són instal·lades dóna pistes del format dels documents que
>> es treballen per tal d'escarbar en el desxifrat. I també la distinció
>> entre dades i programari dóna pistes entre la informació important i la
>> resta.
>>
>> Porto anys donant voltes a aquest tema (amb xifrat i sense) i no acabo
>> d'esbrinar quin és el problema amb Linux o util-linux.
>>
>> Ara per ara, per a rehabilitar una unitat SSD no veig altra sortida que
>> utilitzar blkdiscard per a formatejar-la tota de nou.
>>
>> Salut;
>> Narcís.
>
> Per parts:
>
> Un xifratge decent i ben implementat (i no em refereixo a la
> implementació del programari que s'usi per xifrar sinó a l'ús que se'n
> fa) d'un sistema de fitxers no permetrà "escarbar" en el contingut,
> doncs el xifratge inclou per definició totes les metadades, tant les
> incrustades en el propi fitxer com les que corresponen al propi sistema
> de fitxers (propietat, permisos, ctime, mtime i atime les més evidents).
> Si el xifratge que uses depèn de l'ofuscació de dades tan trivials com
> saber si està instal·lat LibreOffice, aquest xifratge no val per a res.
>
> És més, el mer fet de fer servir fstrim ja dóna metadades sobre el
> sistema de fitxers encriptat que, d'altra forma, serien impossibles o
> costoses d'aconseguir: estadístiques d'ús del disc. Després d'un fstrim
> només cal comptar quina proporció de sectors estan marcats com a
> reutilitzables per tenir una aproximació prou fiable de quin és el
> resultat de du, i donat que aquesta llista pot ser molt més fàcil
> d'obtenir i que es pot anar comparant durant el temps, es podria arribar
> a deduir a més llarg termini quins sectors són els ocupats per
> programari (dades estàtiques) i quins per documents i treballs en ús
> actiu (dades dinàmiques), tot això sense desxifrar mai ni un míser bit.
>
> Si, per altra banda, el que et preocupa és que s'usin vulnerabilitats
> per infiltrar-se al sistema i per això cal saber quins programes s'han
> d'intentar explotar, doncs aquí la clau és mantenir el sistema
> correctament actualitzat i instal·lant només de fonts de confiança (que,
> en el meu cas, és única i exclusivament el repositori de Debian). No cal
> ser molt espavilat per assumir que un sistema Linux d'escriptori tindrà,
> amb molta probabilitat, llibreries GTK (encara que usi KDE), un servidor
> CUPS en marxa, LibreOffice com a suite ofimàtica i les llibreries de
> ffmpeg i/o VLC per a multimèdia. Per no parlar de si s'envien a
> l'exterior documents creats i/o modificats en aquesta màquina, metadades
> dels quals poden donar indicis de què s'hi ha emprat.
>
> Però és que, a més, per aquest tipus d'infiltracions, el xifratge de
> disc de la partició arrel és inútil, doncs només resulta efectiu mentre
> el propi sistema de fitxers està desmuntat. En el cas del sistema arrel,
> doncs, el xifratge només és efectiu mentre l'ordinador estigui apagat.
> Un cop engegat (i entrada la clau de desxifratge), adéu a tota la
> protecció que ofereix. Si una vulnerabilitat s'explota amb l'ordinador
> engegat (que, fins que jo sé, sol ser el cas en la majoria d'ocasions),
> ja ho tens...
>
> Amb això no estic dient que el xifratge de disc no sigui útil, però que
> cal ser molt conscient de per què és útil i per a què no serveix, puix
> no hi res pitjor que una falsa sensació de seguretat que et faci abaixar
> la guàrdia. El xifratge és una peça important del complex trencaclosques
> per assegurar i blindar un sistema informàtic, però cal saber-la
> col·locar junt amb les altres peces. I l'ofuscació, per regla general,
> és la peça que sempre sobra.
>
> Dita la qual cosa, si pel que entenc el fstrim no és efectiu a la
> partició arrel xifrada (via /dev/mapper, que honestament desconec si
> passa les ordres TRIM al dispositiu pare) però tampoc a la d'arrencada
> (que, com bé apuntes, està directament sobre un dispositiu físic de
> disc), m'inclino a pensar més aviat que el problema rau en la pròpia
> controladora del disc SSD que s'ho passa per l'Arc de Triomf. Això, o un
> bug a fstrim o al kernel per al dispositiu en qüestió que faci que no
> acabi rebent l'ordre correcta.
>
> Si dius que et passa de fa temps, jo canviaria de proveïdor o de marca
> dels discs SSD. Perquè l'alternativa seria que fstrim no li funcionés a
> ningú, però el fet que ara mateix no hi hagi cap bug obert [1] al
> respecte em fa sospitar que no seria el cas.
>
> [1]
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Afstrim;package=util-linux
>
Està molt bé debatre sobre un altre assumpte (eficàcia i estratègies de
xifrat), però de diverses unitats SSD (amb i sense xifrat) no
aconsegueixo que conservin el rendiment que se li espera a aquesta
tecnologia, degut a què els blocs alliberats no es descarten.
També m'ha passat en màquines virtuals (KVM) amb SSD virtual.
La controladora SATA no la puc canviar sense canviar l'ordinador, i per
a canviar el SSD n'hauria de comprar un altre, i sense tampoc no saber
si hi haurà més sort.
En aquest ordinador concret el problema l'arrossego amb els nuclis Linux
4.19 (buster) 5.6 (buster-backports) 5.7 (buster-backports) i 5.8
(buster-backports)
i en altres ordinadors no et sabria dir (és possible que deb-stretch i
ub-bionic segons el cas)
La dificultat a la què m'enfronto és la manca d'eines per a analitzar el
problema. Com veig si la unitat SSD ha rebut l'ordre de descartar un
bloc? Com veig si un bloc «es considera» descartat o realment ho està?
Com veig la situació dels blocs a mitges (que estan utilitzats en part)?
Narcís.
Reply to: