← Cloudflare Workers / workers / reference

Bezpečnostní model

Tento článek obsahuje přehled bezpečnostní architektury Cloudflare a poté se věnuje dvěma často kladeným otázkám: chybám V8 a Spectre.

Bezpečnost byla vysokou prioritou od samého začátku projektu Workers: již od počátku panovala obava, že při hostování velkého množství tenantů na sdílené infrastruktuře budou různé druhy postranních kanálů představovat hrozbu. Cloudflare Workers runtime je pečlivě navržen tak, aby útokům postranními kanály odolal.

Za tímto účelem je Workers navržen tak, aby kód nemohl lokálně měřit dobu svého vlastního běhu. Například hodnota, kterou vrací Date.now() zůstává během provádění kódu neměnný. Žádné jiné časovače nejsou k dispozici. Cloudflare navíc neposkytuje přístup k souběžnosti (například vícevláknovému zpracování), protože by to útočníkům umožnilo sestavit vlastní časovače. Tato návrhová rozhodnutí nelze zpětně zavést do jiných platforem, jako jsou webové prohlížeče, protože by to odstranilo rozhraní API, na kterých existující aplikace závisí. Ve Workers byla možná pouze díky návrhovým rozhodnutím běhového prostředí od samého počátku.

Tato raná návrhová rozhodnutí se osvědčila, Cloudflare ale nadále přidává další vrstvy zabezpečení, včetně technik, které narušují útoky přeplánováním Workerů, čímž vytváří další úroveň izolace mezi podezřelými Workery a Workery s vysokou hodnotou.

Přístup Workers se výrazně liší od přístupu, který zvolila většina odvětví. Je odolný vůči celé škále Útoky typu Spectre ↗, aniž by bylo nutné věnovat zvláštní pozornost každému z nich a aniž by bylo nutné obecně blokovat spekulativní provádění. Protože je však přístup Workers jiný, vyžaduje důkladné zkoumání. Cloudflare v současnosti spolupracuje s výzkumníky z Graz University of Technology (TU Graz) na zkoumání toho, co již bylo zjištěno. Mezi tyto výzkumníky patří i někteří z těch, kteří původně objevili zranitelnost Spectre. Cloudflare výsledky tohoto výzkumu zveřejní, jakmile budou k dispozici.

Podrobnosti uvádí tato přednáška ↗ od Kentona Vardy, architekta Cloudflare Workers. Spectre je popsán ke konci.

Začneme rychlým přehledem architektury runtime Workers:

Návrh sandboxu pro kód má dvě základní části: zabezpečenou izolaci a návrh API.

Nejprve bylo nutné vytvořit zabezpečené spouštěcí prostředí, ve kterém kód nemá přístup k ničemu, k čemu přístup mít nemá.

K tomu slouží především V8, JavaScript engine, který Google vyvinul pro použití v Chromu. V8 spouští kód uvnitř isolates, které danému kódu brání v přístupu k paměti mimo daný isolate, a to i v rámci stejného procesu. To především znamená, že Cloudflare dokáže v rámci jediného procesu spouštět mnoho isolates. To je zásadní pro platformu edge compute, jakou jsou Workers, kde Cloudflare musí na každém stroji hostovat tisíce cizích aplikací a tisíckrát za sekundu mezi nimi rychle přepínat s minimální režií. Kdyby Cloudflare musel pro každou aplikaci spouštět samostatný proces, počet zákazníků, které by mohl podporovat, by se drasticky snížil a Cloudflare by musel edge compute omezit jen na malý počet velkých Enterprise zákazníků. Díky technologii isolates může Cloudflare zpřístupnit edge compute úplně všem.

Někdy se ale Cloudflare přesto rozhodne naplánovat Worker do vlastního privátního procesu. Dělá to tehdy, když Worker používá funkce vyžadující dodatečnou vrstvu izolace. Když si například vývojář pomocí ladicího nástroje devtools prohlíží svůj Worker, Cloudflare tento Worker spustí v samostatném procesu. Je to proto, že protokol inspectoru byl v prohlížeči historicky dostupný jen důvěryhodnému operátorovi prohlížeče, a proto neprošel tak důkladnou bezpečnostní kontrolou jako zbytek V8. Aby Cloudflare omezil zvýšené riziko chyb v protokolu inspectoru, přesouvá zkoumané Workery do samostatného procesu s izolací na úrovni procesu. Cloudflare využívá izolaci procesů také jako další obranu proti Spectre.

I izoláty, které běží ve sdíleném procesu s dalšími izoláty, u toho nejsou výjimkou: Cloudflare navíc na každém stroji spouští několik instancí celého runtime, čemuž se říká cordons. Workery jsou mezi cordons rozdělovány tak, že se každému Workeru přiřadí úroveň důvěryhodnosti a méně důvěryhodné Workery se oddělují od těch důvěryhodnějších. Jako příklad: zákazník na plánu Free nebude nikdy naplánován do stejného procesu jako zákazník na plánu Enterprise. Díky tomu vzniká určitá hloubková obrana pro případ, že by se ve V8 objevila bezpečnostní zranitelnost typu zero-day.

Na úrovni celého procesu uplatňuje Cloudflare pro důkladnější obranu ještě další vrstvu sandboxingu. Sandbox druhé vrstvy využívá jmenné prostory Linuxu (namespaces) a seccomp pro zakázání veškerého přístupu k souborovému systému a síti. Namespaces a seccomp se běžně používají k implementaci kontejnerů. Cloudflare ale tyto technologie využívá mnohem přísněji, než je obvykle možné u kontejnerových enginů, protože Cloudflare konfiguruje namespaces a seccomp po spuštění procesu, ale ještě před načtením jakýchkoli izolátů. To například znamená, že Cloudflare může použít (a skutečně používá) zcela prázdný souborový systém (mount namespace) a využívá seccomp pro zablokování naprosto všech systémových volání souvisejících se souborovým systémem. Kontejnerové enginy běžně nemohou zakázat veškerý přístup k souborovému systému, protože by tím znemožnily použití exec() pro spuštění guest programu z disku. V případě Workers nejsou guest programy Cloudflare nativní binární soubory a runtime Workers je již plně načten předtím, než Cloudflare zablokuje přístup k souborovému systému.

Sandbox vrstvy 2 navíc zcela zakazuje přístup k síti. Proces může komunikovat pouze prostřednictvím lokálních UNIX domain socketů s dalšími procesy na stejném systému. Veškerá komunikace se vnějším světem musí probíhat přes jiný lokální proces mimo sandbox.

Jeden z těchto procesů, který se nazývá supervisor, odpovídá za načítání kódu Workeru a konfigurace z disku nebo z jiných interních služeb. Supervisor zajišťuje, že sandboxový proces nemůže číst žádnou konfiguraci kromě té, která se týká Workers, které má spouštět.

Když například sandbox proces obdrží požadavek na Worker, se kterým se dosud nesetkal, obsahuje tento požadavek šifrovací klíč ke kódu daného Workeru, včetně připojených secrets. Sandbox pak může tento klíč předat supervisoru a vyžádat si tak kód. Sandbox nemůže vyžádat žádný Worker, pro který nedostal příslušný klíč, ani nedokáže vyjmenovat známé Workery. Stejně tak si nemůže vyžádat konfiguraci, kterou nepotřebuje: nemůže si například vyžádat TLS klíč používaný pro HTTPS provoz k Workeru.

Kromě čtení konfigurace komunikuje sandbox s ostatními procesy v systému také kvůli implementaci API, která jsou vystavena Workerům.

Existuje rčení: Pokud v lese spadne strom a nikdo to neslyší, vydává vůbec nějaký zvuk? Cloudflare verze tohoto rčení zní: Pokud se Worker spustí v naprosto izolovaném prostředí, kde mu není umožněna žádná komunikace s vnějším světem, běží vůbec?

Úplná izolace kódu je ve skutečnosti k ničemu. Aby Workers mohly dělat něco užitečného, musí mít možnost komunikovat s uživateli. Worker musí být přinejmenším schopen přijímat požadavky a odpovídat na ně. Aby mohly Workers bezpečně odesílat požadavky do světa, jsou zapotřebí API.

V kontextu sandboxingu nabývá návrh API zcela nového významu odpovědnosti. Rozhraní API Cloudflare přesně definují, co Worker může a nemůže dělat. Cloudflare musí každé API navrhnout velmi pečlivě tak, aby umožňovalo vyjádřit pouze povolené operace a nic navíc. Cloudflare chce Workers například umožnit vytvářet a přijímat HTTP požadavky, ale zároveň jim nechce umožnit přístup k místnímu systému souborů nebo interním síťovým službám.

V současnosti Workers neumožňují žádný přístup k místnímu souborovému systému. Cloudflare proto vůbec nezpřístupňuje API souborového systému. Žádné API znamená žádný přístup.

Představte si však, že by Workers v budoucnu chtěly podporovat přístup k lokálnímu souborovému systému. Jak by to šlo realizovat? Workers by neměly vidět celý souborový systém. Představte si však, že by každý Worker měl svůj vlastní soukromý adresář v souborovém systému, kam by mohl ukládat cokoliv chce.

K tomu by Workers použily návrh založený na zabezpečení založené na capabilities ↗. Capabilities jsou samy o sobě rozsáhlé téma, ale v tomto případě by to znamenalo, že by Cloudflare Workeru předal objekt typu Directory, představující adresář v souborovém systému. Tento objekt by měl API, které umožňuje vytvářet a otevírat soubory a podadresáře, ale neumožňuje přechod do nadřazeného adresáře. Každý Worker by tak fakticky viděl svůj vlastní privátní Directory jako by to byl kořen jejich vlastního systému souborů.

Jak by bylo takové API implementováno? Jak bylo popsáno výše, sandboxový proces nemá přístup ke skutečnému souborovému systému. Přístup k souborům by místo toho zprostředkovával supervizorský proces. Sandbox komunikuje se supervizorem pomocí Cap’n Proto RPC ↗, protokol RPC založený na oprávněních. (Cap’n Proto je open source projekt, který v současnosti spravuje tým Cloudflare Workers.) Tento protokol výrazně usnadňuje implementaci API založených na oprávněních, díky čemuž může Cloudflare striktně omezit sandbox pouze na přístup k souborům patřícím Workers, které v něm běží.

Co se týče síťového přístupu? V současnosti mohou Workers komunikovat se zbytkem světa pouze prostřednictvím HTTP, a to jak příchozího, tak odchozího. Pro jiné formy síťového přístupu neexistuje žádné API, a proto jsou zakázány. Cloudflare však plánuje v budoucnu podporu dalších protokolů.

Jak již bylo zmíněno, proces sandboxu se nemůže připojit k síti přímo. Všechny odchozí HTTP požadavky se místo toho posílají přes UNIX domain socket do lokální proxy služby. Tato služba na požadavek uplatňuje omezení. Ověřuje například, že požadavek směřuje buď na veřejnou internetovou službu, nebo na vlastní origin server zóny daného Workeru, nikoli na interní služby, které by mohly být viditelné na lokálním počítači nebo v síti. Ke každému požadavku také přidává hlavičku identifikující Worker, ze kterého požadavek pochází, takže lze zneužívající požadavky vysledovat a zablokovat. Jakmile je vše v pořádku, požadavek pokračuje do vrstvy HTTP cache sítě Cloudflare a odtud dál na internet.

Podobně to funguje i u příchozích HTTP požadavků, které nesměřují přímo do Workers runtime. Nejprve je přijme vstupní proxy služba. Ta odpovídá za ukončení TLS spojení (Workers runtime nikdy neuvidí klíče TLS) a zároveň určuje, který Worker skript se má pro danou URL požadavku spustit. Jakmile je vše připraveno, požadavek se přes UNIX doménový socket předá sandboxovému procesu.

Každý netriviální software obsahuje chyby a technologie sandboxingu nejsou výjimkou. Chyby mají i virtuální stroje, kontejnery a izoláty, které Workers používají.

Workers se silně spoléhají na izolaci, kterou poskytuje V8, JavaScriptový engine vyvinutý Googlem pro použití v Chromu. Má to své výhody i nevýhody. Na jedné straně je V8 mimořádně komplexní technologie, což vytváří širší útočnou plochu než u virtuálních strojů. Vyšší složitost znamená více příležitostí, kdy může něco selhat. Na druhou stranu se do hledání a opravování chyb V8 investuje mimořádné úsilí, protože jde patrně o nejrozšířenější sandboxingovou technologii na světě. Google pravidelně vyplácí pětimístné odměny každému, kdo najde únik ze sandboxu V8. Google také provozuje fuzzingovou infrastrukturu, která nachází chyby automaticky a rychleji, než to dokáže většina lidí. Díky investicím Googlu se výrazně snižuje riziko zero-day chyb ve V8, tedy chyb, které objeví útočníci dříve, než se o nich dozví Google.

Co se ale stane poté, co je chyba nalezena a nahlášena? V8 je open source, takže opravy bezpečnostních chyb vznikají veřejně a jsou uvolněny pro všechny současně. Je důležité, aby se jakákoli záplata dostala do produkce co nejrychleji, dříve než útočníci stihnou vyvinout exploit.

Doba mezi vydáním opravy a jejím nasazením se nazývá patch gap. Společnost Google dříve oznámili, že se u Chromu prodleva v opravách zkrátila z 33 dnů na 15 dnů ↗.

Naštěstí má Cloudflare přímou kontrolu nad stroji, na kterých běží runtime Workers. Téměř celý proces sestavení a vydání je automatizovaný, takže ve chvíli, kdy vyjde nová záplata V8, systémy Cloudflare automaticky sestaví nové vydání runtime Workers a po jednom kliknutí, kterým to potvrdí potřební (lidští) recenzenti, ho automaticky nasadí do produkčního prostředí.

Díky tomu je nyní zpoždění záplat u Workers kratší než 24 hodin. Záplata, kterou tým V8 v Mnichově vydá během svého pracovního dne, se obvykle dostane do produkce ještě před koncem pracovního dne v USA.

Tým V8 ve společnosti Google uvedl, že V8 samotné se nedokáže bránit proti Spectre ↗. Workers k tomu nepotřebují záviset na V8. Prostředí Workers nabízí mnoho alternativních přístupů ke zmírnění Spectre.

Spectre je třída útoků, při kterých dokáže škodlivý program přimět CPU, aby spekulativně provedl výpočet s daty, ke kterým by program neměl mít přístup. CPU si nakonec problém uvědomí a výsledky spekulativního výpočtu programu neumožní zobrazit. Program ale může část tajných dat odvodit ze subtilních vedlejších efektů výpočtu, například z jeho dopadu na mezipaměť.

Více informací o Spectre najdete v Stránka Learning Center k tomuto tématu ↗.

Spectre zahrnuje širokou škálu zranitelností přítomných v moderních CPU. Konkrétní zranitelnosti se liší podle architektury a modelu a je pravděpodobné, že řada z nich ještě nebyla objevena.

Tyto zranitelnosti představují problém pro každou cloudovou výpočetní platformu. Kdykoli na stejném stroji běží kód více nájemců, jsou útoky typu Spectre možné. Čím blíže jsou si však nájemci navzájem, tím obtížnější může být zmírnění konkrétních zranitelností. Mnohé ze známých problémů lze zmírnit na úrovni jádra (ochrana procesů navzájem) nebo na úrovni hypervisoru (ochrana VM), často s pomocí aktualizací mikrokódu CPU a různých obranných mechanismů (z nichž mnohé mohou mít vážný dopad na výkon).

V Cloudflare Workers jsou jednotliví nájemci od sebe izolováni pomocí V8 isolates, nikoli pomocí procesů nebo virtuálních strojů. To znamená, že Workers se nemohou vždy spolehnout na opravy operačního systému nebo hypervisoru proti útokům typu Spectre. Workers proto potřebují vlastní strategii.

Cloudflare Workers je navržen tak, aby spouštěl váš kód v každé jednotlivé lokalitě Cloudflare.

Workers je navržen jako platforma dostupná pro každého. Musí zvládnout obrovské množství tenantů, přičemž řada z nich generuje jen velmi malý provoz.

Pokud tyto dva body zkombinujete, plánování se stane obtížným.

Typický serverless poskytovatel bez edge architektury by mohl málo vytížené tenanty obsluhovat tak, že by veškerý jejich provoz posílal na jeden jediný stroj, takže by se aplikace musela načíst jen jednou. Pokud stroj zvládne obsloužit třeba desítku tenantů, je to zcela dostatečné. Takový stroj může být provozovaný v obřím datovém centru s miliony strojů, což přináší úspory z rozsahu. Tato centralizace ale s sebou nese vyšší latenci a náklady na celosvětovou šířku pásma, pokud uživatelé nejsou poblíž.

U Workers naproti tomu aktuálně běží každý tenant, bez ohledu na úroveň provozu, ve všech lokalitách Cloudflare. A ve snaze dostat se co nejblíže koncovému uživateli Cloudflare někdy volí lokality, kde je místo jen pro omezený počet strojů. Výsledkem je, že Cloudflare musí umět hostit tisíce aktivních tenantů na jeden stroj a zároveň rychle spouštět neaktivní tenanty na vyžádání. To znamená, že každý host nesmí zabrat víc než pár megabajtů paměti, což sotva stačí na call stack, natož na všechno ostatní, co proces potřebuje.

Cloudflare navíc potřebuje, aby přepínání kontextu bylo výpočetně efektivní. Řada Workers uložených v paměti zpracovává událost jen občas a mnohé z nich stráví na jedné konkrétní události méně než zlomek milisekundy. V takovém prostředí se jedno jádro snadno přepíná mezi tisíci různými nájemci každou sekundu. Zpracování jedné události vyžaduje značnou komunikaci mezi hostovanou aplikací a jejím hostitelem, což znamená další přepínání a komunikační režii. Pokud každý nájemce běží ve vlastním procesu, je tato režie o řády vyšší, než když více nájemců sdílí jeden proces. Při použití striktní izolace procesů ve Workers může být zátěž CPU snadno desetkrát vyšší než u sdíleného procesu.

Aby byly Workers levné, rychlé a dostupné pro každého, musel Cloudflare najít způsob, jak hostovat více tenantů v jediném procesu.

Spectre nemá žádné oficiální řešení, a to ani při použití těžkopádných virtuálních strojů. Zranitelní jsou stále všichni.

Odvětví se potýká s novými útoky typu Spectre. Přibližně každých pár měsíců výzkumníci odhalí novou zranitelnost Spectre, výrobci CPU vydají nový mikrokód a výrobci operačních systémů vydají opravy jádra. Všichni musí neustále aktualizovat.

Stačí ale pouhé nasazení nejnovějších záplat?

Existují další zranitelnosti, které dosud nebyly zveřejněny. Aby se Cloudflare bránil proti Spectre, musel zvolit jiný přístup. Nestačí blokovat jednotlivé známé zranitelnosti, je nutné řešit celé třídy zranitelností najednou.

Je nepravděpodobné, že se najde univerzální oprava zranitelnosti Spectre. Následující myšlenkový experiment ale nastoluje body k zamyšlení:

Všechny zranitelnosti typu Spectre v zásadě využívají postranní kanály k odhalení skrytého stavu procesoru. Postranní kanály z definice spočívají v pozorování nedeterministického chování systému. Většina softwarových běhových prostředí se naštěstí snaží nedeterminismus co nejvíce eliminovat, protože nedeterministické chování dělá aplikace nespolehlivými.

Přesto stále existuje několik druhů nedeterminismu, které jsou běžné. Tím nejzřetelnějším je časování. Odvětví se už dávno vzdalo představy, že by program měl při každém spuštění trvat stejně dlouho, protože deterministické časování je v zásadním rozporu s heuristickou optimalizací výkonu. Většina útoků Spectre se zaměřuje na časování jako způsob, jak odhalit skrytý mikroarchitektonický stav CPU.

Někdo navrhoval, že by se to dalo vyřešit znepřesněním časovačů nebo přidáním náhodného šumu. Ukázalo se ale, že to útoky nezastaví, jen je zpomalí. Pokud časovač alespoň částečně sleduje reálný čas, jakoukoli nepřesnost lze překonat opakovaným spuštěním útoku a použitím statistiky k odfiltrování nesrovnalostí.

Mnoho bezpečnostních výzkumníků to považuje za konec příběhu. K čemu je zpomalení útoku, pokud je útok stále možný?

Opatření, která útok zpomalují, však mohou být velmi účinná.

Klíčové zjištění je toto: čím pomalejší útok je, tím více nových technik se stává použitelnými pro jeho další zpomalení. Cílem je tedy zřetězit dostatek technik, aby se útok stal natolik pomalým, že přestane být zajímavý.

Ostatně velká část kryptografie je technicky zranitelná vůči útokům hrubou silou, teoreticky ji lze s dostatkem času prolomit. Pokud je ale potřebný čas v řádu tisíců (nebo i miliard) let, jde o dostatečnou ochranu.

Co lze udělat pro to, aby útoky Spectre ztratily jakýkoli smysl?

Workers neumožňuje zákazníkům nahrávat binární soubory s nativním kódem, které by běžely v síti Cloudflare, povoleny jsou pouze JavaScript a WebAssembly. Řadu dalších jazyků, jako je Python, Rust nebo i Cobol, lze zkompilovat nebo transpilovat do jednoho z těchto dvou formátů. Oba formáty pak prochází V8, který je převádí na skutečný nativní kód.

Samo o sobě to nutně neztěžuje útoky typu Spectre. Uvádí se to ale jako krok 0, protože je zásadní pro umožnění následujících kroků.

Přijímat programy s nativním kódem znamená být vázán na konkrétní architekturu procesoru (typicky x86). Pro dosažení přijatelného výkonu je totiž obvykle nutné spouštět kód přímo na reálném hardwaru, čímž se výrazně omezuje kontrola hostitele nad průběhem tohoto spouštění. Jádro nebo hypervizor tak například nemá možnost zabránit aplikacím ve volání CLFLUSH instrukce, instrukce což je užitečné při útocích postranním kanálem ↗ a téměř nic jiného.

Podpora nativního kódu navíc obvykle znamená nutnost podporovat celé existující operační systémy a softwarové stacky, které s sebou nesou desítky let zažitých očekávání o fungování dané architektury. Procesory x86 například umožňují jádru nebo hypervisoru zakázat instrukci RDTSC, jež čte vysoce přesný časovač. V praxi ovšem její zakázání rozbije řadu programů, protože jsou napsané tak, že RDTSC používají kdykoli potřebují zjistit aktuální čas.

Podpora nativního kódu by do budoucna omezila výběr technik zmírnění rizik. Použití abstraktního mezilehlého formátu dává větší volnost.

Ve Workers můžete získat aktuální čas pomocí JavaScript Date API voláním Date.now(). Vrácená hodnota času ale není aktuální čas. Date.now() vrací čas posledního I/O. Během provádění kódu se neposouvá. Pokud by útočník napsal například:

let start = Date.now();
for (let i = 0; i < 1e6; i++) {
  doSpectreAttack();
}
let end = Date.now();

Hodnoty start a end bude vždy naprosto stejný. Útočník nemůže použít Date k měření doby provádění svého kódu, což by potřebovali k provedení útoku.

Workers stejně tak nepovolují multithreading ani sdílenou paměť. Vše, co souvisí se zpracováním jedné události, probíhá na jediném vlákně. Jinak by bylo možné vlákna závodit a tímto způsobem odhadovat a ověřovat podkladový časovač. Více Workerů nesmí zpracovávat stejný požadavek souběžně. Pokud máte na své zóně nainstalovanou Cloudflare App postavenou na Workers a vaše zóna zároveň sama Workers používá, může být požadavek na vaši zónu ve skutečnosti zpracován dvěma Workery za sebou. Ty běží na stejném vlákně.

V tomto okamžiku je lokální měření doby provádění kódu znemožněno. Vzdáleně ho ale stále měřit lze. HTTP klient, který odešle požadavek spouštějící Worker, může například změřit, jak dlouho trvá, než Worker odpoví. Takové měření bude pravděpodobně velmi zašuměné, protože musí projít internetem a započítává obecné síťové náklady. Tento šum lze teoreticky překonat tak, že se útok provede mnohokrát a výsledky se zprůměrují.

Přestože Cloudflare při adversariálním testování a za pomoci předních expertů na Spectre nedokázal vyvinout vzdálený časovací útok fungující v produkčním prostředí, neznamená to, že by tým Workers měl přestat budovat obranu. Naopak tým Workers v současné době testuje další pokročilejší opatření.

Pokud je útok vůbec možný, jeho provedení by trvalo dlouho, minimálně hodiny, klidně i týdny. Jakmile ale útok probíhá byť jen sekundu, vzniká velké množství nových dat, která lze využít ke spuštění dalších opatření.

Útoky Spectre vykazují neobvyklé chování, jaké byste u běžného programu nečekali. Tyto útoky se záměrně snaží vytvořit patologické výkonnostní scénáře, aby zesílily mikroarchitektonické efekty. To platí obzvlášť tehdy, když už je útok kvůli překonání dalších zmíněných opatření nucen běžet v cyklu miliardykrát. Taková aktivita se pak často projeví v metrikách, jako jsou výkonnostní čítače CPU.

Obvyklým problémem při detekci útoků Spectre pomocí metrik výkonu jsou občasné falešně pozitivní výsledky. Legitimní program se totiž někdy chová špatně. Runtime nemůže vypnout každou aplikaci, která vykazuje nízký výkon.

Runtime místo toho přesune každý Worker s podezřelými výkonnostními metrikami do vlastního procesu. Jak už bylo řečeno, u každého Workeru to udělat nejde, protože by režie byla příliš vysoká. Izolovat několik procesů Workerů jako obranný mechanismus je ale přijatelné. Pokud je Worker legitimní, poběží dál, jen s trochu vyšší režií. Cloudflare naštěstí dokáže přesunout Worker do vlastního procesu prakticky kdykoli.

Propracované spouštění na základě výkonnostních čítačů zde ve skutečnosti nemusí být ani potřeba. Pokud Worker spotřebuje na jednu událost velké množství času CPU, je režie izolace do vlastního procesu relativně nižší, protože přepíná kontext méně často. Runtime tedy může izolaci procesem klidně použít pro každý Worker, který je náročný na CPU.

Jakmile je Worker izolovaný, může se Cloudflare spolehnout na obranu operačního systému proti útokům Spectre, stejně jako to dělá většina desktopových webových prohlížečů.

Cloudflare na vývoji tohoto přístupu spolupracuje s odborníky z Technické univerzity ve Štýrském Hradci (TU Graz). Tým TU Graz se podílel na objevení samotné zranitelnosti Spectre a od té doby stojí za velkým množstvím navazujících objevů. Cloudflare vyvinul schopnost dynamicky izolovat Workers a identifikoval metriky, které spolehlivě odhalují útoky.

Jak již bylo zmíněno, izolace procesů není úplnou obranou. Útoky typu Spectre bývají časem stále pomalejší, takže je Cloudflare schopna s rozumnou jistotou odhalit a identifikovat útočníky. Izolace procesu potenciální útok dále zpomaluje.

V tomto okamžiku jsou všechny známé útoky zablokovány. Workers tak zůstávají zranitelné vůči budoucím neznámým útokům, stejně jako všechny ostatní systémy založené na CPU. Nové útoky ale budou obecně velmi pomalé, jejich provedení potrvá dny i déle, takže Cloudflare bude mít čas připravit obranu.

Je například rozumné restartovat celý runtime Workers denně. Tím se resetuje umístění všeho v paměti, což útočníky donutí začít proces zjišťování umístění secrets znovu od začátku. Cloudflare také může Workery přeplánovat mezi fyzickými stroji nebo cordons, takže časové okno pro útok na konkrétního souseda je omezené.

Vzhledem k tomu, že Workers jsou ve své podstatě preemptibilní (na rozdíl od kontejnerů nebo virtuálních strojů), má Cloudflare při maření útoků obecně velkou volnost.

Cloudflare to vnímá jako průběžnou investici, ne jako něco, co bude někdy hotové.