openrouter.info
http://openrouter.info/forum/

Akceleracja sprzętowa operacji kryptograficznych w Broadcom.
http://openrouter.info/forum/viewtopic.php?f=22&t=634
Strona 1 z 1

Autor:  obsy [ 14 lut 2011, 14:48 ]
Tytuł:  Akceleracja sprzętowa operacji kryptograficznych w Broadcom.

Wielu Was zapewne wie, że układu SoC Broadcoma zawierają w sobie wbudowany sprzętowy akcelerator operacji kryptograficznych. Do jego obsługi wymagany jest sterownik ubsec_ssb, który zawarty jest w obecnych wydaniach OpenWrt. Korzysta zaś z niego biblioteka openssl dzięki czemu można przyspieszyć niektóre operacje.
W odpowiednią wersję układu SoC wyposażony jest np. staruszek Asus WL-500g Premium. Podobne rozwiązanie oferuje Geode (stosowany w płytach Alix) lub VIA. Dostępna jest także oddzielna karta minipci Soekris Engineering vpn1411. Nie ma go natomiast w Atherosach (TP-Linkach czy Ubiquiti).

Ogólny sterownik w OpenWrt został przeportowany z *BSD. W przypadku biblioteki libopenssl podczas kompilacji musi być zaznaczona specjalna opcja, dzięki czemu będzie możliwe wykorzystanie nowego engine przez openssl i tym samym przyśpieszenie operacji. Wymagana opcja nazywa się CONFIG_OPENSSL_ENGINE, po jej zaznaczeniu zostanie skompilowany także pakiet kmod-ocf-ubsec-ssb zawierający moduł ubsec_ssb.ko. On jest właściwym sterownikiem dla rdzenia IPSEC zawartego w Broadcomach.

Po udanej kompilacji i instalacji obrazu należy sprawdzić czy w logach (logread) pojawia się informacja typu:
Sentry5(tm) ROBOGateway(tm) IPSec Core at IRQ 2
ubsec_ssb: DES 3DES AES128 AES192 AES256 MD5_HMAC SHA1_HMAC

Jeżeli dodatkowo istnieje urządzenie /dev/crypto - nasz system ma wsparcie dla sprzętowego przyśpieszenia operacji kryptograficznych. Dla pewności można jeszcze sprawdzić czy openssl widzi nowy engine:
root@OpenWrt:/tmp#  openssl engine -t
(cryptodev) BSD cryptodev engine
     [ available ]
(dynamic) Dynamic engine loading support
     [ unavailable ]
root@OpenWrt:/tmp# openssl engine -c
(cryptodev) BSD cryptodev engine
 [RSA, DSA, DH, RC4, AES-128-CBC, AES-192-CBC, AES-256-CBC]
(dynamic) Dynamic engine loading support
root@OpenWrt:/tmp#

Testy openssl pokazują różnicę z wykorzystaniem tego modułu oraz bez niego:
root@OpenWrt:/tmp# rmmod ubsec_ssb
root@OpenWrt:/tmp# openssl speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
[...]
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 bytes
aes-128-cbc       1779.28k     6100.11k    29301.33k   322355.20k    97075.20k
root@OpenWrt:/tmp# ismod ubsec_ssb
root@OpenWrt:/tmp# openssl speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
[...]
type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 bytes
aes-128-cbc       2623.13k     7744.00k    31645.54k    92891.43k   130241.42k
root@OpenWrt:/tmp#

No dobrze, można spytać w takim razie jakie ma to zastosowanie praktycznie? Jeżeli korzystamy np. z tunelu openvpn można osiągnąć większą przepustowość łącza. Korzystając z transmission możemy oczekiwać mniejszego obciążenia systemu przy korzystaniu z szyfrowanych połączeń. Aby pokazać rzeczywistą różnicę, wykonanłem testy kopiowania 10MB pliku do routera (Asusie WL-500gP ) przez scp korzystając z określonego algorytmu. openssh-server został uruchomiony na porcie 222.

Bez załadowanego modułu ubsec_ssb:

$ time scp -c aes128-cbc -P222 plik.bin root@192.168.1.1:/tmp
root@192.168.1.1's password:
plik.bin                                       100%   10MB   1.4MB/s   00:07   

real   0m10.521s
user   0m0.152s
sys   0m0.024s
$ time scp -c aes128-cbc -P222 plik.bin root@192.168.1.1:/tmp
root@192.168.1.1's password:
randomfile                                       100%   10MB   1.4MB/s   00:07   

real   0m10.361s
user   0m0.144s
sys   0m0.032s
$ time scp -c aes128-cbc -P222 plik.bin root@192.168.1.1:/tmp
root@192.168.1.1's password:
plik.bin                                       100%   10MB   1.7MB/s   00:06   

real   0m10.322s
user   0m0.148s
sys   0m0.028s

Z załadowanym modułem ubsec_ssb:
$ time scp -c aes128-cbc -P222 plik.bin root@192.168.1.1:/tmp
root@192.168.1.1's password:
plik.bin                                       100%   10MB   2.0MB/s   00:05     

real   0m7.398s
user   0m0.164s
sys   0m0.020s
$ time scp -c aes128-cbc -P222 plik.bin root@192.168.1.1:/tmp
root@192.168.1.1's password:
plik.bin                                       100%   10MB   2.5MB/s   00:04   

real   0m7.303s
user   0m0.144s
sys   0m0.036s
$ time scp -c aes128-cbc -P222 plik.bin root@192.168.1.1:/tmp
root@192.168.1.1's password:
plik.bin                                       100%   10MB   2.5MB/s   00:04   

real   0m7.359s
user   0m0.160s
sys   0m0.016s

Czyli zastosowanie tego rozwiązanie przyniosło realny zysk w postaci zwiększenia transferu na poziomie 1MB/s, co daje ponad 50%! Dla mało wydajnego systemu jakim jest platforma zastosowana w Asusie to naprawdę dużo.

Z takiego przyśpieszenia będą korzystały programy skompilowane z libopenssl, więc np. openssh-serwer, transmission, rotrrent czy openvpn. Nie będzie korzystał z niego natomiast standardowo instalowany dropbear (nie jest kompilowany z openssl).

Oto kolejny powód, aby porzucić jądra 2.4 na rzecz nowego, 2.6 w broadcomach.

Autor:  obsy [ 17 gru 2011, 18:57 ]
Tytuł:  Re: Akceleracja sprzętowa operacji kryptograficznych w Broad

Małe info: w repozytorium openssl pojawiły się łatki dla aes na platformę mips napisane w asemblerze. Platforma ar71xx sprzętowego akceleratora nie ma, ale z takimi łatkami pozwala na zwiększenie wydajności o 5-8%. Zawsze coś.

Strona 1 z 1 Strefa czasowa UTC+1godz. [letni]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/