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.
