DS112j hardware encryption engine

[Xennex]

Maar de engine cryptodev kan nog steeds niet aangesproken worden:

Code: [Selecteer]

$ /usr/syno/bin/openssl engine cryptodev
WARNING: can't open config file: /usr/syno/ssl/openssl.cnf
1073868240:error:25066067:lib(37):func(102):reason(103):NA:0:filename(/usr/syno/lib/engines/libcryptodev.so): /usr/syno/lib/engines/libcryptodev.so: cannot open shared object file: No such file or directory
1073868240:error:25070067:lib(37):func(112):reason(103):NA:0:
1073868240:error:260B6084:lib(38):func(182):reason(132):NA:0:
1073868240:error:2606A074:lib(38):func(106):reason(116):NA:0:id=cryptodev
des-cbc is sneller bij de /opt versie:

Code: [Selecteer]

evp               7321.34k     8340.29k     8687.07k     8718.77k     8848.43k
Wat langzamer bij /usr/syno/bin:

Code: [Selecteer]

evp               6129.99k     7507.20k     7944.34k     8084.55k     8165.43k
En net zo snel met of zonder -evp:

Code: [Selecteer]

des cbc           7076.07k     7857.47k     7990.68k     8061.22k     8262.37k
De snelste tot nu toe was /usr/syno/bin/openssl ZONDER -evp.

En -engine cryptodev is nog niet gelukt.

[Ben(V)]

Jij zit twee levels hoger te testen dan waar die hardware ondersteunde encryption werkt.

In de instructieset van de cpu's heeft intel een aantal instructies opgenomen die gebruikt kunnen worden door software libraries.
Uiteraard hebben andere cpu fabrikanten die overgenomen.
Sommige cpu's realiseren dat gewoon in microcode(dus software in de chip) en andere cpu's hebben er extra hardware voor.
Er is geen enkele manier om te kiezen tussen de een en de ander, want het zit in de cpu ingebakken.

Wat jij aan het testen bent is het effect van verschillende compiler flags die gebruikt kunnen worden als je een cpu hebt die de instructieset niet heeft.
Je emuleert daarmee op software niveau wat anders door de cpu gedaan wordt, zonder externe software en de bijbehorende vertragingen.

[Xennex]

Jij zit twee levels hoger te testen dan waar die hardware ondersteunde encryption werkt.

Ik probeer het gewoon aan te zetten op het niveau waar het aan kan gaan, om te kijken of dat verschil maakt, of ik probeer het uit te zetten om te kijken of het verschil maakt.

Ik weet bijna zeker dat eCryptFS het al gebruikt.

Maar OpenSSL niet en dat is voor OpenVPN. Daar was ik alleen nog naar aan het kijken.

Ook was ik nog geïnteresseerd in ccrypt en ik weet vrij zeker dat die geen libraries gebruikt omdat ik een keer in een source code heb zitten rondneuzen en die deed de AES calls zelf.

In de instructieset van de cpu's heeft intel een aantal instructies opgenomen die gebruikt kunnen worden door software libraries.

Ja en de Linux kernel doet dat met OCF.

Uiteraard hebben andere cpu fabrikanten die overgenomen.

Ik denk niet dat ARM dat gedaan heeft.

Sommige cpu's realiseren dat gewoon in microcode(dus software in de chip) en andere cpu's hebben er extra hardware voor.

Ik denk niet dat ARM (v5) ia-aes emulatie heeft.

Er is geen enkele manier om te kiezen tussen de een en de ander, want het zit in de cpu ingebakken.

Ja maar je moet het wel eerst nog gebruiken door de software libraries.

Ik ben aan het testen of ze dat doen.

Wat jij aan het testen bent is het effect van verschillende compiler flags die gebruikt kunnen worden als je een cpu hebt die de instructieset niet heeft.

Niet waar.

Het klopt dat ARM die IA-AES set niet heeft en dat OpenSSL dit direct gebruikt; en het is zo dat ARM v7 een eigen set heeft, wat OpenSSL kan gebruiken, maar ARM v 5 heeft beide niet.

ARMv5 heeft wel iets dat ondersteund wordt door de Linux kernel.

Hoe efficiënt het gebruik daarvan is weet ik niet (vanwege die context switches).

Je emuleert daarmee op software niveau wat anders door de cpu gedaan wordt, zonder externe software en de bijbehorende vertragingen.

Da's niet waar. Cryptodev is geen software-emulatie-library. Het is een hardware-acceleratie-toegangs-library.

Die 'libraries' waar je het over hebt zijn wel een laag van indirectie maar het maakt het mogelijk dat slecht ondersteunde CPUs zoals bijvoorbeeld die ARMv5 toch ondersteund kunnen worden door bijv. OpenSSL.

Het is inderdaad zo dat bijv. die Intel CPUs dat dan niet nodig hebben omdat OpenSSL het dan direct doet.

Maar omdat OpenSSL geen ondersteuning heeft voor deze chip direct, maar wel via OCF of cryptodev of whatever het is,

probeer ik te kijken of het aan staat en of ik het uit kan zetten.

Het is vrij duidelijk dat de verschillende versies van OpenSSL en de verschillende flags nu al grote verschillen laten zien.

Dus ik weet niet wat je precies bedoelde met emulatie, maar de software emuleert niet hardware chips. Als de hardware chip er niet is, wordt er niks geëmuleerd. Het wordt gewoon direct in software uitgevoerd. (De berekeningen).

[Ben(V)]

Als je mijn link gelezen had dan had je daarin kunnen lezen dat al vanaf de A10 serie the ARM processoren de AES instructieset ondersteunen.

[Xennex]

Als je mijn link gelezen had dan had je daarin kunnen lezen dat al vanaf de A10 serie the ARM processoren de AES instructieset ondersteunen.

Ik weet niet wat A10 te maken heeft met Marvell Kirkwood.

Ik weet niet alles van ARM.

The commands in these architectures are not directly compatible with the AES-NI commands, but implement similar functionality.

Je hebt het gewoon verkeerd, meneer. Dat was een referentie naar o.a. ARM v8.

VIA x86 CPUs, AMD Geode, and Marvell Kirkwood (ARM, mv_cesa in Linux) use driver-based accelerated AES handling instead.

Uit niets blijkt dat ze "gewoon" AES-NI kunnen doen.

Uit alles blijkt gewoon dat Kirkwood die driver nodig heeft.

[Ben(V)]

Je hebt gelijk de Kirkwood is een ARM V5 en heeft geen AES ondersteuning in hardware noch in microcode.
Dit is dus een geval dat er een driver nodig is.

[Xennex]

Nou dank je wel.

Maar voor ARM v8 gebruikt OpenSSL weer een andere vlag dus gebruikt ook eigen instructies en niet die van intel.

Ik kan even de pagina niet terugvinden maar voor ARM v8 gebruik je (of gebruikt OpenSSL) de "Neon" instructies, dus geen Intel.

Code: [Selecteer]

OPENSSL_armcap=0 openssl ....

NEON technology was introduced to the Armv7-A and Armv7-R profiles. It is also now an extension to the Armv8-A and Armv8-R profiles.

Het wordt ook gebruikt voor encryptie maar heeft duidelijk niets te maken met de Intel codes.