"Le plus impressionnant est selon moi les perfs du module matériel AES, openssl dispose d'un engine lui permettant d'utiliser le padlock de via, à quand un patch pour le geode ?"
Jamais : le cryptage avec le via padlock est fait par des instructions étendues du processeur, l'approche utilisée sur le Geode LX est complètement différente.
Même s'il est intégré au processeur, le bloc de sécurité AES est vu comme un périphérique PCI, on y accède en faisant du DMA entre la mémoire et le périphérique.
Pour accéder au matériel, OpenSSL utilise un périphérique cryptodev qui fait le lien entre le userland et le matériel dans le noyau. C'est ce qu'apporte l'Open Crypto Framework (OCF). Sous les BSD, OCF est aussi utilisé en interne par le noyau (pour IPsec par exemple).
J'ai fais pas mal de tests de perf avec OpenSSL sous FreeBSD (j'ai porté le driver glxsb d'OpenBSD sous FreeBSD). Ce qui me chagrine le plus dans le bloc de sécurité c'est la lenteur des interruptions pour déterminer la fin du codage. Du coup il faut utiliser un horrible busy-wait et tester la fin en lisant les registres. Beurk !
- sans le matériel:
1m11.57s real 1m7.69s user 3.34s sys
- avec le matériel en utilisant les interruptions (oui c'est plus long en temps réel)
1m27.08s real 1.58s user 6.85s sys
- avec le matériel et un busy wait.
18.41s real 1.51s user 16.75s sys
- avec le matériel et un busy wait, mais qui tourne dans un thread noyau (pour éviter de bloquer dans l'OCF). C'est la version actuelle du driver FreeBSD.
21.11s real 1.57s user 6.41s sys
Je suis preneur de mesures faites sous Linux.
J'ai aussi fait des essais sur IPsec en aes-128-cbc + hmac_md5, en faisant des pings flood simultanés à partir d'une autre machine "ping -f -s 3000". Sans le matériel, la machine est à genou avec 5 ping, top ne tourne plus. Avec le matériel, je peux faire 8 ping flood sans aucun soucis (je n'ai pas essayé plus loin). Top:
CPU: 0.0% user, 0.0% nice, 33.5% system, 12.5% interrupt, 54.1% idle
Je n'ai pas fait de benchmark d'Ipsec, OpenBSD annonce du 30Mbit/s mais sans en dire beaucoup plus :
http://www.onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html
Enfin bref il y a quand même un net gain de perf, et puis c'est présent sur le processeur alors autant s'en servir.
Pour le générateur de nombre aléatoire pas grand chose à dire, je l'ai testé avec le module rndtest (FIPS 140-2) de FreeBSD et j'ai eu une dizaine d'échecs en quatres jours, mais toujours avec des valeurs très proches de l'intervalle autorisé:
# Geode AES
Posté par Patrick Lamaizière (site web personnel) . En réponse au journal Que vaut vraiment l'AMD Geode LX 800 ?. Évalué à 4.
Jamais : le cryptage avec le via padlock est fait par des instructions étendues du processeur, l'approche utilisée sur le Geode LX est complètement différente.
Même s'il est intégré au processeur, le bloc de sécurité AES est vu comme un périphérique PCI, on y accède en faisant du DMA entre la mémoire et le périphérique.
Pour accéder au matériel, OpenSSL utilise un périphérique cryptodev qui fait le lien entre le userland et le matériel dans le noyau. C'est ce qu'apporte l'Open Crypto Framework (OCF). Sous les BSD, OCF est aussi utilisé en interne par le noyau (pour IPsec par exemple).
J'ai fais pas mal de tests de perf avec OpenSSL sous FreeBSD (j'ai porté le driver glxsb d'OpenBSD sous FreeBSD). Ce qui me chagrine le plus dans le bloc de sécurité c'est la lenteur des interruptions pour déterminer la fin du codage. Du coup il faut utiliser un horrible busy-wait et tester la fin en lisant les registres. Beurk !
Pour crypter un fichier de 361 Mo:
/usr/bin/time -h openssl enc -e -aes-128-cbc -in file -out /dev/null
-k abcdefghijk -nosalt
- sans le matériel:
1m11.57s real 1m7.69s user 3.34s sys
- avec le matériel en utilisant les interruptions (oui c'est plus long en temps réel)
1m27.08s real 1.58s user 6.85s sys
- avec le matériel et un busy wait.
18.41s real 1.51s user 16.75s sys
- avec le matériel et un busy wait, mais qui tourne dans un thread noyau (pour éviter de bloquer dans l'OCF). C'est la version actuelle du driver FreeBSD.
21.11s real 1.57s user 6.41s sys
Je suis preneur de mesures faites sous Linux.
J'ai aussi fait des essais sur IPsec en aes-128-cbc + hmac_md5, en faisant des pings flood simultanés à partir d'une autre machine "ping -f -s 3000". Sans le matériel, la machine est à genou avec 5 ping, top ne tourne plus. Avec le matériel, je peux faire 8 ping flood sans aucun soucis (je n'ai pas essayé plus loin). Top:
CPU: 0.0% user, 0.0% nice, 33.5% system, 12.5% interrupt, 54.1% idle
Je n'ai pas fait de benchmark d'Ipsec, OpenBSD annonce du 30Mbit/s mais sans en dire beaucoup plus :
http://www.onlamp.com/pub/a/bsd/2007/11/01/whats-new-in-bsd-42.html
Enfin bref il y a quand même un net gain de perf, et puis c'est présent sur le processeur alors autant s'en servir.
Pour le générateur de nombre aléatoire pas grand chose à dire, je l'ai testé avec le module rndtest (FIPS 140-2) de FreeBSD et j'ai eu une dizaine d'échecs en quatres jours, mais toujours avec des valeurs très proches de l'intervalle autorisé:
glxsb0: rndtest: zeros interval 3 failed (723, 542-708)
723 pour 708
glxsb0: rndtest: ones interval 1 failed (2336, 2343-2657)
2336 pour 2343
Alors je pense que c'est bon, enfin j'espère c'est pas facile à dire.
les pixels au peuple !