Een vervelend effect van de Meltdown en Spectre-crisis is dat cloudinfrastructuren problemen ondervinden, grotendeels omdat Linux-ontwikkelaars pas laat werden geïnformeerd. Google publiceerde vorige week over de ontdekkingen waar Google, Intel, AMD en ARM ongeveer een half jaar van wisten.
De Linux-kernel implementeert sinds november een oplossing en in kernel 4.15 wordt deze officieel toegevoegd. Linux-distro's rollen nu hun patches uit, Microsoft heeft Windows onder handen genomen en Apple heeft macOS-patches uitgerold. Deze zijn allemaal haastig toegepast, omdat de softwareleveranciers een stuk minder de tijd hadden om het gat aan te pakken dan hardwaremakers.
Jarenlange cloudimpact
OpenBSD-leider Theo de Raadt klaagt over het discolureproces waarbij vooral kleinere leveranciers pas laat op de hoogte werden gesteld. Ook heeft hij geen goed woord over voor Intels aanpak met speculative execution, waarvan elke expert allang weet dat het beveiligingsrisico's met zich meebrengt. De Raadt vermoedt dat Intel zijn ontwerpers heeft opgedragen dat risico simpelweg te negeren.
Dat juist OpenBSD hardop zijn beklag doet is tekenend: het OS houdt zich specifiek bezig met het leveren van een beveiligde omgeving en wordt daarom ook gebruikt in cloudinfrastructuren. De Raadt maakt zich grote zorgen over de langetermijneffecten van Intels aanpak en vindt het eigenlijk van de zotte dat de kernel moet worden aangepast om fouten in de micro-architectuur op te lossen.
Ruwe kernelpatches
En die kernelpatches zijn eigenlijk een noodoplossing. "De kernelpatches waren haastig gemaakt", merkt Zac Smith, CEO van clouddienst Packet. "Er is weinig optimalisatie. Ze beschermen tegen de exploits, maar er is met grof geschut op de kwetsbaarheid geschoten. De vraag is maar of we met nieuwe updates het prestatieverlies kunnen goedmaken."
Die impact wordt al gevoeld door cloudklanten. Een ontwikkelaar liet bijvoorbeeld zien hoe zijn EC2-instances minder goed presteren. Dat komt omdat Amazon kernelpatches toepast en daarna virtuele machines reboot met software die de geheugenfout oplost door ruw te breken met een feature om geheugenberekeningen sneller (en onveiliger) uit te voeren. Een woordvoerder van AWS laat Computerworld weten dat er geen prestatieverlies is voor de meerderheid van EC2-workloads.
Geheugenvertraging
Dat verlies is vooral merkbaar bij processen die in-memory worden uitgevoerd. Vooral bewerkingen van specifieke databasestructuren worden met twintig tot dertig procent vertraagd, wat voor veel bedrijven een onacceptabel verlies is. Om dit probleem op te lossen zonder dit prestatieverlies, moeten patches worden verfijnd of nieuwe hardware worden uitgerold die Intel zo heeft ontworpen dat de architectuurfout niet meer aanwezig is.
Momenteel kun je kiezen uit twee slechte opties: draai zónder de oplossing en loop het risico dar aanvallers het gat misbruiken, of patch het issue en loop prestatieverlies op. Smith stelt een derde oplossing voor: stap af van een multi-tenant-omgeving en draai weer losse, geïsoleerde instances.
Multi-tenancy is zo'n beetje de standaardmethode waarop virtuele omgevingen de laatste jaren functioneren. Cloudproviders als Amazon, Microsoft en Google beheren de virtuele machines en je deelt CPU-resources met andere klanten. IBM is de enige grote dienstverlener die bare metal-hosting levert - waarbij je als klant de hele softwarelaag levert, inclusief OS en daarboven, hoewel Amazon onlangs ook bare metal-oplossingen aankondigde.
Patches vermijden
Op locatie doen we eigenlijk hetzelfde. Met een gesloten netwerkomgeving beperk je de toegang van applicaties zodat data-opslag, BI of Online Analytical Processing (OLAP) van elkaar gescheiden blijven en je ook zeker bent dat andere applicaties daar niet bij kunnen. In de cloud geldt dan dat andere apps en andere klanten niet bij jouw spullen kunnen, maar via Meltdown is dat niet meer zeker.
Smith merkt dat diverse klanten van de clouddienst momenteel kiezen voor een scenario waar één klant instances draait zonder resources te delen en dan de Meltdown-patches vermijden. "Sommige van onze klanten willen zowel de kernelpatches als andere Meltdown-updates, terwijl anderen liever ongepatcht blijven", zegt Smith van cloudprovider Packet. "Ze hebben daar use cases voor: ze willen geen prestatieverlies en begrijpen de beveiliging met single tenancy."
Specifieke scenario's
Deze klanten hebben een gemeenschappelijk profiel: ze zijn vooral gericht op prestaties en draaien één specifieke workload op grote schaal. Ze begrijpen hoe hun code in elkaar steekt, delen die met niemand, en hebben een besturingsomgeving die gedetailleerd op maat gemaakt is. Meestal is het voor taken als extract, transform load (ETL) of big data, waarbij geen vertraging van 20 procent geduld kan worden, ze draaien geen willekeurige workloads en staan geen andere gebruikers toe in de gebruikte ruimte.
"Enkele van onze klanten met de sterkste meningen zijn heel geavanceerd in hun aanpak. Sommige hebben zelfs specifiek gevraagd hoe ze kernelpatches kunnen tegenhouden voor hun OS. Ze hebben vertrouwen in hun single tenancy en hoe ze hun code draaien dat ze goed zicht hebben op het feit dat ze weinig risico lopen", aldus Smith.
Lager risico
Hij voegt daaraan toe dat het zeker geen wondermiddel is, maar dat VM's op een publieke cloud momenteel een risico met zich meebrengen. Als je je eigen workload op een enkele, dichtgetimmerde omgeving met één gebruiker draait heb je dat specifieke risico niet, omdat andere gebruikers de geheugentoegang via een Meltdown-exploit kunnen uitlezen.
En water is nat. Wat een stupide reactie. Alsof dit een permanente situatie moet voorstellen.
Deze puinbak loopt al héél veel langer dan Meltdown/Spectre en Theo schopt er ook al minstens 10 jaar tegenaan. Permanent? Misschien niet, maar het duurt allemaal wel heel erg lang voordat de CPU-bouwers in beweging komen.
OpenBSD is geen Linux-distributie.
Wie zegt van wel dan?
Reageer
Preview