Synology-Forum.nl
Hardware ondersteuning => NAS hardware vragen => Topic gestart door: Xennex op 16 oktober 2017, 14:41:56
-
Hoi,
Ik dacht altijd dat ik met mijn DS112j geen "hardware encryption engine" had maar nu blijkt dit verkeerd.
Maar mijn vraag is: merk ik er wel wat van?
Ik weet dat het een trage CPU is (1GHz) maar normale transfers zijn ca. 35MB/s upload en met encryptie is dat ca. 7MB/s maximaal.
Is dit normaal?
-
DSM Help:
Waarom wordt de bestandsoverdracht trager wanneer de gedeelde map gecodeerd is?
Het is normaal dat gecodeerde gedeelde mappen langzamere bestandsoverdrachtsnelheden hebben. Codering kan de CPU-werklast aanzienlijk verhogen en de bestandsoverdrachtsnelheid verlagen.
Voor een verbeterde capaciteit kunt u de voorkeur geven aan een Synology NAS met een hardwarecoderingsengine:
Jouw DS heeft "Hardware Encryption Engine" dus, je kunt zeggen, je hebt wel een "verbeterde capaciteit" echter, denk dat de J-Versie, ondanks dat het geen CPU kracht kost, het wel zal merken, zoals je het al ondervindt.
-
Jouw DS heeft "Hardware Encryption Engine" dus, je kunt zeggen, je hebt wel een "verbeterde capaciteit" echter, denk dat de J-Versie, ondanks dat het geen CPU kracht kost, het wel zal merken, zoals je het al ondervindt.
Hoe kan ik er überhaupt achter komen of die engine gebruikt wordt?
Heeft u enig idee welke instructies er dan voor gebruikt worden?
Zouden andere tools zoals gewone encryptieprogrammaatjes zoals "ccrypt" er ook baat bij hebben?
-
Alle software die gebruikt maakt van AES encryption gebruikt die hardware, als die hardware er niet is worden de calls naar de encryption engine automatisch in software gedaan.
Voorbeelden zijn SSL, VPN en disk encryption.
Het is nauwelijk sneller dan de software variant en aangezien het altijd om het en/de crypten van streams gaat zal het nooit de performance beinvloeden, want de cpu is altijd vele malen sneller als die steams dus ook met software encryption.
Het enige echte voordeel is dat het niet te hacken is omdat het nu eenmaal in hardware zit.
Verder is het voornamelijk een intel marketing verhaal.
-
De pdf van de SOC/CPU staat hier:
https://wikidevi.com/files/Marvell/88F6281.pdf
Mijn vermoeden is al heel lang dat de engine alleen aangesproken wordt voor encrypted backup.
Dit gebeurt zover ik weet middels OCF in kernel.
Hoe kan ik er überhaupt achter komen of die engine gebruikt wordt?
Op de CLI kun je met
htop -d 20kijken wat er gebeurt. "-d 20" staat voor elke 2 seconden verversen.
Met F2 kun je kolommen e.d. aanpassen.
-
Alle software die gebruikt maakt van AES encryption gebruikt die hardware, als die hardware er niet is worden de calls naar de encryption engine automatisch in software gedaan.
Welke instructie zou het zijn? Ik kan wel iets ...disassemblen om te zien of die calls er in staan.
Voorbeelden zijn SSL, VPN en disk encryption.
Maar disk encryption ... disk performance is veel sneller dan 7MB/s toch.
Het is nauwelijk sneller dan de software variant en aangezien het altijd om het en/de crypten van streams gaat zal het nooit de performance beinvloeden, want de cpu is altijd vele malen sneller als die steams dus ook met software encryption.
Ik bedoel op mijn NAS gebruikt SSH en VPN ook flink wat CPU.
Als ik encryptie uit zet op VPN is het processorgebruik een stukje lager (niet enorm).
Maar het maakte wel verschil, ik weet niet meer hoeveel.
Het was wel denk ik minstens 20% minder CPU door VPN.
(20% op wat het gebruikte).
Het enige echte voordeel is dat het niet te hacken is omdat het nu eenmaal in hardware zit.
Right.
Verder is het voornamelijk een intel marketing verhaal.
Maar dit is ARM. Hebben die dezelfde instructies?
Ik geloof je wel als je zegt dat het niet sneller is dan software.
-
Mijn vermoeden is al heel lang dat de engine alleen aangesproken wordt voor encrypted backup.
Dit gebeurt zover ik weet middels OCF in kernel.
Dat klinkt wel erg goed:
At this point in time OCF-Linux provides acceleration for OpenSwan, OpenSSL, OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key operations and adds randomness to the kernels /dev/random by utilising the RNG hardware. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop.
Dan kan ik er misschien wel achterkomen of dit gebruikt wordt...
Bijv. "ccrypt" moet ten eerste deze kernel interface gebruiken en daarna moet het worden aangesproken, maar misschien kan je wel informatie over het OCF-subsysteem opvragen...
Hetzelfde geldt voor eCryptFS (dat is natuurlijk het belangrijkste voor de Synology).
-
http://www.marvell.com.cn/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf (http://www.marvell.com.cn/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf)
Hier staat de ondersteunde hardware (pagina 175).
Er zijn 4 engines:
- md5
- des
- aes128
- aes128
Toen ik ooit LUKS aan het testen was was Blowfish (96 bit) een stuk sneller dan aes 128, wat vreemd zou zijn als aes 128 geaccelereerd zou worden... :-/.
Wel was het zo dat aes128 met 256 bit sleutels niet bijzonder langzamer was dan aes128 met 128 bit sleutels.
Dit is de encryptie module in the kernel:
/lib/modules/cesa_ocf_drv.ko
Hij is wel geladen dus dat zit in elk geval goed:
$ lsmod | grep cesa
cesa_ocf_drv 7063 0
cesa_dev 1977 0
ocf 17404 4 cryptosoft,ecryptfs,cesa_ocf_drv,cryptodev
Dus het lijkt vrij duidelijk dat het zou moeten werken.
$ cat /proc/interrupts
CPU0
1: 52856176 - kw_tick
11: 5492715 - mv_ethernet
19: 27 - ehci_hcd:usb1
21: 200210 - sata_mv
22: 413145 - cesa
33: 172 - serial
34: 35 - serial
Err: 0
-
Dus zo te zien werkt dat gewoon.
Speculatieve post uit 2010:
https://www.spinics.net/lists/linux-crypto/msg27836.html (https://www.spinics.net/lists/linux-crypto/msg27836.html)
Dus ik denk dat ik me nergens om zorgen maak maar dat het gewoon niet zo snel is.
In elk geval als ik encryptie gebruik zal ik AES128 met 128, 192 of 256 bit keys moeten gebruiken.
Bedankt voor de antwoorden.
-
Ik moet natuurlijk met het voorbeeld OpenVPN komen ;), kijk eens naar mijn afbeelding.
(https://www.synology-forum.nl/vpn-server/openvpn-'redirect-gateway-def1'-werkt-niet-met-gecomprimeerde-data-overdracht/?action=dlattach;attach=35968)
OpenVPN maakt (standaard) gebruik van OpenSSL voor crypto taken. OpenSSL vanaf versie 1.0.0 zal AES-NI capabele hardware automatisch detecteren waardoor er, zoals het voorheen was, geen engine in de config aangegeven hoeft te worden. Een engine kan overigens ook acceleratie code in kernel zijn.
Dat het niet sneller is kan niet zo eenvoudig gesteld worden.
Op recente hardware die b.v. Intel AES-NI ondersteund, of het equivalent van andere merken, kan het wel degelijk uitmaken. Uit de afbeelding kun je ook opmaken dat het zo goed als altijd beter is OpenSSL`s ingebouwde instructies te gebruiken vanwege minder context switching. Dit geldt algemeen ook voor andere applicaties.
Op mijn N3150 bordje met Debian:
Met het volgende commando maakt OpenSSL geen gebruik van h.w. crypto support:
env OPENSSL_ia32cap=0 openssl speed -elapsed -evp aes-256-cbc -multi 8
evp 97659.74k 117140.11k 123383.16k 307494.50k 339199.79k
OpenSSL met h.w. crypto support:
openssl speed -elapsed -evp aes-256-cbc -multi 8
evp 618920.09k 882027.93k 1003271.00k 1041262.20k 1150214.31k
Het is echter nog heel wat gecompliceerder waardoor deze waarden niet 1-2-3 met elkaar vergelijkbaar zijn. Dat heeft te maken met het systeem waarop de test plaatsvindt, de configuratie, gebruikte ciphers/type encryptie, enz.
-
https://en.wikipedia.org/wiki/AES_instruction_set
Alle huidige cpu's ondersteunen dit.
De ene in microcode, de andere met hardware en sommige geheel in software(extra drivers).
Het maakt allemaal niet veel verschil, zoals ik al zei.
Uiteraard heeft het niets te maken met het verschil in cpu gebruik bij het al of niet aanzetten van encryptie.
Je kunt nooit het verschil meten want op dat niveau kun je de hardware encryptie niet uitzetten en iets anders gebruiken.
-
Het verschil in mijn voorbeeld wordt duidelijk doordat de resultaten, hierboven gepost, laten zien dat in dezelfde tijd meer crypto operaties plaatsvinden.
-
Uiteraard is dat geen vergelijk.
Je vergelijkt appel met peren.
Zoals ik al zei het verschil tussen hardware en software encryptie zit in ofwel hardware in de cpu ofwel microcode die in de cpu zit, dat kun je toch niet gaan vergelijk met het niet gebruiken van de AES instructieset
Dan kun je het ook wel gaan vergelijken met het op de rekenmachine met de hand uitrekenen.
-
evp 6011.47k 6732.55k 6893.41k 6901.76k 6996.69k
Dat was het hardware commando.
For ARM there are two possible optimization levels:
1. Without NEON
2. With NEON (ARM7 only)
Boo?
Een post uit 2009 (http://openssl.6102.n7.nabble.com/AES-hardware-accelerator-in-OpenSSL-with-without-OCF-td32308.html) geeft aan dat OpenSSL "libcryptodev" nodig heeft, maar...
$ OPENSSL_armcap=0 openssl speed -elapsed -evp aes-256-cbc -multi 8 -engine cryptodev
invalid engine "cryptodev"
23570:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:162:filename(/opt/lib/engines/libcryptodev.so): /opt/lib/engines/libcryptodev.so: cannot open shared object file: No such file or directory
Maar iemand zegt weer dat de engine al ingebakken zit:
libcryptodev.so? Why? It's builtin into openssl, you don't even need the
extra engines option, it's taken care of when building openssl with
cryptodev support in buildroot.
Als ik -evp weg haal:
aes-256 cbc 6269.79k 6796.48k 6920.08k 6934.01k 7044.51k
Geen verschil eigenlijk.
Maar ik krijg geen debug output in /var/log/messages als ik:
# echo 1 > /sys/module/cryptosoft/parameters/swcr_debug
Maar meer nog denk ik niet dat openssl met cryptodev is gebouwd:
options: bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) idea(int) blowfish(ptr)
compiler: /home/slug/optware/cs08q1armel/toolchain/arm-2008q1/bin/arm-none-linux-gnueabi-gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -pipe -I/home/slug/optware/cs08q1armel/staging/opt/include -DTERMIO -O3 -fomit-frame-pointer -Wall
Dit is echter wel in /opt...
Waaat, de inbgebouwde is nieuwer en beter:
options: bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) idea(int) blowfish(ptr)
compiler: /usr/local/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ccache-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DOPENSSL_NO_ERR -I/usr/local/arm-none-linux-gnueabi/include -DSYNO_MARVELL_88F6281 -O2 -I/usr/syno/include -g -DSYNO_PLATFORM=MARVELL_88F6281 -DL_ENDIAN -DTERMIO -Os -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/syno/fips//include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
Euhm, okay:
evp 4836.78k 5710.98k 5976.59k 6037.56k 6093.40k
Dat is langzamer dan hiervoor...
Maar zonder de -evp (Ik weet niet of dat nuttig is):
aes-256 cbc 9057.94k 10289.41k 10681.31k 10724.04k 10923.55k
-
Zoals ik al zei het verschil tussen hardware en software encryptie zit in ofwel hardware in de cpu ofwel microcode die in de cpu zit, dat kun je toch niet gaan vergelijk met het niet gebruiken van de AES instructieset
Ben ik weet eerlijk gezegd niet waar je het over hebt.
Maar summary van mij:
- /opt OpenSSL gebruik van -evp vlag maakt niks uit en laatste getal: 7000k
- /usr/syno/bin OpenSSL: met -evp langzamer at 6000k en zonder -evp sneller at 10000k.
Ik weet dus niet wat OpenVPN gebruikt.
Maar dat is de Synology versie:
$ ldd /usr/sbin/openvpn
libssl.so.1.0.0 => /lib/libssl.so.1.0.0 (0x40026000)
Terwijl SSHD weer de /opt versie gebruikt:
$ ldd /opt/sbin/sshd
libcrypto.so.0.9.8 => /opt/lib/libcrypto.so.0.9.8 (0x40026000)
Buuu.
-
Maar de engine cryptodev kan nog steeds niet aangesproken worden:
$ /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:
evp 7321.34k 8340.29k 8687.07k 8718.77k 8848.43k
Wat langzamer bij /usr/syno/bin:
evp 6129.99k 7507.20k 7944.34k 8084.55k 8165.43k
En net zo snel met of zonder -evp:
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
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.
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.