Journal AES-XTS dans le noyau Linux 6.10

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
70
23
juil.
2024

Le dernier noyau Linux publié est le 6.10 et il incorpore le travail d'Eric Biggers qui a cherché à optimiser les performances de l'algorithme de chiffrement AES.

Cet algorithme est notamment utilisé, dans son mode d'opération AES-XTS, pour chiffrer nos disques durs via le standard LUKS et l'outil cryptsetup.

Avec les disques SSD le débit de données est très important et tous les accès au disque dur doivent donc passer par ces phases de chiffrement ou de déchiffrement. Les performances des primitives cryptographiques du noyau sont donc cruciales pour ne pas subir de ralentissement.

Curieux de constater le résultat du travail d'Eric Biggers j'ai lancé le benchmark avec un noyau 6.9.10 (l'ancienne version) et avec un noyau 6.10 (la nouvelle version).
Voici les résultats (la machine est un laptop avec un Intel de la génération Alder Lake modèle i7-1260p) :

Titre de l'image

Titre de l'image

On constate bien un progrès très important pour l'algorithme AES-XTS 256 bits qui passe d'environ 4670 MiB/s à 7870 MiB/s soit une progression de 68%.

Ce n'est pas tous les jours qu'on empoche ainsi un tel gain et cela permet d'utiliser sereinement le chiffrage de votre disque dur sous Linux sans avoir à payer ça par une baisse des performances.

  • # Chouette

    Posté par  . Évalué à 10 (+12/-0).

    Quelle nouvelle réjouissante.

    Merci à toi pour l'info hyper intéressante et merci au dev pour le boulot.

    "Si tous les cons volaient, il ferait nuit" F. Dard

  • # Ajout de code en assembleur

    Posté par  (site web personnel) . Évalué à 4 (+2/-0).

    Je suppose que le gain de perf vient de cette partie du commit Git:

    create mode 100644 arch/x86/crypto/aes-xts-avx-x86_64.S

    Ajout d'un code assembleur AVX ("Advanced Vector Extensions").

    Lien vers le code : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/crypto/aes-xts-avx-x86_64.S

    • [^] # Re: Ajout de code en assembleur

      Posté par  (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 24 juillet 2024 à 14:54.

      En fait on voit dans le mail de récap d'Herbert Xu (mainteneur officiel de la partie crypto du noyau) qu'il y a eu plusieurs commits cumulatifs d'Eric Biggers optimisant aes-xts :

      crypto: x86/aes-xts - add AES-XTS assembly macro for modern CPUs
      crypto: x86/aes-xts - wire up AESNI + AVX implementation
      crypto: x86/aes-xts - wire up VAES + AVX2 implementation
      crypto: x86/aes-xts - wire up VAES + AVX10/256 implementation
      crypto: x86/aes-xts - wire up VAES + AVX10/512 implementation
      crypto: x86/aes-xts - make non-AVX implementation use new glue code
      crypto: x86/aes-xts - access round keys using single-byte offsets
      crypto: x86/aes-xts - handle CTS encryption more efficiently
      crypto: x86/aes-xts - handle AES-128 and AES-192 more efficiently
      crypto: x86/aes-xts - eliminate a few more instructions
      crypto: x86/aes-xts - optimize size of instructions operating on lengths
      crypto: x86/aes-xts - simplify loop in xts_crypt_slowpath()

      • [^] # Re: Ajout de code en assembleur

        Posté par  (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 24 juillet 2024 à 18:39.

        Curieux je ne vois pas d'amélioration (je viens de mettre à jour mon Arch pour passer au 6.10).

        crypto: x86/aes-xts - add AES-XTS assembly macro for modern CPUs

        Ça veut dire quoi "modern CPU" d'après toi ? Le mien a l'air d'avoir les instructions AES concernées non ?

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # nice

    Posté par  (site web personnel) . Évalué à 5 (+4/-0).

    sur ma machine j'obtiens 52% d'augmentation sur le même test.
    Cela reste impressionnant

  • # [HS] Pourquoi des captures d'écran?

    Posté par  (site web personnel) . Évalué à 7 (+10/-5).

    J'ai l'habitude de recevoir des captures d'écran pour du texte venant de mon logiciel ou de ligne de commande, mais comme ces personnes sont pas expertes j'évite de les "attaquer" la dessus, mais ici les personnes écrivant sont sensée mieux connaître donc je pose la question qui me trotte dans la tête depuis un moment : pourquoi cette habitude de faire une capture d'écran de texte plus facile à copier/coller dans un mail ou journal LinuxFr que capture d'écran à découper et stocker (sans parler de son "poids" inutilement plus élevé pour la même information)?

    • [^] # Re: [HS] Pourquoi des captures d'écran?

      Posté par  (site web personnel) . Évalué à 10 (+11/-3).

      Un tableau de chiffres tu peux écrire ce que tu veux comme résultat alors que la capture d'écran c'est la "preuve irréfutable" que le gain est réel :-)

      Non en fait ça m'a juste paru plus simple que de galérer avec la syntaxe markdown pour coller les résultats.

      • [^] # Re: [HS] Pourquoi des captures d'écran?

        Posté par  (site web personnel) . Évalué à 10 (+12/-1). Dernière modification le 25 juillet 2024 à 01:29.

        galérer avec la syntaxe markdown pour coller les résultats.

        hein ?!

        ```bash au début et ``` à la fin, et c'est marre…

        [root@localhost ~]# cryptsetup benchmark
# Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S).
PBKDF2-sha1      1008246 itérations par seconde pour une clé de 256 bits
PBKDF2-sha256    1376083 itérations par seconde pour une clé de 256 bits
PBKDF2-sha512    1008246 itérations par seconde pour une clé de 256 bits
PBKDF2-ripemd160  607517 itérations par seconde pour une clé de 256 bits
PBKDF2-whirlpool  431868 itérations par seconde pour une clé de 256 bits
argon2i       4 itérations, 1048576 mémoire, 4 threads parallèles (CPUs) pour une clé de 256 bits (temps de 2000 ms demandé)
argon2id      4 itérations, 1040385 mémoire, 4 threads parallèles (CPUs) pour une clé de 256 bits (temps de 2000 ms demandé)
#    Algorithme |       Clé |     Chiffrement |    Déchiffrement
        aes-cbc        128b       578,5 MiB/s      2318,8 MiB/s
    serpent-cbc        128b        77,2 MiB/s       494,2 MiB/s
    twofish-cbc        128b       164,2 MiB/s       314,8 MiB/s
        aes-cbc        256b       429,6 MiB/s      1817,2 MiB/s
    serpent-cbc        256b        78,6 MiB/s       496,9 MiB/s
    twofish-cbc        256b       166,8 MiB/s       314,8 MiB/s
        aes-xts        256b      2029,6 MiB/s      2053,4 MiB/s
    serpent-xts        256b       455,9 MiB/s       449,9 MiB/s
    twofish-xts        256b       292,7 MiB/s       299,8 MiB/s
        aes-xts        512b      1627,2 MiB/s      1649,9 MiB/s
    serpent-xts        512b       463,0 MiB/s       452,1 MiB/s
    twofish-xts        512b       299,5 MiB/s       300,0 MiB/s

    • [^] # Re: [HS] Pourquoi des captures d'écran?

      Posté par  (Mastodon) . Évalué à 6 (+4/-0).

      pourquoi cette habitude de faire une capture d'écran

      Pour être compatible Instagram ?

    • [^] # Re: [HS] Pourquoi des captures d'écran?

      Posté par  (site web personnel) . Évalué à 4 (+2/-0).

      Perso, j'aurais bien aimé voir un joli "plot" plutôt que d'avoir à parser la capture d'écran.

      • [^] # Re: [HS] Pourquoi des captures d'écran?

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        et donc après parsing + plot ça donne quoi ? :D (tu peux héberger sur imgur comme patrick_g< :p)

        je n'ai qu'un kernel 6.6.42 pour fournir les infos sur ma machine :/ (cauldron suit les kernel LTS pour les fournir en Mageia stable aka 9 ensuite, donc bon 6.10 attendra)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.