Vývojáři z Cloudflare o práci na optimalizaci výkonu šifrování disku v jádře Linuxu. V důsledku toho se připravili pro subsystém a Crypto API, které více než zdvojnásobily propustnost pro čtení a zápis v syntetickém testu a také snížily latenci na polovinu. Při testování na skutečném hardwaru se režie ze šifrování snížila téměř na úroveň pozorovanou při práci s diskem bez použití šifrování dat.
Cloudflare používá dm-crypt k šifrování dat na discích používaných k ukládání obsahu do mezipaměti na CDN. Dm-crypt funguje na úrovni blokového zařízení a šifruje požadavky na zápis I/O a dešifruje požadavky na čtení, přičemž funguje jako vrstva mezi blokovým zařízením a ovladačem systému souborů.
Vyhodnotit výkon dm-crypt pomocí balíčku Byla měřena rychlost práce se šifrovanými a nešifrovanými oddíly na RAM disku umístěném v RAM, aby se eliminovaly výkyvy výkonu disku a zaměřil se na výkon kódu. U nešifrovaných oddílů byl výkon čtení a zápisu udržován na 1126 MB/s, ale když bylo povoleno šifrování, rychlost se snížila 7 v čase a činil 147 MB/s.
Zpočátku existovalo podezření na použití neefektivních algoritmů v kryptosystému jádra. Testy však používaly nejrychlejší algoritmus aes-xts s 256 šifrovacími klíči, jehož výkon při spuštění „benchmarku šifrování“ je více než dvakrát vyšší než výsledek získaný při testování disku RAM. Experimenty s příznaky dm-crypt pro ladění výkonu nepřinesly žádný výsledek: při použití příznaku „--perf-same_cpu_crypt“ se výkon dokonce snížil na 136 MB/s, a když byl příznak „--perf-submit_from_crypt_cpus“ specifikováno, zvýšila se pouze na 166 MB/s.
Hlubší analýza logiky práce ukázala, že dm-crypt není tak jednoduchý, jak se zdá - když je přijat požadavek na zápis z ovladače FS, dm-crypt jej nezpracuje okamžitě, ale zařadí jej do fronty „kcryptd“ , který není analyzován okamžitě, ale ve vhodném okamžiku. Z fronty je požadavek odeslán do Linux Crypto API k provedení šifrování. Ale protože Crypto API používá asynchronní model provádění, šifrování se také neprovádí okamžitě, ale obchází další frontu. Po dokončení šifrování se může dm-crypt pokusit seřadit nevyřízené požadavky na zápis pomocí vyhledávacího stromu . Na konci samostatné vlákno jádra opět s určitým zpožděním vyzvedne nahromaděné I/O požadavky a odešle je do zásobníku blokových zařízení.
Při prvním čtení přidá dm-crypt do fronty „kcryptd_io“ požadavek na získání dat z disku. Po nějaké době se data zpřístupní a umístí do fronty „kcryptd“ pro dešifrování.
Kcryptd odešle požadavek do Linux Crypto API, které dešifruje informace asynchronně. Požadavky neprocházejí vždy všemi frontami, ale v nejhorším případě se požadavek na zápis usadí ve frontách až 4krát a požadavek na čtení až 3krát. Každý zásah ve frontě přináší zpoždění, která jsou hlavním důvodem výrazného snížení výkonu dm-crypt.
Použití front je způsobeno potřebou pracovat v podmínkách přerušení. V roce 2005, kdy byl implementován současný model dm-crypt založený na frontě, nebylo rozhraní Crypto API ještě asynchronní. Po převedení Crypto API na asynchronní exekuční model se začala uplatňovat v podstatě dvojí ochrana. Fronty byly také zavedeny, aby se ušetřila spotřeba zásobníku jádra, ale po jeho zvýšení v roce 2014 ztratila data optimalizace svou relevanci. Byla zavedena další fronta „kcryptd_io“, aby se překonalo úzké místo, které způsobuje čekání na přidělení paměti, když přichází velký počet požadavků. V roce 2015 byla navíc zavedena fáze třídění, protože požadavky na šifrování na víceprocesorových systémech mohly být dokončeny mimo pořadí (místo sekvenčního přístupu na disk byl přístup prováděn v náhodném pořadí a plánovač CFQ nefungoval efektivně). V současnosti třídění u SSD ztratilo smysl a plánovač CFQ se v jádře již nepoužívá.
Vzhledem k tomu, že moderní disky se staly rychlejšími a chytřejšími, systém alokace zdrojů v jádře Linuxu byl revidován a některé subsystémy byly přepracovány, inženýři Cloudflare dm-crypt má nový způsob provozu, bez použití zbytečných front a asynchronních volání. Režim je povolen samostatným příznakem „force_inline“ a přináší dm-crypt do podoby jednoduché proxy, která šifruje a dešifruje příchozí požadavky. Interakce s Crypto API byla optimalizována explicitním výběrem šifrovacích algoritmů, které pracují v synchronním režimu a nepoužívají fronty požadavků. Pro synchronní práci s Crypto API bylo modul, který umožňuje použít FPU / AES-NI pro zrychlení a přímo předává požadavky na šifrování a dešifrování.
Výsledkem je, že při testování RAM disku se nám podařilo více než zdvojnásobit výkon dm-crypt – výkon vzrostl z 294 MB/s (2 x 147 MB /s) na 640 MB/s, což je velmi blízko na výkon holého šifrování (696 MB/s).
Při zátěžovém testování na reálných serverech vykazovala nová implementace výkon velmi blízký konfiguraci běžící bez šifrování a povolení šifrování na serverech s mezipamětí Cloudflare nijak neovlivnilo rychlost odezvy. V budoucnu Cloudflare plánuje vydat připravené záplaty do hlavního linuxového jádra, ale předtím je bude nutné přepracovat, protože jsou optimalizovány pro určitou zátěž a nepokrývají všechny oblasti aplikace, například šifrování na nízké úrovni -napájení vestavěných zařízení.
Zdroj: opennet.ru