(OPAL 1 est un peu différent et n’est pas analysé ici)

Généralités

La norme OPAL 2.0 est une norme qui définit notamment un standard pour qu’un péripĥérique de stockage (disque dur, ssd etc) auto-protège ses données par du chiffrement. C’est un SED, un Self-Encrypting Disk.
C’est donc une puce dans le disque lui-même qui s’occupe de chiffrer et déchiffrer les données (libérant ainsi le CPU de ces tâches, et réduisant la surface d’attaque concernant les failles CPU/RAM ; d’autres attaques concernant ce type de chiffrement sont toutefois existantes).

Le chiffrement du disque se fait un peu à la manière de LUKS : la clé qui va réellement chiffrer les données (Data Encryption Key, DEK) est elle-même chiffrée par le mot de passe utilisateur (Authentication Key, AK).
Ainsi, il est facile de changer le mot de passe du disque sans tout rechiffrer (la DEK ne change pas, mais est rechiffrée avec la nouvelle AK).
Il est également instantané et simple d’effacer de manière sécurisée et intégralement un disque, simplement en regénérant une nouvelle DEK. Ainsi, le reste du contenu n’a pas besoin d’être effacé, puisqu’il est indéchiffrable, la clé ayant été supprimée. C’est le Secure Disk Erasure.

Sur un disque OPAL, les données sont TOUJOURS chiffrées par une DEK, mais en l’absence de AK, la DEK est lisible en clair et donc utilisée de manière transparente (voir MSID).

Spécifications d’OPAL sur le site du TCG : https://www.trustedcomputinggroup.org/wp-content/uploads/TCGandNVMe_Joint_White_Paper-TCG_Storage_Opal_and_NVMe_FINAL.pdf

Un diaporama qui schématise bien OPAL et différentes attaques

USB

La disponibilité de l’interface OPAL via un adaptateur USB va dépendre de l’adaptateur en question. Ce fil mentionne un adaptateur qui semble fonctionner avec les disques M.2 SATA et NVMe.

Doc chez ArchLinux

Terminologie

• SD : Storage Device : le support de stockage (disque, SSD, clé USB etc)
• MEK (ou DEK) : Media (ou Data) Encryption key : la clé qui chiffre les données sur le disque ; chiffrée par la KEK
• AC : Authentication Credentials : le mot de passe utilisateur (“password”)
• AK : Authentication Key (ou PIN) : dérivée de l’AC
• KEK : Key-Encryption-Key : dérivée de l’AK, chiffre la DEK
• TPer : Trusted Peripheral
• MSID : Manufacturer Secure ID : une clé fixe, lisible par tout le monde directement sur le disque, qui fait office de AK par défaut.
• PSID : Physical Security ID : présent physiquement sur le disque (ou la boîte), permet de réinitiliser le disque (avec PERTE de données). Il est optionnel pour OPAL v2.00, et obligatoire pour OPAL v2.01
• Verrouillage (Locking) : Création/suppression de la MEK (déchiffrée) dans la RAM du disque. Lorsqu’elle est absente, le disque est verrouillé. Une fois la MEK accessible grâce au password, elle est stockée dans la RAM du disque jusqu’à la prochaine coupure d’alimentation (ou verrouillage manuel ?). Le disque est alors déverrouillé.

Locking Range

Les intervalles de verrouillage sont des sections continues sur le disque, exprimées en LBA, qui peuvent être verrouillées de manière indépendantes les unes des autres. Chaque intervalle a sa propre MEK.
Ceci permet, il me semble, de partager un disque entre plusieurs utilisateurs, en ne laissant chacun accéder qu’aux données qui lui sont autorisées.
Ceci permet également d’avoir certains intervalles qui ne sont PAS chiffrés.

Le Global Range représente l’ensemble des intervales qui ne sont pas définis explicitement (les Local Ranges). C’est le range 0.

Lorsqu’on définit un nouvel intervalle, les données déjà présentes dessus sont détruites.

On peut lister les LockingRange ainsi :
sudo ./sedutil-cli --listLockingRanges mYpAsSwOrD /dev/sdX

Authentification pré-boot

La Preboot-Authentication (PBA) est un MBR particulier (shadow MBR) qui contient une instance de sedutil permettant de déverrouiller le disque, pour ensuite pouvoir le démarrer.
Selon cette discussion, MBREnable = Y dit au disque de présenter ce shadow MBR lors du boot, alors que MBRDone = Y dit au disque de ne PLUS présenter ce shadow MBR.

Sous Debian

La gestion d’un disque OPAL sous Linux se fait avec l’utilitaire sedutil. C’est un utilitaire open-source, développée par la Drive Trust Alliance.
Il n’est, en 2021, pas disponible dans les dépôts Debian, et doit donc être téléchargé ou compilé depuis le lien ci-dessus.

Pour pouvoir gérer les disques SATA, il faut activer le paramètre allow_tpm du module libata. Pour le faire de manière permanente, il faut ajouter libata.allow_tpm=1 à /etc/default/grub (ligne GRUB_CMDLINE_LINUX_DEFAULT=), mettre à jour la config de GRUB et redémarrer.
Pour le faire de manière temporaire sans redémarrage du système, il semble qu’il faille écrire 1 dans le fichier /sys/module/libata/parameters/allow_tpm, mais je n’arrive pas à obtenir l’accès en écriture sur mon système.

Ceci ne semble pas nécessaire pour les disques NVMe. Par contre, il semble qu’il faille être root.

Utilisation de sedutil

Cet utilitaire nécessite souvent les droits root pour agir directement sur le périphérique.

Syntaxe

Codes d’erreur :

• NOT_AUTHORIZED : mauvais mot de passe
• AUTHORITY_LOCKED_OUT : trop d’essais infructueux, il faut éteindre/rallumer le disque

Lister les disques et leur support d’OPAL :

sudo sedutil-cli --scan
/dev/sda No -> Pas de support d’OPAL
/dev/sda 12 -> Support d’OPAL (“12” pour support de OPAL 1 et 2, “2” pour support d’OPAL 2 uniquement, il me semble)

Lister les détails d’un périphérique :

sudo ./sedutil-cli --query /dev/nvme0
On y voit notamment le statut de verrouillage (LockingEnabled) et de shadowing du MBR (MBREnabled) :

Locking function (0x0002)
    Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = Y, MediaEncrypt = Y

PSID revert - DÉTRUIT TOUTES LES DONNÉES SI VERROUILLAGE ACTIVÉ

Ceci va réinitialiser https://www.reddit.com/r/sysadmin/comments/9ogdnk/psid_revert_of_encrypted_ssd_not_possible/
sudo ./sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID PSIDPASSWORD /dev/sdX
sudo ./sedutil-cli --PSIDrevert PSIDPASSWORD /dev/sdX
Si le constructeur a mis des tirets dans le PSID, il faut les enlever (sinon on aura l’erreur “One or more header fields have 0 length”). Il doit faire 32 caractères de long.

Initialisation du chiffrement

sudo sedutil-cli --initialSetup mYpAsSwOrD /dev/sdX
Définit les mot de passe SID et Admin1 (avec le password fourni) (c’est le takeownership).
Active le shadowing de MBR.

Ceci équivaut aux suites de commandes (à vérifier) :

sudo ./sedutil-cli --takeOwnership mYpAsSwOrD /dev/sdX
# définit les password SID et Admin1

sudo ./sedutil-cli --activateLockingSP mYpAsSwOrD /dev/sdX
# active la possibilité de chiffrement ? (LockingEnabled)

sudo ./sedutil-cli --setMBREnable on mYpAsSwOrD /dev/sdX
#

On peut ensuite effectivement chiffrer le disque :
sudo ./sedutil-cli --enablelockingrange 0 mYpAsSwOrD /dev/sdX

Le disque devient ainsi non-lisible sans le mot de passe (y compris le MBR, il n’apparaîtra pas dans fdisk).
On voit “Locked = Y” lorsqu’on lance query

Déverrouillage d’un disque chiffré

sudo ./sedutil-cli --setlockingrange 0 rw mYpAsSwOrD /dev/sdX
Il redevient ainsi libible, y compris le MBR.
On peut également définir le volume en lecture seule :
sudo ./sedutil-cli --setlockingrange 0 ro mYpAsSwOrD /dev/sdX
ou le verrouiller :
sudo ./sedutil-cli --setlockingrange 0 lk mYpAsSwOrD /dev/sdX

Suppression du chiffrement

https://github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL

On peut désactiver le chiffrement SANS suppresion des données avec :
sudo ./sedutil-cli --revertnoerase mYpAsSwOrD /dev/sdX
(il faut avoir deverrouillé le disque avant, en RX ou RO, sinon erreur FAIL)

Un peu de lecture ici.

iotop

sudo apt install iotop
sudo iotop

Permet de voir, à la manière de top, l’activité I/O des disques par processus. Ne distingue toutefois pas sur quel disque l’activité se produit.

dstat

sudo apt install dstat
dstat pour avoir un aperçu général.
dstat -d -D total,sdk,md0 pour n’afficher que les infos relatives aux disques (-d), et surveiller l’ensemble des I/O dans une colonne (-D total), /dev/sdk dans un autre (-D sdk)et /dev/md0 dans une autre (-D md0).

iostat

sudo apt install sysstat
iostat pour avoir des infos générales depuis le boot.
iostat -y 1 2 pour avoir des infos uniquement dans l’intervalle temporel spécifié ; ici : 1s, analyse répétée 2 fois (1 2). Si le 2e chiffre n’est pas spécifié, l’analyse sera faite en boucle.
iostat -d pour n’inclure que l’info relative aux disques.
iostat -p sdk,md0 pour n’inclure que l’info relative à ces périphériques.
iostat -t pour inclure le timestamp

En cumulant ces options, et avec l’utilisation de watch, on tombe sur un truc comme ça :
watch -t -n 0.1 iostat -p sdk,md0 -d -t -y 1 1

nmon

sudo apt install nmon
nmon puis presser la touche d

https://support.apple.com/fr-fr/HT201255
https://support.apple.com/fr-fr/HT204904

Alt : Boot menu
⇧ : Mode sans échec
Super+S : Mode monoutilisateur (root en CLI)

Super+R : Récupération via partition de récup (OS actuel)
Alt+Super+R : Récupération via internet (OS le plus récent compatible)
⇧+Alt+Super+R : Récupération via internet (OS d’origine, ou le plus proche encore disponible sur les serveurs)

Alt+Super+P+R : reset PRAM
Alt+⇧+Ctrl : reset SMC

D : AHT
Alt+D : AHT via internet

Suite à un changement de carte-mère, et donc à un remplacement de la puce TPM dedans, il peut arriver d’avoir des messages d’erreur (notamment 0x80090016) à l’ouverture de session Windows, ou Outlook (ou autre ?).

Ceci semble lié au fait que les infos d’identification étaient chiffrées grâce à un jeu de clés situé matériellement dans la puce TPM.
Pour corriger ceci, il faut renommer le dossier

C:\users\%username%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy

en .OLD (ou le supprimer…). Puis fermer la session.

Les infos d’identification seront redemandées au prochain lancement de la session ou de l’appli (et, je suppose, chiffrées grace au nouveau jeu de clés de la nouvelle puce).

Source

Il semble que dans certains cas (visiblement en lien avec la protection par code PIN), la solution soit plutôt (ou aussi ?) de supprimer le contenu du dossier

C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc\

/sbin/ntfsresize --force --no-action -s 100G /dev/sdX1 | grep -e ERROR -e relocations

--force peut ne pas être nécessaire
-s indique la nouvelle taille de partition, par défaut en octets, et peut être suivi des suffixes k,M,G,ki,Mi ou Gi

On peut aussi

Avec 12 disques (a -> l)

for i in {a..l}; do echo sd$i; udevadm info --query=all --name=/dev/sd$i | grep ID_SERIAL_SHORT; done

Sous Linux, il arrive que, pour économiser de l’énergie, la carte son se mette en veille après quelques temps d’inactivité. Ceci génère chez moi des craquements assez désagréables lors de sa remise en fonctionemment, ou parfois un craquement très régulier tout le long de la veille.

Pour voir si la mise en veille est activée :

cat /sys/module/snd_hda_intel/parameters/power_save

S’il contient autre chose que 0, alors le mode powersave est activé.

Pour le désactiver, on peut ajouter le fichier /etc/modprobe.d/snd_disable_powersave.conf et entrer dedans la ligne suivante :

options snd_hda_intel power_save=0

Puis redémarrer, ou bien décharger/recharger le module.

Disques tous en spare

Après une panne d’éléctricité, un RAID6 de 12 disques (dégradé, avec 1 disque manquant) a refusé de se remettre en route. Après vérification (par live-cd) via un cat /proc/mdstat, les 11 disques étaient tous en spare (se manifeste par un [S] ).
Pour ce raid sont utilisées les 2e partitions de chaque disque de sda -> sdk. J’ai vérifié l’état de synchronisation de tous les volumes : sudo mdadm --examine /dev/sd[abcdefghijk]2 | grep Events

Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752

Ils sont bien synchronisés, mais pas assemblés. J’ai alors testé
sudo mdadm --assemble --force /dev/md126 /dev/sd[abcdefghijk]2
mais ai obtenu 11 jolis “Device or ressource busy”. Ce qui est normal, les disques étant intégrés dans le RAID, mais en spare. J’ai alors lancé
sudo mdadm --stop /dev/md126
suite à quoi la commande d’assemblage précédemment citée a bien fonctionné, le RAID s’est resynchronisé sans perdre de données, en prenant toutefois son temps.

RAID fonctionnel qui ne se synchronise pas tout seul

Dans un autre cas, où le RAID était resté fonctionnel mais dans lequel un volume manquait (sdl2, détecté mais non intégré/synchronisé), j’ai pu le réintégrer avec la commande sudo mdadm --re-add /dev/md126 /dev/sdl2 (si re-add ne fonctionne pas, add devrait fonctionner mais prendre plus de temps).

Dans encore un autre cas, un seul disque était intégré au RAID, mais non synchronisé, car il restait en “spare”. J’ai pu forcer la réintégration avec la commande
echo check > /sys/block/md126/md/sync_action
De la lecture intéressante se trouve sur cette page.

Ici aussi : https://robbat2.livejournal.com/231207.html?nojs=1

Exclure disque d’un raid

Il doit être marqué en failed ; soit par mdadm suite à erreur de lecture ou autre, soit manuellement par :

sudo mdadm /dev/mdX --fail /dev/sdX

Il peut alors être retiré :

sudo mdadm /dev/mdX --remove /dev/sdX

Suite à quelques soucis de recherche dans la base CDDB avec Asunder, voici un mini-tuto pour abcde. Déjà,

sudo apt install abcde lame eyed3 glyrc imagemagick cdparanoia

Les préférences d’extraction se définissent dans le fichier /etc/abcde.conf ou bien dans un fichier user qui outrepassera le précédent, et que nous éditons ici : pluma ~/.abcde.conf

# VBR bonne qualité
LAMEOPTS='-V 0'
# On extrait la couverture
ACTIONS=default,getalbumart
# On range les fichiers finaux dans ce dossier :
OUTPUTDIR="/path/to/music/dir"
# On encode en mp3
OUTPUTTYPE=mp3
# Arborescence type Artiste/Album/01 - Morceau.mp3
OUTPUTFORMAT='${ARTISTFILE}/${ALBUMFILE}/${TRACKNUM} - ${TRACKFILE}'
# On ne remplace PAS les espaces par des underscores (et autres modifs)
mungefilename ()
{
echo "$@"
}

On peut ensuite lancer abcde ou encore abcde -d /dev/sr1 si on spécifie manuellement le lecteur CD.

Enfin, dans le dossier final, si on souhaite intégrer la pochette au fichier :

for i in *.mp3
do
eyeD3 --add-image cover.jpg:FRONT_COVER "$i"
done

(cf cette page)

Habituellement, lorsque je souhaite installer une Debian sur un pc avec double carte graphique Intel-Nvidia (système Optimus), il suffit d’installer bumblebee via apt install bumblebee bumblebee-nvidia (ou simplement bumblebee si on souhaite essayer avec les pilotes libres Nouveau, ce qui m’a semblé fonctionner moins souvent).
La configuration des paquets met en place toute la configuration nécessaire (glx, alternatives, modprobe/blacklist etc). Ceci installe également un module noyau bbswitch, dont le but est d’éteindre ou d’allumer à la demande la carte graphique dédiée.

Cependant, sur un poste, après avoir installé ces paquets, le pc freezait au démarrage, que le pilote soit nouveau ou nvidia. Comme le pc démarrait correctement en mode recovery, j’ai désactivé le lancement automatique du gestionnaire de connexion graphique. Ainsi, le pc démarrait correctement, je pouvais me connecter, mais dès le moindre service lightdm start ou startx, il freezait à nouveau. Après pas mal de lecture, j’ai appris que le fichier /proc/acpi/bbswitch contenait entre autre l’état de la carte graphique (ON ou OFF), et que la commande tee /proc/acpi/bbswitch <<<ON permettait de l’allumer à la demande.
Et j’ai constaté que la carte était en OFF à chaque démarrage, que si on essayait de lancer un programme graphique (même une interface graphique qui tourne sur la carte intégrée au CPU) alors que la carte dédiée était OFF, alors ça freezait. Si par contre on allumait manuellement la carte avant, on pouvait lancer l’interface, et ensuite ça fonctionnait, même si la carte était coupée. Mais si on souhaitait simplement se déconnecter, comme ceci coupe puis relance l’interface graphique, alors ça freezait à nouveau…

Mais avec le détail des cas où ca plantait, j’ai facilement trouvé ce rapport de bug, et après moult tests, modifier la ligne dans le fichier /etc/default/grub pour qu’elle ressemble à ceci :

GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi='Windows 2009'"

suivi d’un update-grub a bien fonctionné ! Les graphiques standards sont bien lancés sur le gpu intégré, le gpu dédié est éteint la plupart du temps, allumé correctement lorsqu’on lance un programme avec optirun, et bien éteint lorsque ce programme se termine.