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.