C’est en lisant un vieux post sur macOS Mojave que j’ai eu envie de vérifier un truc. Dixit ce sujet, Apple utilise les instructions AES-Ni des processeurs Intel pour accélérer le chiffrement avec OpenSSL à partir de la version 10.14.5 de macOS Mojave.
AES-NI, c’est quoi ? Des instructions pensées pour accélérer tout ce qui a un rapport avec le chiffrement avec les processeurs Intel. Les instructions sont apparues avec les processeurs Core de première génération, mais elle n’étaient pas généralisées à l’époque. De façon général, il a fallu attendre la 6e génération de puces (Skylake) pour avoir les instructions dans toute la gamme. Dans les puces qui précèdent, il faut généralement un Core i5 ou i7 (et parfois i3). Les gains avec AES-NI sont très importants dans tout ce qui touche au chiffrement, on peut espérer multiplier les performances par vingt.
Je me suis toujours demandé si Apple utilisait les instructions dans ses Mac, car macOS emploie pas mal le chiffrement en AES. Avec FileVault, par exemple, tout est chiffré en permanence et donc l’impact sur le CPU peut être élevé. L’article se penche sur un cas précis, celui d’OpenSSL. Avec macOS 10.14.5, Apple a visiblement modifié son implémentation d’OpenSSL pour tirer parti d’AES-NI, compte tenu des gains. J’ai testé sur un MacBook Pro de 2017 sous macOS Mojave avec la version originale de l’OS (10.14.0) et la dernière (10.14.6). J’explique plus bas que le plus compliqué à été d’installer l’OS.
Par ailleurs, il faut bien comprendre une chose : tout ceci est très théorique et surtout là pour expliquer les choses. Vous n’avez probablement plus de Mac sous macOS Mojave (même si l’OS reste présent que d’autres parce que c’est le dernier qui prend en charge les applications 32 bits) et même si c’est le cas, vous avez là encore probablement installé la dernière version (et si ce n’est pas le cas, c’est une mauvaise idée).
Quelques essais
Avec OpenSSL, donc, la différence est très significative sur le benchmark intégré (openssl speed dsa
). On passe de 1 485 signatures/s à 20 932 signatures/s par exemple (en DSA 512 bits). Les gains sont très importants et il n’y a que les instructions AES-NI qui permettent ça. Dans un autre exemple lié à OpenSSL, il y a le chiffrement d’un fichier de 832 Mo. Il prend 23 secondes avec macOS Mojave 10.14.0 (en AES 256) et environ 11 secondes avec la version 10.14.6. Le gain n’est pas aussi élevé que sur un test théorique pour une bonne raison : le chiffrement ne dépend pas uniquement du temps de calcul, mais aussi des performances du SSD.
Ensuite, je me suis posé une question simple : est-ce que d’autres usages gagnent en performances ? J’ai donc chiffré un SSD externe en HFS+ puis en APFS, sans succès. Les performances sont les mêmes entre les deux, soit parce qu’Apple utilisait déjà les instructions, soit parce que la charge n’est pas assez importante pour voir une différence. J’ai ensuite testé avec un partage réseau en Ethernet à 2,5 Gb/s, avec le même résultat : même en SMB chiffré, pas de différences. Idem avec une image disque chiffrée en HFS+ : les performances sont identiques (et faibles dans les deux cas).
Enfin, j’ai tenté avec un partage en Thunderbolt over IP, avec une petite différence. Sur la lecture séquentielle, la dernière version de macOS Mojave est un peu plus rapide avec plusieurs commandes dans la queue, et très significativement avec une seule commande. On n’est vraiment probablement dans un cas ou le chiffrement devient le goulet d’étranglement, devant les autres opérations liées à la lecture. Après, je ne suis pas totalement certain que le problème ne vient pas d’autres points, mais j’ai fait le test plusieurs fois pour vérifier tout de même.
Dans tous les cas, la différence ne semble vraiment visible qu’avec OpenSSL dans un cas théorique, et c’est toujours un biais très présent avec les accélérations matérielles de ce type. Les gains des instructions sont bien présents, et elles ont un intérêt dans des cas particuliers (comme pour les serveurs, qui effectuent énormément d’opérations de chiffrement). Mais dans un usage plus classique, il est vraiment difficile de voir les gains, même si les calculs sont 20x plus rapides. Parce que dans un usage normal, ce n’est pas vraiment le temps de calcul lié au déchiffrement qui va ralentir le Mac, mais plutôt le débit du SSD, le débit ou la latence du réseau, etc. Et donc même si le temps de calcul diminue pour une partie des tâches… les tâches en question ne se terminent pas nécessairement plus rapidement.
Pour terminer, le problème ne se pose généralement pas sur les puces ARM, les instructions cryptographiques sont habituellement présentes dès qu’on a une puce ARMv8.
Installer la version d’origine de Mojave
Pour tester, j’avais besoin d’une version de macOS Mojave assez ancienne, donc pas la 10.14.6 installée sur le Mac. Sur le papier, avec l’APFS, c’est simple : il suffit d’ajouter un volume qui va partager l’espace disque (c’est plus souple qu’une partition). Dans la pratique, il faut se méfier d’une chose : les versions récentes de l’APFS posent des soucis avec Mojave, donc vous ne verrez pas nécessairement les données des autres OS.
Pour installer Mojave, il a fallu trouver l’installeur de départ, que je n’avais plus. Je ne garde que les fichiers à jour, donc la version 10.14.6, et Apple ne propose que la dernière. Dans la pratique, on trouve assez facilement une version d’époque, par exemple en cherchant avec le numéro de build (18A391
). Pour l’installer, je ne suis pas passé par une clé USB – en fait, si, mais le Mac refusait de démarrer dessus – mais j’ai simplement lancé l’exécutable depuis macOS Mojave qui était déjà installé (depuis les OS suivants, macOS l’empêche). Il y a deux contraintes : il n’est pas signé (plus exactement, la signature n’est plus valable) et il faut mettre la date du Mac aux alentours de la date de sortie de macOS Mojave (septembre 2018) pour pouvoir l’installer sans peine. Ensuite, tout à fonctionné. Et bien évidemment, mais c’était implicite, vous aurez besoin d’un Mac qui accepte macOS Mojave (donc il ne doit pas être trop vieux ni trop récent).