Les petites infos – Spécial NVMe
Suivre les avancées technologiques est particulièrement difficile, je suis sysadmin et pourtant souvent largué. Ce n’est pas qu’il est difficile de comprendre une nouvelle techno, de prendre en main du nouveau matos. Avant tout la difficulté se situe autour de cette nouveauté : Nouveau paradigme, fonctionnement différent, nouveaux outils pour l’utiliser.
On va partir du NVMe. Techno matérielle récente et bas niveau (disque), certains en ont déjà sur leur pc, les hébergeurs web y passent massivement quand ce n’est pas déjà fait. Mon but étant qu’à la fin de cet article, vous ayez appris quelque chose même si vous pensiez tout savoir dessus.
Je vais donner beaucoup de liens sinon l’article serait infiniment trop long, il s’agit aussi du concept des petites infos (faire passer l’info sans aller trop loin). Libre à vous de creuser, d’apprendre. Sans suivre et lire ces liens, il est illusoire de prétendre connaître le sujet.
Bases et bas niveau
On commence simple : Tout savoir sur le NVMe.
Première difficulté il vous faudra un BIOS UEFI. L’info ne ressort pas de manière « importante » je trouve, il faut le savoir. Un BIOS classique ne prend pas en charge NVMe. Enfin… on peut bidouiller : Utiliser un SSD NVMe avec Linux, même sur un vieux serveur.
Sur les serveurs que j’utilise au boulot le BIOS est en mode Legacy, il faudra le passer en mode UEFI pour « booter » les disques NVMe. Vous avez là mon problème du moment, pour installer un serveur je dois aller modifier une option du BIOS systématiquement. Aucune autre solution, nous sommes en 2020. Il existe des outils fournis par le constructeur pour récupérer la configuration du BIOS et injecter la conf (modifiée) qu’on désire. Option soumise à une licence payante (pour chaque node/serveur)… LOL.
Une chose que vous ne savez probablement pas, on peut se passer de GRUB avec l’UEFI. L’avantage principal est que le démarrage (boot) va plus vite, le désavantage est que vous n’avez pas toutes les options et raffinements que vous amène GRUB. Déjà rappelons la différence entre Boot loaders et Boot managers (en Anglais). L’EFISTUB (ou EFI Boot Stub) est un boot loader intégré au noyau depuis la version 3.3.0. Je vous conseille la lecture chez Arch et celle chez Debian en Anglais (la famille ha ha ha). Enfin voici un article en Français sur Void Linux qui vous en apprendra davantage sur comment s’y prendre avec efibootmgr ainsi que Full disk encryption, dualboot et LVM.
Le lecteur pourrait se demander comment on part du NVMe et on en arrive à causer UEFI. Voilà ce que j’appelle autour. Naturellement en faisant le point sur une nouvelle techno, on fait le point sur beaucoup d’autres choses qui ont évolué ou qui sont arrivées avec. En tant que sysadmin je vais notamment m’interroger : Dois-je continuer à utiliser GRUB ou passer directement par EFISTUB ? Mais du coup pourquoi les distribs continuent à utiliser/proposer GRUB quand l’EFISTUB fait le job de boot (un début de réponse en Anglais) ?
nvme-cli
On vient de boucler la partie bas niveau, comment je récupère des infos dessus ? nvme-cli. Un petit sudo apt install nvme-cli plus tard, on liste les disques NVMe avec sudo nvme list et on récupère des infos intéressantes (genre température, warning, power cycles/hours…) avec sudo nvme smart-log /dev/nvme0. Pour connaître modèle, numéro de série et d’autres trucs très pointus : sudo nvme id-ctrl -H /dev/nvme0.
Vous avez toujours rien appris ? Bon attendez je sors mon joker.
Chiffrement
Le chiffrement est un sujet qui deviendra de plus en plus important pour protéger les données, la confidentialité et vie privée. En tant qu’utilisateur de Debian/Linux/NVMe je me demande : Au fait le chiffrement matériel avec les disques NVMe ?
Aujourd’hui on chiffre nos disques avec cryptsetup ou /home avec ecryptfs, du chiffrement logiciel. Le chiffrement matériel n’est pas encore grand public mais va tendre à le devenir avec les disques NVMe. Cette technologie de disques grand public étant la plus récente, elle amène de nouvelles spécifications/options dont TCG Opal, vous en apprendrez davantage avec What are Opal 2.0-Compliant SEDs ? et TCG OPAL et disques SED.
SED signifie Self-Encrypting Drives, il vous faut absolument lire l’article en Anglais sur ArchWiki pour comprendre les bases, les avantages et inconvénients de ces self-encrypting drives.
L’outillage s’appelle sedutil et vous trouverez ici comment chiffrer votre disque. Préalablement il vous faudra vérifier si votre SSD NVMe est pris en charge, deux moyens disponibles : Préparer un média bootable ou compiler sedutil. J’ai testé les 2, je vous donne le second.
sudo apt -y install autoconf build-essential g++ wget https://github.com/Drive-Trust-Alliance/sedutil/archive/master.zip unzip master.zip && cd sedutil-master/ autoreconf -i ./configure make sudo nano /etc/default/grub # Ajouter libata.allow_tpm=1 ce qui donnera en gros GRUB_CMDLINE_LINUX_DEFAULT="quiet splash libata.allow_tpm=1" sudo update-grub sudo reboot cd sedutil-master/ sudo ./sedutil-cli --scan
Voici le retour sur mon pc fixe (Verify that your drive has a 2 in the second column indicating OPAL 2 support).
sudo ./sedutil-cli --scan Scanning for Opal compliant disks /dev/nvme0 2 Samsung SSD 960 EVO 250GB 3B7EDFV7 /dev/sda 12 Samsung SSD 850 PRO 256GB EXM4JLPQ /dev/sdb No ST2000DM006-2DM164 CD45 No more disks present ending scan
À l’heure actuelle je me suis arrêté là et je vais vous dire le fond de ma pensée sur sedutil et le chiffrement matériel des SSD :
- Je vous invite à lire cette issue : Pas de commit depuis 2 ans, en gros on fournit à la communauté une implémentation de référence et on communique dessus ensuite démerdez-vous. Quelques devs ont proposé des évolutions/corrections, à titre personnel mon ressenti est que ça part dans tous les sens et que ça n’a pas été assez « incubé »
- Exemple le site https://sedutil.com/ on pourrait se dire que ça vient de l’implémentation de référence mais non, un des devs (https://github.com/ChubbyAnt/sedutil) a pris le nom de domaine et propose son implémentation/outil
- On parle de chiffrer la totalité de son disque avec une solution basique / peu maintenue, mon radar à bullshit me dit on va attendre de voir comment ça évolue et les premiers retours « en prod »
- Encrypting Your Ubuntu Operating System Using a SED Hard Drive chez Dell, le genre d’indices montrant que les industriels commencent à soutenir ces outils
- SSD : des failles permettent de contourner le chiffrement du disque (11/2018)
- Pour résumer je surveille cela de près car entre chiffrement matériel et logiciel, je signe de suite pour le matériel avec un minimum de garanties : Fiabilité, projet maintenu avec une bonne visibilité, sécurité…
On a fait un bon tour, j’ai testé une autre façon d’écrire, j’espère que vous avez apprécié mais surtout appris des choses. Je réponds aux questions dans les commentaires.
Tcho !
Déjà 13 avis pertinents dans Les petites infos – Spécial NVMe
Les commentaires sont fermés.
Ça ne m’étonne pas mais merci d’avoir remonté l’info.
Tcho !
La partie chiffrement de mon article concerne la sphère privée et non professionnelle. Sinon pour le reste je comptais en parler plus tard mais tu sais que je suis toujours très lent ^^ :
https://www.journalduhacker.net/s/mvknxe/stockage_chiffr_int_gral_sur_serveur
https://blog.tetsumaki.net/articles/2019/02/installation-de-void-linux-chiffre-sur-un-serveur-distant.html
https://www.tictech.info/post/ssh_dmcrypt_remote
https://github.com/slashbeast/better-initramfs
Je ne sais pas si ça répond à tes questions ou si j’ai mal compris, tu me diras.
Tcho !
Pour chiffrer sous Linux, quelle est la solution la plus fiable et la plus efficace ?
1/ Chiffrer la partition nativement
2/ Utiliser VeraCrypt
Devrait-on utiliser VeraCrypt pour chiffrer les médias externes, et le chiffrement « natif » pour les médias internes ?
Personnellement (sans doute suis-je « un peu » paranoïde), je ne suis pas du tout convaincu par le chiffrement matériel au niveau du disque, tant au niveau de la fiabilité (récupération des données en cas de problème) que de la sécurité (gestion des failles et des patches associés).
par contre concernant Grub , il y a un souci dans les différentes distributions :
chacune a développé depuis sa propre version , avec le souci du multifichiers au démarrage ( cas manjaro on démarre avec le microcode )
==> quasi aucune autre distribution sous grub ne parvient a démarrer avec le microcode , cause
dernière version utilisé 2.02 ( cad au mois plus de 3 a 5 ans )
je ne parle pas non plus des différents grub , grub-customiser , et les autres variantes
pourtant à la base le grub ( voir gnu savannah le git ) est bien pour plusieurs architectures , mais les outils proposés pour tests – debuggages sont quasi nuls
à cela se greffe
– la gestion lvm
– la gestion des raids mdadm
– la gestion de btrfs
– cas de démarrage root zfs
J’utilisais TrueCrypt/VeraCrypt du temps où j’étais sur Windows, excellent outil, VeraCrypt a été audité en 2016 en plus.
Le truc c’est que d’après ce que je sais VeraCrypt n’est pas dans les dépôts Debian/Ubuntu par exemple donc plus simple/direct de passer par ecryptfs/cryptsetup pour chiffrer. De plus lors de l’installation sur Ubuntu/Mint une simple case à cocher permet de chiffrer /home avec ecryptfs, pareil si tu passes par LVM tu peux chiffrer un volume donc c’est plus simple de passer par les outils fournis direct.
Niveau fiabilité je ne saurais dire, en tout cas je mets ecryptfs dans les outils très moyens, je l’utilise mais je ne le recommande pas. Des bugs, des limitations dont j’ai parlé dans d’autres articles précédemment.
Pour répondre à ta question je passerai par cryptsetup pour une partition entière, ecryptfs pour /home car sur Ubuntu/Mint c’est une case à cocher à l’install, VeraCrypt pour les médias externes. Je connais et j’ai vu peu de gens utiliser VeraCrypt sur Linux.
Tcho !
2nde remarque: sur le chiffrement logiciel et le chiffrement matériel. Personnellement j’ai une très mauvaise expérience du RAID matériel et pseudo matériel (avec un blob exécuté par le CPU). L’implémentation est fermée, le code n’est pas toujours maintenu, en cas de mise à jour il arrive que l’on perde le contenu parce que cela entraine des changements de structure. J’ai bien plus confiance dans le code du kernel que dans celui d’un obscure sous traitant d’un fabriquant de matériel qui sera passé à autre chose au bout de 6 mois. En cas de problème avec du RAID, on perds les données, mais là, on ajoute un problème de sécurité. En ce moment, le chiffrement fait l’objet de beaucoup d’attaques, les implémentations sont rarement irréprochables, quand on ne découvre pas carrément des défauts conceptuels.
Par contre les utilisateurs peu expérimentés ne rencontrent généralement aucun problème.
Les raisons ? Ces « pros » assument que toutes les distributions utilisent GRUB. La doc c’est un machin pour les n00bs donc c’est pas pour eux. Conclusion, ils vont gueuler, dire que les devs sont nuls et que cette distro c’est de la m**de.
J’imagine que c’est aussi une des raisons pour lesquelles GRUB reste souvent utiliser même avec l’UEFI.
Tcho !
Merci à toi pour la qualité de tes articles, dommage que tu n’en écrives pas davantage ^^
Tcho !
Il y a cependant des inconvénients lors de la mise à jour de l’initramfs, et ce n’est pas si full encryption disk puisque que le kernel et l’initramfs ne sont pas chiffrés.