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.

Voici le retour sur mon pc fixe (Verify that your drive has a 2 in the second column indicating OPAL 2 support).

À 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à 12 avis pertinents dans Les petites infos – Spécial NVMe

  • Sytoka
    Le chiffrement matériel est pour le moment déconseillé dans l’enseignement supérieur et la recherche française. Il y a trop de bogues ! Si on souhaite chiffré (obligatoire chez nous), il faut absolument utiliser cryptsetup et luks.
  • Lord
    Quel est l’intéret de chiffrer un disque d’un serveur ? Par définition, il sera déchiffré tout le temps sauf lorsqu’il est éteint. En cas de reboot, il faudra un admin présent avec le pass pour déchiffrer…
  • mmu_man
    Il existe des « hardware security module » (HSM) qui permettent de délivrer les clefs aux machines sous certaines conditions (typiquement que la baie n’ait pas été ouverte, …), et qui oublient la clef sinon, ce qui permet d’éviter de la rentrer pour un simple reboot.
  • Erwann
    Question de « candide » en particulier pour des laptops et stations de travail :
    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).

  • stephane
    côté manjaro souvent le disque nmve n’est pas reconnu ( pas de UUID ! ), on tente de le mettre sous gestion disque ahci (version Efi) pour qu’il soit reconnu ,car la plupart du temps il est mis en mode raid.

    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

  • skc
    1ère remarque: sur le boot. J’insiste sur l’importance du second lien « … même sur un vieux serveur ». Sous Linux, on a l’avantage que la partie boot de la machine soit très bien identifiée (/boot). La machine démarre avec un kernel et un ramdisk copié en mémoire. Une fois que ceux-ci ont démarrés, tous les drivers et toutes les ressources deviennent exploitables. Cela permet d’installer le système sur un disque NVMe même sur une machine qui n’est pas capable de booter sur du NVMe, simplement en installant /boot sur un support accessible pour booter. Les utilisateurs de windows ont peut-être plus de difficulté de ce coté.

    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.

  • Pierre
    Chez Solus (dont le temps de boot est un de chevaux de bataille) on a jamais utilisé GRUB en UEFI et ce que j’observe, c’est que certains utilisateurs qui se disent « pro » qui ont déjà installé des dizaines d’autres distributions sans problèmes poussent des gueulantes parce que ça ne marche pas…

    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.

  • Hello ! Les bios legacy sont compatibles NVMe avec 100% des performances. Mais ils ne peuvent pas booter dessus à moins de bidouiller comme tu dis, et c’est ce que j’explique dans mon article (merci pour la citation).
    Tcho !

Laisser un commentaire

indique des champs obligatoire.