Activer le Padlock du VIA Nano (Dedibox V3) sous Debian 64 bits
Par NoNoBzH le dimanche, juin 6 2010, 11:53 - Informatique - Lien permanent
Certains d'entre vous auront remarqués que le Padlock n'est pas activé
par défaut sous Debian 64 bits, et ce pour deux raisons.
Premièrement
les modules ne sont pas chargés automatiquement au démarrage.
Et
deuxièmement, OpenSSL ne se sert pas du Padlock en 64 bits.
- Chargement des modules :
pour cela, tapez dans une console :
modprobe padlock-aes
modprobe padlock-sha
Pour que ces modules soient chargés dès le démarrage de la machine tapez ceci :
echo padlock-aes >> /etc/modules && echo padlock-sha >> /etc/modules
- Modification d'OpenSSL :
C'est la partie la plus complexe et la plus longue. En effet il va falloir modifier les sources d'OpenSSL et les recompiler pour que OpenSSL utilise le Padlock.
Si vous êtes sous Debian 64, en install de base Dedibox et que vous ne voulez pas tout recompiler, je met à disposition les paquets en bas de la page.
Petite explication :
Le premier Padlock est apparu avec le processeur VIA C7 il y a quelques année. Il n'était que 32 bits. Quand son support a été ajouté à OpenSSL, il ne l'a été quand dans la version 32 bits !
Or le VIA Nano est compatible 64 bits, mais OpenSSL n'a pas encore intégré cette spécificité.
Tout d'abbord, téléchargez ce patch : centaur-openssl-padlock-x86_64.patch
Ce patch provient du Forum Ubuntu (inscription obligatoire pour le télécharger).
On installe les pré-requis :
aptitude install build-essential devscripts fakeroot
aptitude build-dep openssl
On télécharge les sources d'OpenSSL :
apt-get source openssl
On entre dans le répertoire :
cd openssl-0.9.8g
(à adapter suivant votre version d'OpenSSL)
wget -q -O - http://launchpadlibrarian.net/13798833/bug119295.patch | patch -p1
En fait, ce n'est pas nécessaire pour les version >= 0.9.8g
On patch une deuxième partie :
wget -q -O - http://www.logix.cz/michal/devel/padlock/contrib/openssl-0.9.8e-engine.diff | patch -p1
Puis on patch la dernière partie :
cat ../centaur-openssl-padlock-x86_64.patch | patch -p1
Un petit debchange : (optionnel)
debchange --nmu
Si nano s'ouvre : ctrl-o puis ctrl-x
Si vi s'ouvre : echap puis :wq
Et là, l'étape la plus longue : la compilation + création du package :
dpkg-buildpackage
Une fois fait (environ 10-15 minutes) on installe les paquets créés (à adapter suivant votre distribution) :
dpkg -i ../openssl_0.9.8g-15+lenny6.1_amd64.deb ../libssl0.9.8_0.9.8g-15+lenny6.1_amd64.deb ../libssl-dev_0.9.8g-15+lenny6.1_amd64.deb
On vérifie qu'il est bien reconnu par OpenSSL :
#openssl engine
(padlock) VIA PadLock (no-RNG, ACE)
(dynamic) Dynamic engine loading support
Si vous voyez la ligne avec padlock, c'est bon :)
Et voilà ! Maintenant on peut tester tout ça :
#openssl speed -evp aes-128-ecb [-engine padlock]
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-ecb 49787.88k 53811.97k 54739.18k 55077.02k 54949.63k
aes-128-ecb 144205.73k 493446.57k 1107523.84k 1591005.98k 1836111.30k
On voit tout de suite la différence !
La première ligne est en mode dynamic (sans le Padlock)
La deuxième est avec le Padlock.
Maintenant, il faut configurer OpenSSL pour utiliser par défaut le padlock : c'est par ici
Source et Source
Commentaires
Excellent!
Qu'en est-il avec la dernière version de OpenSSL à savoir la 1.0.0a ?
C'est une bonne question :)
Le meilleur moyen de le savoir est de l'installer et de regarder si le Padlock est détecté.
Malheureusement je n'ai pas de dedibox v3 sous la main (j'évalue divers solutions là...).
Si tu essais la 1.0.0a, fais le savoir ici. Je penses que je ne suis pas le seul intéressé par le sujet ;) cf:
http://blog.crifo.org/post/2010/06/...
Sinon, si t'as l'occase, un petit unixbench 5.1.2 serait la bienvenu histoire de voir ce que cette petite dedibox v3 à dans le ventre. Voici quelques un de mes tests:
http://wanab.free.fr/unixbench/5.1....
Pour info:
# Installation des éléments nécessaire pour la compilation
> aptitude install build-essential
> wget http://byte-unixbench.googlecode.co...
> tar zxvf unixbench-5.1.2.tar.gz
> cd unixbench-5.1.2
> nano Makefile
# Mettre en commentaire "GRAPHIC_TESTS = defined"
> make
> ./Run
# attention, ça met plus d'une heure à compléter...
/!\ petite précision pour choper la source.
j'avais besoin d'installer le client whois, et la, aptitude se fache et me sort plein de dépendances cassées (apache, postfix, ssh, nginx, courier, openvpn... et beaucoup d'autres) o_Ô
En fait, la version d'OpenSSL installée de base sur US 10.04 est donc la 0.9.8k et quand on chope la source, on se retrouve avec le code de la 0.9.8g
Du coup, tous les paquets dépendants d'openssl sont "cassés" car la version g est trop vieille, il faut au moins la k.
Après un pti tour dans /etc/apt/sources.list, j'ai copié les lignes en modifiant au début "deb" en "deb-src"
Une fois le fichier modifié, ça va maintenant bien récupérer les sources pour lucid (sinon, comme les deb-src n'étaient pas inscrit par défaut dans le source.list, il allait chercher par défaut celles de karmik.... c'est con mais c'est comme ça)
Bref, après cette modif, aptitude update et apt-get source openssl me récupérer bien les sources de la version k.
Ensuite, à nouveau les 2 patch, puis recompilation, et c'est bon. le padlock est toujours activé et les dépendances sont satisfaites :)
Et surprise sur le gateau, une fois la procedure terminée, je refais un test de speed sous openssl.. et j'ai beaucoup mieux qu'avant !
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-ecb 128178.63k 435178.33k 1057783.81k 1567884.97k 1824399.36k
avant, en version g :
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 117876.02k 354836.03k 665504.62k 847728.98k 930318.83k
donc voila... attention à la version ça bouffe les performances :p