Installer un Ubuntu chiffré avec LUKS, LVM et un partitionnement personnalisé
Imaginons que pour une raison quelconque – j’en donnerai quelques exemples au début du tutoriel – vous voulez installer votre Ubuntu sur une partition chiffrée. Le plus simple est de sélectionner l’option prévue à cet effet dans l’installeur officiel. Oui, mais voilà, cette option a deux inconvénients :
- Elle utilise tout le disque, sans laisser de possibilité de conserver un autre système d’exploitation en parallèle ;
- Elle impose son propre plan de partitionnement, qui est discutable (pas de partition
/homeséparée par exemple).
Ce tutoriel assez technique va vous montrer comment passer outre ces limitations, et ce avec un média d’installation standard1 de la variante que vous voulez d’Ubuntu (testé avec Ubuntu 16.04 LTS), probablement Linux Mint, et peut-être même encore d’autres (n’hésitez pas à partager vos retours en commentaires).
Prérequis : on va parler technique. Donc, je considère que les notions de partitionnement et les règles de nommage des disques sous Linux vous sont acquises. Je suppose aussi que vous n’avez pas peur de la ligne de commande et que vous avez une idée de ce que sont LVM et chroot.
Le tutoriel est un peu long, mais tout est détaillé. Comptez dix à quinze minutes en plus d’une installation normale, plus plusieurs heures d’initialisation des disques, pendant lesquels vous pouvez faire autre chose.
-
On trouve un certain nombre de ressources, en particulier en français, qui mentionnent l’utilisation du média d’installation alternate qui n’existe plus depuis un petit moment…
↩
- Important : pour Ubuntu 18.04 et suivants
- Pourquoi chiffrer son disque dur avec de telles contraintes ?
- Préparer les partitions et installer le système
- Permettre au système de démarrer
- Sûreté, vérifications et performances
Important : pour Ubuntu 18.04 et suivants
Ce tutoriel est obsolète et ne permet plus d’installer Ubuntu 18.04 selon la méthode décrite, même avec des adaptations simples.
De plus, l’installateur d’Ubuntu n’oblige plus à écraser tout le disque pour faire une installation chiffrée tant qu’on installe Ubuntu sur une seule partition.
Donc, si vous désirez installer Ubuntu selon ce tutoriel, deux possibilité s’offrent à vous :
- Soit vous utilisez le système intégré à l’installeur, cf ci-dessous pour les détails,
- Soit vous voulez vraiment quelque chose de plus poussé, auquel cas je vous renvoie vers ce sujet de discussion.
Pour installer Ubuntu 18.04 ou supérieure sur une seule partition sans écraser tout le disque
- Lancez la procédure d’installation normale.
- Au moment de choisir le partitionnement, choisissez « Autre chose ».
- Créez une partition de boot, indispensable (1 Go, ext4, montée sur
/boot)1. - Créez votre partition, et choisissez « Utiliser comme : volume physique pour chiffrement ».
- Ubuntu va vous créer une partition chiffrée. Pensez à écraser tout le disque, toute la sécurité repose là-dessus !
- Vous avez maintenant une nouvelle partition
/dev/mapper/sdaX_cryptau format ext4 il vous suffit de la sélectionner comme partition racine/et de lancer l’installation normalement.
-
Il semblerait qu’il soit possible de chiffrer aussi
↩/bootmais l’installeur d’Ubuntu ne le permet pas.
Pourquoi chiffrer son disque dur avec de telles contraintes ?
Pourquoi chiffrer son disque dur ?
Sur un ordinateur fixe, cela ne sert probablement à rien — ou alors vous travaillez sur des données si sensibles que vos disques sont déjà chiffrés.
Le cas d’un ordinateur portable est plus intéressant, parce que vous pouvez le perdre ou vous le faire voler. Or, même si la personne qui récupèrera votre ordinateur n’en fera rien directement, il est très facile de récupérer les données d’un disque qui n’a pas été effacé exprès dans ce but1. Or, qui sait dans quelles mains vont tomber ces données et ce qui va en être fait par exemple ? Quelqu’un de mal intentionné peut tirer des informations intéressantes et un bon prix de données aussi fréquentes sur un disque dur de particulier qu’un scan de carte d’identité ou de passeport, d’informations bancaires, de relevés de comptes, de billets pour un long voyage à l’étranger.
Dans le cas de votre ordinateur professionnel, c’est encore mieux : accès aux comptes de l’entreprise, espionnage industriel, etc.
Je conseille à ce sujet la lecture du dossier du Canard PC Hardware n° 23 (article payant), où les auteurs montrent par l’exemple ce qu’on peut réellement lire sur un disque dur d’occasion et ce qu’on peut en faire.
Le moyen le plus sûr pour éviter de subir des désagréments2 autres que la simple perte de votre ordinateur, c’est donc de chiffrer vos données : toute personne qui récupèrerait le disque dur se retrouverait face à un bloc de données pseudoaléatoires et surtout inutiles sans la clé ad hoc.
De quelle manière chiffrer son disque dur ?
Je mets de côté les disques et ordinateurs à chiffrement intégré matériel. D’une part parce que si vous en avez un, normalement vous le savez déjà ; et deuxièmement parce que ce ne sont pas des solutions disponibles partout, surtout lorsqu’on veut chiffrer un disque interne.
Vous pouvez simplement chiffrer votre home sous Linux, il y a pléthore d’outils pour ça. Mais si des données se retrouvent hors de votre home ? Dans les fichiers temporaires par exemple, dans la partition de swap, dans les logs, n’importe où sauf là où vous l’aviez prévu ?
Une solution est alors de chiffrer l’intégralité de son disque dur, et c’est ce que nous allons faire dans ce tutoriel.
Quoique… pas tout à fait en réalité : Linux est incapable de démarrer si les informations de démarrage sont chiffrées (dit comme ça, ça parait assez logique). Donc, /boot sera monté sur une partition séparée qui ne sera pas chiffrée. L’intégralité du reste du disque sera chiffrée, éventuelle partition swap comprise.
C’est ce que propose Ubuntu lorsqu’on choisit, à l’installation, l’option de chiffrement du disque dur. Mais comme déjà évoquée en introduction, cette option a deux inconvénients :
- Elle écrase l’intégralité du disque dur : adieu, autres systèmes !
-
Elle vous impose un plan de partitionnement assez étrange :
- 1 Go pour la partition EFI ,
- 1 Go pour la partition de boot,
- Et surtout le reste en partition racine (pas de possibilité de séparer votre home par exemple).
LVM dans LUKS, ou LUKS dans LVM ?
Pour commencer, un rapide rappel de qui est qui :
- LVM est une méthode de gestion de l’espace de stockage, beaucoup plus souple que de simples partitions.
- LUKS est le standard de chiffrement du noyau Linux ; utilisé avec dm-crypt (son utilisation normale), il permet d’obtenir des périphériques de type bloc utilisables normalement, alors qu’ils sont chiffés de manière transparente.
On pourrait imaginer deux montages :
- une grosse partition LUKS découpée comme on veut avec LVM ;
- un découpage LVM dans lequel on chiffrerait les partitions avec LUKS.
Le premier montage rend le redimensionnement de la partition chiffrée ou l’ajout de disque au système LVM assez délicat, mais ne nécessite qu’un mot de passe pour déverrouiller l’intégralité du système, puisqu’il n’y a qu’une partition LUKS.
Le second est plus souple, mais nécessite de saisir un mot de passe par partition. C’est l’option proposée par défaut dans l’installeur d’Ubuntu 18.04 quand on sélectionne « Volume physique pour chiffrement » dans le menu « Utiliser comme : » d’une partition.
Comme sur un ordinateur portable intégralement chiffré, les deux inconvénients de la première solution sont des cas pathologiques, nous allons utiliser une grosse partition LUKS découpée comme on veut avec LVM.
Bien. Maintenant qu’on sait ce qu’on veut, comment l’obtenir ?
-
Un simple reformatage, par exemple, permet généralement la récupération de toutes les données en quelques minutes. Effacer physiquement les données d’un disque dur magnétique nécessite de réécrire l’intégralité des données, plusieurs fois avec des valeurs aléatoires – ce qui peut être donc très long.
↩ -
En vrac : usurpation d’identité, cambriolage ciblé en votre absence, utilisation frauduleuse de votre compte bancaire, fuite des informations de votre entreprise à un concurrent, apparition soudaine de vos photos intimes sur des sites publics…
↩
Préparer les partitions et installer le système
Hypothèses, cible et préparation
Je pars du principe que vous faites ça avec un système moderne en 2016, donc avec un démarrage en UEFI et un disque dur au format GPT. Si ce n’est pas le cas pour vous, à vous de faire les adaptations nécessaires.
Le partitionnement cible est le suivant :
← Début du disque | |||
Partition EFI
| Partition de démarrage
| Partition chiffrée LUKS | (Autres partitions si autres OS) |
Volume physique LVM | |||
Montages arbitraires dont au moins | |||
Sauvegardez toutes vos données !
L’un des principes de cette installation est précisément de détruire de manière irrémédiable toute donnée qui se trouverait sur la partition chiffrée !
Les exemples seront donnés pour un disque intégralement dédié à un seul OS installé, à vous de les adapter à votre configuration réelle !
Démarrage et création des partitions
Démarrez le CD d’installation d’Ubuntu en mode « Essai sans installation ».
En effet, on va avoir besoin de faire quelques réglages avant de lancer la procédure d’installation elle-même…
Configurez votre mapping clavier dans les paramètres de la session live-CD.
La ligne de commande va être nécessaire, tout comme la saisie de mots de passe longs – autant le faire avec un mapping clavier que l’on connait. À noter qu’il faut aller dans « Autres » pour trouver le Français. L’installation de packs de langues ne sert à rien par contre.
Configurez vos partitions à l’aide de votre gestionnaire préféré, par exemple GParted. Pour l’exemple, le partitionnement sera le suivant :
| Partition | Système de fichier | Taille | Commentaire |
|---|---|---|---|
/dev/sda1 |
EFI | 1 Go | Doit avoir le flag « bootable ». 50 Mo suffisent sans doute si vous n’avez que Linux. |
/dev/sda2 |
ext4 | 1 Go | Évitez de descendre sous les 500 Mo, ça peut poser problème aux mises à jour. |
/dev/sda3 |
Aucun | Le reste du disque | On va la formater ensuite. |
Création d’une partition chiffrée LUKS
On va commencer par formater au format LUKS la partition qu’on a laissée sans système de fichier tout à l’heure :
$ sudo cryptsetup luksFormat /dev/sda3
La commande va vous demander un mot de passe : il doit être le plus long et complexe possible : toute la sécurité de vos données repose dessus ! Seize (16) caractères semblent un minimum selon l’ANSSI, avec bien entendu majuscules, minuscules, chiffres et caractères exotiques. Oh, et vous devrez le taper à chaque démarrage.
Il faut ensuite ouvrir ce conteneur LUKS et lui donner un nom pour pouvoir l’utiliser, ce qui se fait avec la commande :
$ sudo cryptsetup luksOpen /dev/sda3 hdcrypt
Où hdcrypt est un nom arbitraire. Cette commande va créer un périphérique déchiffré, accessible en mode bloc, dans /dev/mapper/hdcrypt (ou tout autre nom que vous aurez choisi bien sûr.
L’étape suivante n’est pas strictement indispensable, mais est nécessaire à une vraie sécurité !
Les plus observateurs auront remarqué que l’étape de création du conteneur LUKS est très rapide, c’est parce que le système se contente de créer les entêtes et métadonnées qui vont bien. Le reste de votre disque est conservé en l’état. Conséquence : c’est facile de connaitre au moins la taille des données contenues dans votre partition chiffrée – et bien plus si les blocs ne sont pas utilisés de manière contigüe.
Pour éviter ça, on va écrire des données aléatoires sur l’intégralité du conteneur chiffré ; ainsi de l’extérieur, impossible de savoir ce qui est des données ou ce qui est de l’espace libre !
Attention !
- Plus aucune récupération de vos données n’est possible après cette étape.
- Cette opération écrit sur l’intégralité de votre disque chiffré, elle peut donc être très longue. Je parle d’heures entières, là !
On va écrire des zéros (qui seront chiffrés) sur l’ensemble du conteneur par blocs de 16 Mio :
$ sudo dd if=/dev/zero of=/dev/mapper/hdcrypt bs=16M status=progress
Ubuntu 16.04 ne gère pas encore l’option status=progress de la commande dd. Si vous voulez suivre l’avancement, ça peut se faire à l’aide de la commande pv :
$ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc) universe"
$ sudo apt-get install -y pv
$ sudo sh -c ’exec pv -tprebB 16 m /dev/zero >"$1"' _ /dev/mapper/hdcrypt
Création des volumes LVM
Notre conteneur chiffré avec LUKS est prêt, mais est à ce moment aussi inutile qu’un disque dur non formaté. On va donc le partitionner avec LVM :
On commence par créer un volume physique dans le conteneur, puis un groupe nommé vgcrypt (là aussi, c’est un nom arbitraire) dans ce volume physique :
$ sudo pvcreate /dev/mapper/hdcrypt
$ sudo vgcreate vgcrypt /dev/mapper/hdcrypt
On va maintenant créer nos partitions (des volumes logiques) au sein du groupe. Tous les noms sont arbitraires et les tailles sont à adapter à ce que vous voulez faire :
$ sudo lvcreate -n lvroot -L 32g vgcrypt
$ sudo lvcreate -n lvswap -L 4g vgcrypt
$ sudo lvcreate -n lvhome -l 100%FREE vgcrypt
Et enfin, on crée des systèmes de fichier dans nos volumes logiques ! Ici, j’utilise ext4, mais bien entendu vous utilisez autre chose si vous le souhaitez.
$ sudo mkfs.ext4 /dev/mapper/vgcrypt-lvroot
$ sudo mkfs.ext4 /dev/mapper/vgcrypt-lvhome
$ sudo mkswap /dev/mapper/vgcrypt-lvswap
Et on a enfin des partitions utilisables !
Installation du système
Lancez l’installeur graphique, et installez le système normalement. Vérifiez simplement les trois points suivants :
- Indiquez vouloir utiliser un partitionnement personnalisé, et utilisez les partitions que vous venez de créer. N’oubliez pas de monter
/bootsur sa partition ! - Vérifiez bien que le mapping clavier utilisé est bien celui que vous avez utilisé au moment de créer le conteneur LUKS, sans quoi vous risquez d’avoir des surprises au démarrage.
- Ce n’est pas la peine d’activer le chiffrement de la home de l’utilisateur, elle est déjà sur une partition chiffrée.
Laissez votre installation se terminer tranquillou, et…
… ne redémarrez surtout pas ! L’installeur standard ne comprends pas ce qu’on a fait avec les partitions et a laissé le système dans un état qui ne démarre pas !
*[OS] : Système d’Exploitation
Permettre au système de démarrer
Ainsi donc, on a un système installé tout bien comme il faut sur de belles partitions chiffrées… sauf que l’installeur n’a pas compris ce qu’on a fait, parce qu’il ne sait pas que la partition LUKS est chiffrée – et donc qu’il faut la déchiffrer pour pouvoir démarrer le système, et donc qu’il faut demander le mot de passe à l’utilisateur.
Fermez donc l’installeur graphique et lancez un terminal, on va réparer tout ça !
En cas de problème suite à une mise à jour, vous pourrez probablement vous contenter de rejouer cette partie, sans tout réinstaller.
Résumé des opérations et préparation
Il manque tout simplement les configurations qui permettent de dire au processus de démarrage du noyau que la racine est montée sur une partition chiffrée via LUKS, et donc qu’il faut demander le mot de passe à l’utilisateur, déverrouiller la partition et monter les volumes LVM avant de pouvoir continuer.
On va donc monter notre installation dans un chroot, ajouter les configurations manquantes et régénérer les processus de démarrage.
Pour ça, on va avoir besoin de l’UUID de la partition physique dans laquelle on a créé le volume LUKS – parce que rien ne garantit que le numéro de partition sera le même à chaque redémarrage, surtout si un disque externe est branché à ce moment-là :
$ sudo blkid /dev/sda3
/dev/sda3 : UUID="e4047e9c-f858-4301-bbcd-a02bf85e20d5" TYPE="crypto_LUKS" PARTUUID="3c78487a-3b29-4a35-8192-2aca523a6688"
Notez bien le UUID et pas le PARTUUID !
Montage des partitions et chroot
On va tout monter dans /mnt parce que le dossier est déjà là et que c’est court à taper – utilisez un autre dossier si vous voulez. La principale difficulté est de ne pas oublier un point de montage, et de ne pas se tromper dans l’ordre (racine puis partition de boot puis partition EFI) :
$ sudo mount /dev/mapper/vgcrypt-lvoot /mnt
$ sudo mount /dev/sda2 /mnt/boot
$ sudo mount /dev/sda1 /mnt/boot/efi
$ sudo mount /dev/mapper/vgcrypt-lvhome /mnt/home
$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /sys /mnt/sys
$ sudo chroot /mnt
Gestion de la partition chiffrée par le noyau
Déclaration du volume chiffré
Dans l’environnement chrooté, créez le fichier /etc/crypttab avec le contenu suivant. Évidemment, il faut que vous y mettiez l’UUID de votre partition LUKS, son nom et le nom de votre volume LVM.
Ce fichier déclare la partition chiffrée (à l’aide de son nom et de l’UUID de la partition cible), indique qu’il n’y a pas de fichier clé pour la déchiffrer (et donc qu’il faudra demander le mot de passe à l’utilisateur). Les options indiquent que le chiffrement est fait avec LUKS, qu’en cas d’échec on peut réessayer et que cette partition utilise le volume LVM précédemment créé.
# <target name> <source device> <key file> <options>
hdcrypt UUID=e4047e9c-f858-4301-bbcd-a02bf85e20d5 none luks,retry=1,lvm=vgcrypt
Déclaration de la racine chiffrée pour le noyau
Toujours dans l’environnement chrooté, créez le fichier /etc/initramfs-tools/conf.d/cryptroot avec ce contenu – comme d’habitude, à adapter selon vos valeurs :
CRYPTROOT=target=hdcrypt,source=/dev/disk/by-uuid/e4047e9c-f858-4301-bbcd-a02bf85e20d5
Régénération des images de démarrage
La commande suivante, toujours à lancer dans l’environnement chrooté, permet de régénérer une nouvelle image de démarrage (paramètre -c) pour toutes les versions du noyau Linux installées (paramètre -k all).
# update-initramfs -k all -c
Et voilà ! On a des images de démarrage et un noyau qui savent comment démarrer le système chiffré mis en place !
Mais ça ne suffit toujours pas ! Parce que le chargeur de démarrage (GRUB), lui, ne sait toujours pas que la partition racine est chiffrée !
Indiquer au chargeur de démarrage que la partition racine est chiffrée
Encore et toujours dans le chroot, éditez le fichier /etc/default/grub, et trouvez la ligne de configuration des arguments à passer au noyau Linux :
GRUB_CMDLINE_LINUX=""
Modifiez-la avec vos valeurs pour qu’elle ressemble à ceci. Vous devez comprendre le principe à force : on déclare le disque chiffré via son nom et son UUID, ainsi que le volume LVM à utiliser.
GRUB_CMDLINE_LINUX="cryptopts=target=hdcrypt,source=/dev/disk/by-uuid/e4047e9c-f858-4301-bbcd-a02bf85e20d5,lvm=vgcrypt"
Toujours dans l’environnement chrooté, mettez Grub à jour pour prendre en compte cette nouvelle configuration :
# update-grub
Et voilà, c’est prêt ! Vous pouvez redémarrer et profiter de votre nouveau système chiffré !
Sûreté, vérifications et performances
Sûreté contre les corruptions du disque
Le problème de chiffrer ses données, c’est que si l’entête LUKS qui permet de déchiffrement est corrompu, toutes vos données sont perdues : même avec le mot de passe, il n’y a plus rien à faire.
Heureusement, on peut tout à fait sauvegarder cet entête, par exemple avec la commande suivante :
$ sudo cryptsetup luksHeaderBackup /dev/sda3 --header-backup-file luks-header.bin.crypt
La commande est assez claire : on demande à cryptsetup de sauvegarder les en-têtes de la partition physique chiffrée dans le fichier luks-header.bin.crypt. Ceci va produire un fichier d’un peu plus de 1 Mio, accessible en lecture seule par root uniquement, que vous pouvez conserver précieusement ailleurs.
Bien, j’ai réussi à démarrer mon Linux sur ma partition chiffrée. Comment puis-je vérifier que tout est bien chiffré comme je le veux ? Quel impact de ce chiffrement sur les performances ?
Voilà des questions pertinentes ! Voyons comment y répondre.
Vérifier le chiffrement des partitions
Rien de plus simple, il suffit de lister les périphériques en mode bloc du système, et de vérifier que les points de montage sont bien là où on les attend. Par exemple :
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
sda 8:0 0 74,5G 0 disk
├─sda2 8:2 0 512M 0 part /boot
├─sda3 8:3 0 74G 0 part
│ └─hdcrypt 253:0 0 74G 0 crypt
│ ├─vgcrypt-lvroot 253:1 0 16G 0 lvm /
│ ├─vgcrypt-lvswap 253:2 0 4G 0 lvm [SWAP]
│ └─vgcrypt-lvhome 253:3 0 54G 0 lvm /home
└─sda1 8:1 0 64M 0 part /boot/efi
On voit bien que si /boot et /boot/efi correspondent bien à des partitions physiques (respectivement sda1 et sda2), les partitions racine, /, /home et le swap sont bien dans des volumes LVM au sein d’un volume chiffré.
Quel impact sur les performances ?
Pour vérifier ça, on va mesurer les performances du disque lui-même, puis du container chiffré LUKS. On va accéder à ces périphériques directement en mode bloc, en lecture seule et en accès aléatoires avec différentes tailles de blocs (de 512 octets jusqu’à ce qu’on passe sous les 8 opérations par seconde).
Pour ce faire on va utiliser iops, qui est un outil récent, conçu sérieusement (c’est très facile de concevoir un mauvais test d’entrées/sorties) et accessible en ligne de commande.
Les exemples ci-dessous sont exécutés sur un Intel® Core™ i3–3110M CPU @ 2.40GHz de 2012 sans instructions AES-NI qui pourraient accélérer le chiffrement / déchiffrement des données, et un vieux SSD Intel X25-M de 2009.
Installation de iops
$ wget https://raw.githubusercontent.com/cxcv/iops/master/iops
--2016-12-11 18:33:13-- https://raw.githubusercontent.com/cxcv/iops/master/iops
Résolution de raw.githubusercontent.com (raw.githubusercontent.com)… 151.101.60.133
Connexion à raw.githubusercontent.com (raw.githubusercontent.com)|151.101.60.133|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 10104 (9,9K) [text/plain]
Enregistre : «iops»
iops 100%[===================>] 9,87K --.-KB/s in 0s
2016-12-11 18:33:13 (86,7 MB/s) - «iops» enregistré [10104/10104]
$ chmod +x iops
Performances du disque
On lance le test sur la partition qui contient le container LUKS, puis sur le conteneur chiffré lui-même.
$ sudo ./iops /dev/sda3
/dev/sda3, 79.42 G, sectorsize=512B, #threads=32, pattern=random:
512 B blocks: 48616.2 IO/s, 24.9 MB/s (199.1 Mbit/s)
1 kB blocks: 35126.8 IO/s, 36.0 MB/s (287.8 Mbit/s)
2 kB blocks: 22681.0 IO/s, 46.5 MB/s (371.6 Mbit/s)
4 kB blocks: 13547.9 IO/s, 55.5 MB/s (443.9 Mbit/s)
8 kB blocks: 13053.5 IO/s, 106.9 MB/s (855.5 Mbit/s)
16 kB blocks: 7616.1 IO/s, 124.8 MB/s (998.3 Mbit/s)
32 kB blocks: 4061.8 IO/s, 133.1 MB/s ( 1.1 Gbit/s)
65 kB blocks: 2134.1 IO/s, 139.9 MB/s ( 1.1 Gbit/s)
131 kB blocks: 1182.6 IO/s, 155.0 MB/s ( 1.2 Gbit/s)
262 kB blocks: 758.7 IO/s, 198.9 MB/s ( 1.6 Gbit/s)
524 kB blocks: 458.4 IO/s, 240.3 MB/s ( 1.9 Gbit/s)
1 MB blocks: 257.2 IO/s, 269.6 MB/s ( 2.2 Gbit/s)
2 MB blocks: 137.6 IO/s, 288.6 MB/s ( 2.3 Gbit/s)
4 MB blocks: 71.1 IO/s, 298.2 MB/s ( 2.4 Gbit/s)
8 MB blocks: 35.5 IO/s, 297.4 MB/s ( 2.4 Gbit/s)
16 MB blocks: 17.6 IO/s, 294.6 MB/s ( 2.4 Gbit/s)
33 MB blocks: 8.9 IO/s, 298.3 MB/s ( 2.4 Gbit/s)
67 MB blocks: 4.5 IO/s, 302.4 MB/s ( 2.4 Gbit/s)
$ sudo ./iops /dev/mapper/hdcrypt
/dev/mapper/hdcrypt, 79.42 G, sectorsize=512B, #threads=32, pattern=random:
512 B blocks: 36113.5 IO/s, 18.5 MB/s (147.9 Mbit/s)
1 kB blocks: 28022.3 IO/s, 28.7 MB/s (229.6 Mbit/s)
2 kB blocks: 20089.7 IO/s, 41.1 MB/s (329.1 Mbit/s)
4 kB blocks: 13159.6 IO/s, 53.9 MB/s (431.2 Mbit/s)
8 kB blocks: 12800.8 IO/s, 104.9 MB/s (838.9 Mbit/s)
16 kB blocks: 7544.3 IO/s, 123.6 MB/s (988.9 Mbit/s)
32 kB blocks: 4086.5 IO/s, 133.9 MB/s ( 1.1 Gbit/s)
65 kB blocks: 2120.6 IO/s, 139.0 MB/s ( 1.1 Gbit/s)
131 kB blocks: 1177.8 IO/s, 154.4 MB/s ( 1.2 Gbit/s)
262 kB blocks: 754.0 IO/s, 197.7 MB/s ( 1.6 Gbit/s)
524 kB blocks: 459.7 IO/s, 241.0 MB/s ( 1.9 Gbit/s)
1 MB blocks: 256.7 IO/s, 269.2 MB/s ( 2.2 Gbit/s)
2 MB blocks: 136.3 IO/s, 285.8 MB/s ( 2.3 Gbit/s)
4 MB blocks: 70.5 IO/s, 295.6 MB/s ( 2.4 Gbit/s)
8 MB blocks: 35.4 IO/s, 296.6 MB/s ( 2.4 Gbit/s)
16 MB blocks: 18.8 IO/s, 315.4 MB/s ( 2.5 Gbit/s)
33 MB blocks: 9.1 IO/s, 304.6 MB/s ( 2.4 Gbit/s)
67 MB blocks: 4.4 IO/s, 296.9 MB/s ( 2.4 Gbit/s)
Les accès directs à la partition donnent des valeurs au-delà de la spécification Intel, tout est parfait !
Sur les accès au conteneur chiffré, malgré une petite baisse en particulier sur les toutes petites lectures, les performances sont globalement les mêmes. Par contre, l’occupation CPU (invisible ici) est beaucoup plus importante lors de la lecture des données chiffrées.
Illustration en graphiques, avec en prime l’accès à la partition qui contient /home pour être sûr que LVM ne pose pas de problème :
Et voilà, vous savez maintenant comment installer Ubuntu (ou l’un de ses moult dérivés) sur un disque dur intégralement chiffré ! On peut trouver dommage que la procédure d’installation standard ne permette pas ce genre de montage, mais sans doute n’est-ce pas la cible philosophique d’Ubuntu. C’est dommage parce qu’avec les matériels modernes, on voit difficilement pourquoi se priver de chiffrer les données de son ordinateur portable.
Si vous avez la moindre question, n’hésitez pas à la poser sur les forums. N’hésitez pas non plus à me signaler toute erreur ou imprécision à l’aide du bouton dédié à cet effet ou directement en commentaire. Si vous avez des retours d’expériences sur des matériels modernes (les SSD modernes sont bien plus rapides) ou anciens, ça m’intéresse aussi.
Logo CC-BY-SA, d’après Cryptographic slide rule used as a calculation aid by the Swiss Army between 1914 and 1940, CC-BY-SA 2.0 Rama, via Wikimedia Commons.
Je vais le diffuser au plus grand nombre.
