Gisteren werd Retbleed openbaar gemaakt als een nieuwe speculatieve uitvoeringsaanval waarbij gebruik werd gemaakt van retourinstructies. Hoewel het”goede”nieuws is dat Retbleed alleen invloed heeft op eerdere generaties AMD-en Intel-processors, is het slechte nieuws dat de verminderde prestatie-impact op Linux behoorlijk ernstig is. Sinds gisteren ben ik de nieuw samengevoegde Linux-patches aan het benchmarken op verschillende Intel-en AMD-processors die zijn getroffen door Retbleed. Het is erg vervelend als je een getroffen processor gebruikt.
De standaardbeperkingen voor Retbleed zijn pijnlijk voor getroffen Intel/AMD-CPU’s… Voordat iemand te veel getriggerd werd door de afbeelding, waren de afgebeelde CPU’s dood van natuurlijke oorzaken lang voordat ze in 80% isopropylalcohol werden gegooid.
De Linux-beperking voor Retbleed is invasief met bijna tweeduizend regels nieuwe code en bijna 400 verwijderde regels, verdeeld over tientallen bestanden. In de Retbleed-whitepaper van COMSEC-onderzoekers van ETH Zürich, karakteriseerden ze de mitigaties als resulterend in 14~39% overhead. Ik heb de Linux-patches lokaal op verschillende systemen getest en het is inderdaad behoorlijk ernstig. De Retbleed-beperkingen zijn enkele van de meest prestatieverlagende oplossingen die ik in een paar jaar heb gezien, teruggaand naar de vroege Spectre/Meltdown-dagen.
Onderzoekers en de hardwareleveranciers geloof dat Retbleed invloed heeft op AMD Zen 1, Zen 1+ en Zen 2-processors, maar niet op de nieuwste Zen 3-CPU’s. Bij het uitproberen van de gepatchte Linux-kernel op Zen 3-hardware zijn er geen Retbleed-beperkingen toegepast. Aan de Intel-kant worden Core 6e generatie tot en met Core 8e generatie CPU’s beïnvloed–Skylake via Coffee Lake.
De Retbleed-beperkingen zijn sinds gisteren samengevoegd met Linux 5.19 Git en werken momenteel hun weg naar de verschillende stabiele/ondersteunde Linux-serie op dit moment. Die Linux stable point-releases zullen binnenkort verschijnen. Wanneer het draait op een gepatchte Linux-kernel, worden de Retbleed-beperkingen standaard automatisch toegepast op de getroffen AMD/Intel-CPU’s, zoals vermeld.
De beperkingen stapelen zich zeker op voor sommige processors…
Voor degenen die het zich afvragen, het opstarten van de Linux-kernel met”mitigations=off”als de universele vlag voor het uitschakelen van de beperking zal inderdaad de beperking van Retbleed uitschakelen. Of er is nu de kernelparameter”retbleed=”waar”retbleed=off”kan worden ingesteld als u alleen de nieuwe oplossingen wilt uitschakelen. Het standaardgedrag is”rebleed=auto”voor het toepassen van de juiste beperking op basis van de CPU. Er is ook de mogelijkheid om bepaald mitigatiegedrag te forceren of SMT uit te schakelen. Specifiek voor AMD Zen 1-CPU’s is het uitschakelen van SMT nodig voor volledige beperking, maar dit is niet het standaardgedrag.
In dit artikel staan benchmarks van een gepatchte Linux 5.19-kernel met het standaardgedrag (rebleed=auto) en en vervolgens dezelfde kernel en hardware opnieuw opstarten, maar met”rebleed=off”voor het tonen van de niet-gepatchte prestaties. Vervolgartikelen zullen meer ingaan op de verschillende tunables en AMD Zen 1-impact met”auto,nosmt”, enz. Dit artikel zijn slechts de benchmarks die ik de afgelopen dag heb voltooid.
Als eerste in dit artikel gaat in op de verminderde prestaties voor de Intel Core i7 8700K, Intel Xeon E3-1260L v5 en AMD Ryzen Threadripper 3960X-systemen. Na deze desktop-/werkstationgerichte tests volgen een aantal benchmarks op een AMD Zen 2-server met het eerdere vlaggenschip EPYC 7742 2P.
Voor Intel 6e tot 8e generatie en AMD Zen 1/1+/2 processors, worden de reductiekosten op Linux gemakkelijk zichtbaar bij het uitvoeren van workloads met een hoge kernel-interactiviteit…
Voor veel van de I/O-workloads en andere gebieden die al zijn beïnvloed door eerdere speculatieve uitvoeringsbeperkingen, voegt Retbleed bovenop duwt nu standaard de prestaties alleen maar verder terug.
Houd er rekening mee dat deze tests-alleen-kijken naar de nieuwe Retbleed mitigatie-overhead die standaard wordt toegepast en niet naar de geaccumuleerde”mitigations=off”impact, die macrovergelijking komt in een later artikel.
Ook netwerkprestaties kunnen worden beïnvloed door Retbleed-beperkingen.
Of de WireGuard in-kernel VPN-tunneloplossing zag nu aanzienlijke prestatieregressies met de standaardbeperkingen op deze getroffen CPU’s.
Ja, de Retblee d mitigatie-impact is pijnlijk en vooral duidelijk in deze kernel-synthetische testcases…
Maar de Retbleed-mitigatie-impact out-of-the-box toont zich ook voor real-world workloads…
p>
Met sommige van de eerdere speculatieve uitvoeringsbeperkingen voor aanvallen hadden de algehele codecompilatie/buildtime-prestaties de neiging niet veel te worden beïnvloed, maar met Retbleed is er een klein maar consistent verschil.
Database-workloads zijn dat wel beïnvloed door deze standaard Retbleed-beperkingen.
Zelfs zware beeldbewerkingen met het GIMP-beeldvormingsprogramma zagen een meetbaar verschil met de nieuwe met Retbleed gepatchte kernel.
Of het RawTherapee RAW-beeldvormingsprogramma zag ook een regressies op zowel de geteste AMD-als Intel-systemen.
De tijden voor het wisselen van context zijn nu nog pijnlijker met Retbleed-beperkingen bovenop de eerdere beperkingen van de afgelopen vier jaar.
Onnodig te zeggen , zijn de onderzoekers nauwkeurig in hun beoordelingen van de aanzienlijke prestatiekosten met mitigat ing Retbleed.
De Intel-systemen werden ook beïnvloed in de cryptsetup crypto-prestaties met de Retbleed-beperkingen.
Aan de desktopkant kunnen sommigen beweren dat Retbleed-beperkingen misschien niet zo belangrijk of relevant zijn voor de meeste use-cases en probeer”rebleed=off”te rechtvaardigen, maar aan de serverkant waar beveiliging binnen organisaties belangrijker is, is het minder waarschijnlijk dat u speelt met het uitschakelen van CPU-beveiligingsbeperkingen in een dergelijke productieomgeving. Helaas is de out-of-the-box-impact van Retbleed-mitigatie ook hier erg merkbaar voor veelvoorkomende workloads. Deze ronde van serverbenchmarks waarbij de Retbleed-kosten werden bekeken, werd uitgevoerd op een op Zen 2 gebaseerde AMD EPYC 7742 2P met de standaard nu gelimiteerde Linux 5.19 Git-kernel in vergelijking met opstarten met”retbleed=off”.
In de gebruikelijke I/O-workloads waren er merkbare prestatiekosten voor de standaardbeperkingen op deze AMD Zen 2-server.
Met meer real-world workloads zoals codecompilatieprestaties voor speciale buildboxen of OpenJDK Java-servers, helaas , heeft Retbleed wel een merkbare impact. Vooral voor de codecompilatieprestaties waar met enkele van de eerdere CPU-beveiligingsbeperkingen er meestal geen meetbaar verschil was, was er met de standaardbeperkingen van Retbleed nu een duidelijk verschil op deze AMD EPYC 7742-server.
Voor PostgreSQL-serverprestaties was er een merkbare impact op de kant-en-klare prestaties met Retbleed-beperkingen toegepast.
Helaas is de snelheid voor het wisselen van context nu veel duurder met deze nieuwste beperkingen.
Er was een meetbaar prestatieverschil met ClickHouse en andere databaseworkloads.
Met de Nginx-en Apache HTTP-webservers was er ook een meetbare impact van de Retbleed-beperkingen die nu standaard worden toegepast op getroffen CPU’s. In ieder geval worden nieuwere AMD-en Intel-CPU’s niet beïnvloed door Retbleed, maar voor de getroffen CPU-generaties brengt de gepatchte Linux-kernel meetbare kosten met zich mee.
Dit zijn mijn eerste benchmarks van de afgelopen dag dat ik Retbleed heb verkend. Ik zal in toekomstige artikelen meer tests uitvoeren op getroffen Intel/AMD-processors en de totale standaardbeperkingen versus”mitigations=off”-uitschakelingen onderzoeken, samen met andere, meer tijdrovende tests. Als je geniet van mijn meedogenloze Linux-benchmarking, overweeg dan om lid te worden van Phoronix Premium.
