Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user.catalan > #6486

Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net

From Eloi <entfe001@gmail.com>
Newsgroups linux.debian.user.catalan
Subject Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net
Date 2020-12-07 22:10 +0100
Message-ID <BjvVE-4Oi-19@gated-at.bofh.it> (permalink)
References <BiBqq-1v3-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.debian.user.catalan | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

(deb-cat) Efecte acumulatiu de SSD, que no fa net Narcis Garcia <debianlists@actiu.net> - 2020-12-04 18:10 +0100
  Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Àlex <alex@probeta.net> - 2020-12-05 07:10 +0100
    Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Àlex <alex@probeta.net> - 2020-12-05 07:30 +0100
      Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Narcis Garcia <debianlists@actiu.net> - 2020-12-05 09:50 +0100
        Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Eloi <entfe001@gmail.com> - 2020-12-07 22:10 +0100
          Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Narcis Garcia <debianlists@actiu.net> - 2020-12-08 10:20 +0100

csiph-web