[gelöst][patch] Via Epia Padlock OpenSSL Support für 64 Bit

[Ceekay1]

Hallo DebianForum,

ich habe mal wieder etwas neue Hardware angeschafft und es ist ein Via Epia-M910-10PE Mainboard mit 8GB Ram.

Board -> Beschreibung
CPU -> Eden X2

Bisher hatte ich "nur" 512MB Ram auf meinem Epia-EN12000G und kam mit 32Bit super klar.
Da 32Bit Systeme ohne Performance-Einbruch wohl keine 8GB Ram adressieren können, wollte ich jetzt auf 64bit umsteigen.

Via CPUs haben diese tolle Padlock Security Engine, die Crypto-Aktionen deutlich beschleunigen soll.
Allerdings scheint der Support dafür in Linux 64Bit generell defekt zu sein, so auch in Debian 6.0.6
32Bit funktioniert wie erwartet, aber mit zu wenig Ram nützt mir das nichts.

Die beste Problembeschreibung samt mutmaßlicher Lösung hab ich hier gefunden -> bugzialla.redhat.com Bug #617539

Das Ergebnis da war wohl, dass der Bug für die angegebene Version (Fedora12) irgendwann "outdated" war.
Im letzten Post schreibt ein User, dass Fedora15beta immernoch diese "Macke" hat.

Kann ich das dennoch irgendwie für Debian verwenden? Falls ja, wie? Hab leider nicht so die Erfahrung mit Patches und Diffs.
Die "unstable/testing" Packages hatten jedenfalls auch noch keinen Padlock Support.

Ist es grundsätzlich zeitgemäß, den 64Bit Zweig noch "AMD64" zu nennen?
Ist doch klar, dass kein Entwickler Padlock für 64Bit AMD berücksichtigt.
Und dass es Via CPUs mit 64Bit gibt hat sich scheinbar auch noch nicht überall rumgesprochen.

Vielen Dank schonmal für die Hilfe
MfG Ceekay

Edit: Titel angepasst

[rendegast]

Du könntest den backports-, wheezy- oder experimental-Kernel versuchen.

Andererseits adressiert der 32bit-pae bis 64GB,
die jeweiligen 32bit-Anwendungen könnten beschränkt sein, Abwägungssache bei ~ 1-2GHz.


wheezy:

Code: Alles auswählen

$ openssl version
OpenSSL 1.0.1c 10 May 2012
$ openssl engine padlock
(padlock) VIA PadLock (no-RNG, no-ACE)

[Ceekay1]

Hallo rendegast,

danke für die Vorschläge. Die 32bit-pea will ich nur als letzte Möglichkeit verwenden.

Ich habe entsprechend folgender Anleitung http://www.garron.me/linux/upgrade-debi ... 0-7.0.html auf Wheezy aktualisiert. Meine Ausgaben sind aber diese:

Code: Alles auswählen

openssl version
OpenSSL 1.0.1c 10 May 2012

openssl engine
(rsax) RSAX engine support
(dynamic) Dynamic engine loading support

openssl engine padlock
140118828787368:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521:
140118828787368:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=padlock

Geladen wird scheinbar alles korrekt:

Code: Alles auswählen

dmesg|grep pad
[    9.233355] padlock_aes: Using VIA PadLock ACE for AES algorithm.
[    9.235715] padlock_sha: Using VIA PadLock ACE for SHA1/SHA256 algorithms.

Code: Alles auswählen

lsmod |grep via
via_rng                12596  0
rng_core               12652  2 via_rng
snd_hda_codec_via      41160  1
snd_hda_codec          78031  2 snd_hda_intel,snd_hda_codec_via
snd                    52850  6 snd_timer,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_via
via_cputemp            12723  0
hwmon_vid              12430  1 via_cputemp
pata_via               12847  3
libata                140589  3 pata_via,sata_sil24,ata_generic
via_velocity           31788  0
crc_ccitt              12347  1 via_velocity

Code: Alles auswählen

lsmod |grep pad
padlock_sha            13367  0
padlock_aes            13024  0
aes_generic            33026  1 padlock_aes

Was habe ich denn jetzt anders gemacht als Du? Oder besser: wie bekomme ich openssl und padlock zusammen

Danke und schöne Feiertage!

Achso:

Code: Alles auswählen

uname -a
Linux testing 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux

[rendegast]

openssl engine padlock
140118828787368:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521:
140118828787368:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=padlock

Du hast einen bug gefunden?

[Ceekay1]

Was heißt "gefunden", das Problem scheint schon seit über einem Jahr bekannt zu sein.
Was hast Du angestellt, damit es geht?

Ein frisches Wheezy ist mein nächster Versuch. Kann ja sein, dass ein Upgrade nicht ausreicht?

Edit: Ich habe den Titel angepasst, da Padlock wohl grundsätzlich erkannt und eingebunden wird.
Das Problem ist eher, dass Openssl Padlock nicht erkennt und benutzt.

[Ceekay1]

So.

Ich hab den Patch aus dem Redhat-Bug-Tracker genommen und einfach mal laufen lassen.
Das heißt ich hab den Pfad der openssl version 1.0.0a geändert zu 1.0.1c - sonst nichts.
Dann hab ich openssl neu kompiliert und die binary nach /usr/bin verschoben.

Befehle einmal ohne und einmal mit Padlock:

Code: Alles auswählen

openssl speed -evp aes-256-cbc
openssl speed -evp aes-256-cbc -engine padlock

Ergebnisse:

Code: Alles auswählen

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes    --- 32bit EN12000G
aes-256-cbc      10866.12k    11601.38k    13189.02k    11805.01k    11994.64k   --- ohne "engine padlock"
aes-256-cbc      72656.04k   226352.69k   488383.79k   678628.35k   775986.43k   --- mit "engine padlock"

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes    --- 32bit M910
aes-256-cbc      21924.10k    27416.62k    29418.41k    29985.79k    30149.29k   --- ohne "engine padlock"
aes-256-cbc      38848.14k   114841.07k   168002.13k   204629.33k   225419.26k   --- mit "engine padlock"

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes    --- 64bit M910
aes-256-cbc      26286.90k    29392.17k    30547.29k    30835.71k    30819.34k   --- original openssl binary ohne "engine padlock"
aes-256-cbc      47987.97k   159532.69k   310040.32k   405482.50k   445494.61k   --- patched ohne "engine padlock"
aes-256-cbc      48018.89k   159690.35k   309545.90k   405488.64k   445497.34k   --- patched mit "engine padlock"

Erste Verwunderung: Die Werte auf dem alten Board sind mit Padlock doppelt bis dreifach höher (erster Block zweite Datenreihe) als unter 32Bit auf dem Neuen (zweiter Block zweite Datenreihe).
Zweite Verwunderung: selbst unter 64Bit ist das neue Board kaum halb so schnell vie das Alte.
Weitere Beobachtung: mit 64Bit ist es doppelt so schnell als mit 32Bit (naja fast).

Also ich schließe daraus, dass mit dem Patch immer Padlock benutzt wird, da es keinen Unterschied macht, ob man "engine padlock" anhängt oder nicht.
Weitere Anmerkung ist, dass die openssl original eine Größen von 521.408 B besitzt, während es nach dem Patch 2.760.993 B sind.
Also ist da entweder das Padlock Ding hardcoded drin oder ich hab beim kompilieren was vergessen.

Edit: Ausgabe:

Code: Alles auswählen

~# openssl engine
(rsax) RSAX engine support
(dynamic) Dynamic engine loading support
(4758cca) IBM 4758 CCA hardware engine support
(aep) Aep hardware engine support
(atalla) Atalla hardware engine support
(cswift) CryptoSwift hardware engine support
(chil) CHIL hardware engine support
(nuron) Nuron hardware engine support
(sureware) SureWare hardware engine support
(ubsec) UBSEC hardware engine support
(padlock) VIA PadLock (no-RNG, ACE)
(gost) Reference implementation of GOST engine

Sind wohl ein paar Engines zu viel drin ^^ - wie bekomme ich die denn nur raus da?

Naja. Scheint also doch irgendwo der Hund im Pfeffer zu liegen - oder ist da der Hase begraben?
Ich teste das noch gründlich durch. Wenn keine groben Schnitzer drin sind, muss es eben so bleiben.

[rendegast]

Sind wohl ein paar Engines zu viel drin ^^ - wie bekomme ich die denn nur raus da?

Code: Alles auswählen

$ cat engines/Makefile | grep ^LIBNAMES
LIBNAMES= 4758cca aep atalla cswift gmp chil nuron sureware ubsec padlock capi

$ cat crypto/engine/eng_all.c | grep NO_HW_
#ifndef OPENSSL_NO_HW_4758_CCA
#ifndef OPENSSL_NO_HW_AEP
#ifndef OPENSSL_NO_HW_ATALLA
#ifndef OPENSSL_NO_HW_CSWIFT
#ifndef OPENSSL_NO_HW_NCIPHER
#ifndef OPENSSL_NO_HW_NURON
#ifndef OPENSSL_NO_HW_SUREWARE
#ifndef OPENSSL_NO_HW_UBSEC
#ifndef OPENSSL_NO_HW_PADLOCK

zBsp.
$ ./config no-hw-4758cca no-hw-aep no-hw-atalla no-hw-cswift no-hw-nuron no-hw-sureware

Da ist ein kleiner BUG, es gibt im Quelltext
...NO_HW_4758CCA
...NO_HW_4758_CCA
das müßte an ein paar Stellen angeglichen werden, um es "sauber" zu deaktivieren,
auf die Schnelle 'no-hw-4758_cca' oder 'no-hw-4758-cca' hilft aber auch.

Code: Alles auswählen

$ ./apps/openssl engine
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
(dynamic) Dynamic engine loading support
(ubsec) UBSEC hardware engine support
(padlock) VIA PadLock (no-RNG, no-ACE)
(gost) Reference implementation of GOST engine

Nochmal darauf zurückzukommen:

openssl engine padlock
140118828787368:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521:
140118828787368:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=padlock

Das ist so wohl ganz normal, wenn die engine beim Bauen deaktiviert wurde:

openssl (1.0.1c-3) unstable; urgency=low
* Disable padlock engine again, causes problems for hosts not supporting it.
-- Kurt Roeckx <kurt@roeckx.be> Wed, 06 Jun 2012 18:29:37 +0200

Vergleiche

Code: Alles auswählen

$ ./apps/openssl engine
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
(dynamic) Dynamic engine loading support
(4758cca) IBM 4758 CCA hardware engine support
(ubsec) UBSEC hardware engine support
(padlock) VIA PadLock (no-RNG, no-ACE)
(gost) Reference implementation of GOST engine

$ ./apps/openssl engine nuron
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
3076791048:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(/usr/local/ssl/lib/engines/libnuron.so): /usr/local/ssl/lib/engines/libnuron.so: cannot open shared object file: No such file or directory
3076791048:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
3076791048:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450:
3076791048:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=nuron

Code: Alles auswählen

$ openssl version
OpenSSL 1.0.1c 10 May 2012

$ openssl engine
(dynamic) Dynamic engine loading support

$ openssl engine padlock
(padlock) VIA PadLock (no-RNG, no-ACE)

irgendwie ist es noch "drin", halt nicht aktiv.
Unter 32bit gibt es nur nicht die Fehlermeldung.

[Ceekay1]

Sind wohl ein paar Engines zu viel drin ^^ - wie bekomme ich die denn nur raus da?

Code: Alles auswählen

zBsp.
$ ./config no-hw-4758cca no-hw-aep no-hw-atalla no-hw-cswift no-hw-nuron no-hw-sureware

Ok das hab ich geschafft, danke. Die binary ist aber immer noch 2.685.834 B groß. Ist das normal?

Da ist ein kleiner BUG, es gibt im Quelltext
...NO_HW_4758CCA
...NO_HW_4758_CCA
das müßte an ein paar Stellen angeglichen werden, um es "sauber" zu deaktivieren,
auf die Schnelle 'no-hw-4758_cca' oder 'no-hw-4758-cca' hilft aber auch.

In welchen Dateien genau meinst Du? Und was ist richtig? Mit _ oder ohne, CCA oder cca?
Ist der Bug grundsätzlich drin oder mit dem Patch gekommen? Blick ich noch nicht ganz

BTW: Was genau macht der Patch, den ich da so blau-äugig drüber laufen lasse?

Nochmal darauf zurückzukommen:

openssl (1.0.1c-3) unstable; urgency=low
* Disable padlock engine again, causes problems for hosts not supporting it.
-- Kurt Roeckx <kurt@roeckx.be> Wed, 06 Jun 2012 18:29:37 +0200

Ok, da wird es ja gesagt: "causes problems for hosts not supporting it".
Das heißt Padlock wurde komplett entfernt, weil keiner die "hosts" bestimmen kann, auf denen es unterstützt wird?

Unter normalem 32bit System sind die Ergebnisse deutlich, es ist da drin und tut auch was es soll.
Beim installieren von AMD64 "von der Stange" ist eben nicht drin, nur die Fehlermeldung.
Plattform-übergreifend deaktiviert kann es also nicht sein.

Die hier von Dir angegebenen Zeilen geben bei mir beim dritten Befehl den Fehler aus, siehe weiter unten.
Ist das selbst gebaut oder wo ist der Unterschied?

Code: Alles auswählen

$ openssl version
OpenSSL 1.0.1c 10 May 2012

$ openssl engine
(dynamic) Dynamic engine loading support

$ openssl engine padlock
(padlock) VIA PadLock (no-RNG, no-ACE)

irgendwie ist es noch "drin", halt nicht aktiv.
Unter 32bit gibt es nur nicht die Fehlermeldung.

Code: Alles auswählen

    $ openssl version
    OpenSSL 1.0.1c 10 May 2012

    $ openssl engine
    (rsax) RSAX engine support
    (dynamic) Dynamic engine loading support

    $ openssl engine padlock
    140118828787368:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521:
    140118828787368:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=padlock

Ich quäle mich noch etwas mit den config-Parametern rum. Muss doch möglich sein das Teil kleiner zu bekommen ...

Vielen Dank für die Unterstützung bisher!

[Ceekay1]

So, ich habs soweit fertig.

Um die Hardware-Padlock-Engine von Via CPUs mit 64Bit in OpenSSL, genauer "openssl-1.0.1c", zu aktivieren, habe ich folgende Schritte unternommen (alles als root auf einem Testsystem):

Den Patch von bugzilla.redhat.com (Credits @Solomon Peachy) nach "/root" kopieren.
Die erste Zeile der .patch Datei anpassen:
von

Code: Alles auswählen

--- openssl-1.0.0a/engines/e_padlock.c	2009-05-12 16:24:23.000000000 -0400

zu

Code: Alles auswählen

--- openssl-1.0.1c/engines/e_padlock.c	2011-06-21 00:00:00.000000000 -0400

Kann sein dass das nicht nötig ist, schien mir aber sinnvoll wegen des Verzeichnisses etc.
Dann copy & paste

Code: Alles auswählen

cd /root
apt-get source openssl
patch -p0 -i openssl-1.0.0-padlock.patch
cd openssl-1.0.1c
./Configure shared no-threads no-rsax no-gost linux-x86_64
make depend
make
make install

Bei ./Configure könnte man noch Debian-like mit den Verzeichnisangaben arbeiten:

Code: Alles auswählen

--prefix=DIR
--openssldir=DIR

Das hab ich aber noch nicht so ganz durchschaut, wo was hin muss.
Ich habe danach also einfach einige der alten openssl-Dateien, die bei "make" neu erstellt wurden, von Hand ersetzt.
IIRC waren das die binary selbst, die lib***.so (im Verzeichnis "engines"), die libcrypto.so.1.0.0 und die libssl.so.1.0.0.
Besonders bei den beiden letzten musste ich mehrfach probieren, bis schließlich und logisch die Dateien im Verzeichnis

Code: Alles auswählen

/usr/lib/x86_64-linux-gnu/

den Erfolg gaben.
Nach einem reboot (alte Windoof-Gewohnheit) habe ich nun folgende Ausgaben:

Code: Alles auswählen

# openssl version
OpenSSL 1.0.1c 10 May 2012
# openssl engine
(dynamic) Dynamic engine loading support
# openssl engine padlock
(padlock) VIA PadLock (no-RNG, ACE)

Sowie:

Code: Alles auswählen

# openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 5304204 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 64 size blocks: 1390913 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 358737 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 90382 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 11323 aes-256-cbc's in 3.00s
OpenSSL 1.0.1c 10 May 2012
built on: Mon Dec 31 01:49:02 CET 2012
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      28383.70k    29672.81k    30612.22k    30850.39k    30919.34k

und zum Vergleich

Code: Alles auswählen

# openssl speed -evp aes-256-cbc -engine padlock
engine "padlock" set.
Doing aes-256-cbc for 3s on 16 size blocks: 9024282 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 7480089 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 256 size blocks: 3637646 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 1024 size blocks: 1188424 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 163149 aes-256-cbc's in 3.00s
OpenSSL 1.0.1c 10 May 2012
built on: Mon Dec 31 01:49:02 CET 2012
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      48129.50k   160108.93k   311450.63k   405648.73k   445505.54k

Für meine Zwecke ist das ausreichend, zumal die binary jetzt 620.119 B groß ist.
Vorher war die natürlich "static" und somit war alles fest drin, daher die Größe.
Jetzt ist sie "shared" - was ja bei einer normalen Installation default ist - und läuft wie sie soll.

Anmerkungen bzgl.

Code: Alles auswählen

--prefix=DIR
--openssldir=DIR

sind sehr willkommen.

Wenn es angebracht ist, den Patch hier hochzuladen (Copyright usw.?) dann mach ich das gern.
Gibt es da irgendwelche Einwände? Wer weiß wie lange der bei redhat noch vorliegt ...

Vielen Dank @rendegast - Du hast mir die Tür gezeigt - und mich durchgeschubst

[derdigge]

Sollte jemand nach mir hier per google landen:
https://romanrm.net/openssl-padlock

so funktioniert ganz prima