AES-NI az OpenSSL-ben vagy kernel-kiszervezés: melyikre van szüksége?

Két címkét használnak úgy, mintha ugyanaz lenne: hardveresen gyorsított és kernelbe kiszervezett. Az egyik azt írja le, milyen utasításokat hajt végre egy könyvtár AES rutinja, a másik azt, hol történik a csomagok feldolgozása. Egy VPN-nek lehet az első a második nélkül, a második az első nélkül, vagy mindkettő egyszerre. Bármely teljesítményre vonatkozó döntésnek azzal kell kezdődnie, hogy megnevezi, melyiket változtatja valójában.

Két tengely, nem egy pontszám

Az első tengely a megvalósítás: az AES-256-GCM-et végző kód a processzor dedikált utasításait használó változathoz kerül, vagy egy hordozható rutinhoz, amely közönséges aritmetikaként hajtja végre azokat. Ez a választás a kriptográfiai könyvtáron belül él, és az inicializálásakor születik meg.

A második tengely az elhelyezés: a csomag a kernel átalakítási útvonalán halad át, vagy egy felhasználói téri démon olvas egy alagút-eszközről, titkosít és visszaír.

Egyik tengely sem korlátozza a másikat. Egy felhasználói téri VPN AES-utasításokkal rendelkező processzoron végig használhatja azokat, és egy kernel-útvonal azok nélküli processzoron szoftveres megvalósításra esik vissza. A szállítói anyagok címkéi ritkán teszik meg ezt a különbséget, ezért a két helyzet között másolt hangolási tanácsok oly gyakran nem tesznek semmit.

Első tengely: melyik kód végzi a titkosítást

Az OpenSSL inicializáláskor felismeri a processzor jellemzőit, és az eredményt optimalizált kódútvonalak választására használja, ahogy az x86 képességek dokumentációja leírja. Az AES-NI az egyik dokumentált képesség e szétosztás mögött. Ebből semmi sem követeli meg, hogy a könyvtár kernel-összetevővé váljon.

Erősítse meg, hogy a jellemző látható a folyamat számára, mielőtt feltételezné, hogy a gyors útvonalat használják. Linuxon a forrás a /proc/cpuinfo flags mezője, és egy vendég belsejében azt tükrözi, amit a hipervizor feltár, nem a fizikai gazdagép modellnevét.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

A második parancs megnevezi az adott buildben betöltött szolgáltatókat. Nem mondja meg, melyik könyvtárhoz linkelte a VPN szolgáltatást, és egy gazdagép hordozhat két OpenSSL-telepítést, miközben a futó folyamat csak az egyiket használja.

Második tengely: hol fut a csomagútvonal

A kernelbeli elhelyezés azt jelenti, hogy az átalakítás a kernel saját IPsec gépezetében vagy a kernelen belüli alagút-illesztőprogramban történik, így a csomagoknak nem kell minden kötegért oda-vissza utazniuk egy felhasználói téri folyamaton. Ez csökkentheti a másolatokat és a kontextusváltásokat, és szétoszthatja a munkát a magok között úgy, ahogy egy egyszálú démon nem tudja. Áthelyezi azokat a számlálókat és nyomokat is, amelyeket olvasni fog, amikor az áteresztőképesség csökken, mert a munka most egy olyan határ túloldalán történik, amelyet nem irányít. Tekintse ezt hibakeresési költségnek, nem csupán teljesítménybeli döntésnek.

Nem hoz létre utasítás-támogatást, nem állít be titkosítást, és nem tesz működőképessé egy meglévő útvonalat.

A virtualizálás ezen a tengelyen is hoz egy redőt. Egy vendég kaphat maszkolt processzormodellt, amely elrejti a gazdagép jellemzőit, és egy beágyazott vendég még kevesebbet láthat. A képesség-nézetet abból a környezetből olvassa ki, ahol a VPN valóban fut, nem a hipervizor konzoljáról.

Mit vásárol az egyes választás, és mit nem tud

A gyakorlati kérdés az, hová megy az idő. Ha egyetlen elfoglalt szál, ismétlődő puffermásolatok vagy csomagonkénti rendszerhívás korlátozza az áteresztőképességet, segíthet az átalakítást olyan útvonalra vinni, amely megszünteti ezeket a költségeket, feltéve hogy a kernel megvalósítja a szükséges átalakítást.

Ha a korlát egy túlterhelt felső kapcsolat, veszteséges útvonal, hosszú oda-vissza idő, telített célzott szolgáltatás vagy egy maghoz rögzített szál, az elhelyezés semmi fontosat nem változtat. Ugyanez igaz az utasításválasztásra: a dedikált hardveren futó AES nem javítja a hiányzó útvonalat, és nem segít, ha az alagút tétlen, mert a névfeloldás meghiúsul.

Ahol mindkettő érvényes, ott összeadódnak. A kernel-útvonal ugyanazt az utasításszintű szétosztást használhatja a kernel kripto API-ján belül, és a jól megválasztott könyvtárral futó felhasználói téri útvonal már használja is. A döntés nem az, melyik gyorsabb elvontan; hanem hogy melyik költségre van bizonyítéka.

Írja fel a négy tényt, mielőtt bármit megváltoztat

Írja fel a szolgáltatás binárisát és a kriptográfiai könyvtárat, amelyhez linkel, mert ezek döntik el az első tengelyt. Utána rögzítse az egyeztetett adatvédelmet, mert a dedikált utasításútvonal nélküli titkosítás másként viselkedik, mint az ilyennel rendelkező, és a készletet mindkét fél választja.

Ezután a képesség-nézet a futó környezet belsejéből, végül az aktív csomagútvonal bizonyítékkal arra, hogy a bekapcsoltnak hitt mód valóban az. Egy betöltött modul nem bizonyítja, hogy egy profil használja, és egy konfigurációs sor nem bizonyítja, hogy a kernel elfogadta.

Változtasson egy dolgot, majd hasonlítsa össze egy konzisztens terheléssel, azonos végpontokkal és azonos átviteli iránnyal. Egy meg nem mért sebességállítás kevesebbet ér, mint egy megjegyzés, hogy a háttér soha nem volt kérdéses.