Als die Retbleed-Sicherheitslücke Anfang dieses Jahres bekannt wurde, musste sie für Intel Skylake und von Skylake abgeleitete CPU-Kerne abgemildert werden, indem Indirect Branch Restricted Speculation (IBRS) auferlegt wurde, was die Out-of-the-Box-Leistung für diese alternden Intel-CPUs. Aber mit Linux 6.2 wird jetzt eine neue Minderungstechnik namens Call Depth Tracking eingeführt, die dazu beiträgt, einen Teil dieser verlorenen Leistung wiederherzustellen und wiederum die Nützlichkeit der von Skylake abgeleiteten Prozessoren, die noch in Betrieb sind, zu erweitern.
Call Depth Tracking wurde in den letzten Monaten von Intel-und Linux-Kernel-Entwicklern bearbeitet, um die Notwendigkeit von IBRS zu vermeiden für Skylake/Skylake-basierte CPU-Designs zur Minderung von Retbleed. Kernel-Entwickler nannten IBRS eine „Performance-Horror-Show“, VMware-Ingenieure beschwerten sich über die verlorene Leistung und waren nur ein weiterer schmerzhafter Leistungseinbruch für die Out-of-the-Box-Geschwindigkeit dieser Intel-Prozessoren der vorherigen Generation.
Call Depth Tracking wurde für den derzeit in der Entwicklung befindlichen Linux 6.2-Kernelzyklus zusammengeführt. Obwohl mit Linux 6.2 die IBRS-Minderung immer noch die Standardeinstellung für Skylake-CPUs ist, kann Call Depth Tracking, wenn es in den Kernel integriert ist, einfach mit der Boot-Option „retbleed=stuff“ aktiviert werden.
Um zu sehen, wie Call Depth Tracking (retbleed=stuff) wirkt sich auf die Leistung von Skylake Linux aus, ich habe einige neue Abschwächungs-Benchmarks auf dem Linux 6.2 Git-Kernel ausgeführt. Vom Linux 6.2 Git-Kernel auf einem Xeon E3-1280 v5 (Skylake)-Server habe ich die folgenden Kernel-Konfigurationen getestet:
Standards – Der E3-1280 v5 Skylake-Server läuft Stock Out-of-the-Box-Konfiguration mit allen Standardminderungen. Die standardmäßige Reduzierung von Retbleed aktiviert immer noch IBRS.
retbleeed=stuff-Reduzierung von Retbleed mithilfe des neuen Stuffing-Mechanismus (Call Depth Tracking).
retbleed=off – Nur die Retbleed-Minderungen deaktivieren, aber alle anderen CPU-Sicherheitsminderungen auf ihren Standardwerten belassen.
mitigations=off – überhaupt keine CPU-Sicherheitsminderungen aktiviert Laufzeit für diesen Skylake-Server.
Von da an wurde eine Vielzahl von Linux-Benchmarks durchgeführt, um zu sehen, was dies für die Linux-Leistung auf Intel-Skylake-Ära-Hardware bedeutet, jetzt wo Call Depth Tracking verfügbar ist, um dies zu mindern Retbleed, aber zu geringeren Kosten.
Auf Anhieb mit dem PostMark I/O-Benchmark gab es eine deutliche Verbesserung mit retbleed=stuff gegenüber der Standard-Out-of-the-Box-Kernel-Performance, wenn IBRS aktiviert ist auf Skylake. Die Anruftiefenverfolgung führte zu einer Verbesserung von 24 % gegenüber der Standardleistung in PostMark, aber der Anruftiefenverfolgungsmodus hatte immer noch etwa 84 % der Leistung bei der Ausführung ohne Retbleed-Minderungen oder 69 % der Leistung, wenn das System ohne CPU-Sicherheitsminderungen ausgeführt wurde.
Für den Sockperf-Netzwerk-Socket-API-Benchmark gab es auch einen klaren Vorteil für Call Depth Tracking gegenüber der Standardleistung unter Linux 6.2, aber alle anderen Minderungen verursachen immer noch einen erheblichen Overhead.
Aber wenn Im Moment führen Sie Linux sofort einsatzbereit auf einem System aus der Skylake-Ära aus und verwenden die standardmäßigen Sicherheitsminderungen, die IBRS auferlegen. p>
Die retbleed=stuff-Operation half auch bei den OpenJDK-Java-Workloads bei der Wiederherstellung der IBRS-Leistungseinbußen auf diesem Xeon Skylake-Server.
Bei einer Vielzahl von Workloads war die Call Depth Tracking-Minderung hilfreich zeigen in g als deutlich weniger wirkungsvoll als die standardmäßige IBRS-Minderung für Retbleed.
Für verschiedene Linux-Server-Workloads auf diesem Intel Xeon E3-1280 v5-System bot die Ausführung mit Call Depth Tracking eine Leistungssteigerung (retbleed=stuff) gegenüber den Bestandsminderungen, aber es gibt immer noch hohe Kosten mit den anderen beteiligten CPU-Sicherheitsminderungen.
Der Unterschied beim Call Depth Tracking verlangsamt sich deutlich in den Stress-ng-Kernel-Mikro-Benchmarks.
Die Kontextumschaltzeit ist mit Call Depth Tracking viel kürzer als mit IBRS für Retbleed.
Wenn Sie sich immer noch auf einen Skylake/Skylake-abgeleiteten Prozessor verlassen, der jetzt standardmäßig auf IBRS setzt, um Retbleed abzuwehren, ist der Call Die unter Linux 6.2+ durch die Option retbleed=stuff verfügbare Tiefenverfolgungsminderung ist eindeutig in der Lage, einen Teil der verlorenen Leistung wiederherzustellen. Zugegeben, es gibt immer noch einen erheblichen Overhead durch die anderen CPU-Sicherheitsminderungen, die für die älteren Intel-CPUs erforderlich sind, aber zumindest ist es eine deutliche Verbesserung gegenüber dem Status quo. Insbesondere für Intel-Linux-Server der Skylake-Ära, bei denen vernünftige Sicherheitsstandards besonders erforderlich sind, kann Call Depth Tracking dazu beitragen, den Plattformen bis zum Upgrade der Hardware zusätzliches Leben einzuhauchen.
Wenn man das geometrische Mittel über betroffene Workloads nimmt, wechselt man von Der standardmäßige Linux 6.2-Kernel zum Booten mit retbleed=stuff steigerte die Leistung um 15 %. Aber das Call Depth Tracking (retbleed=stuff) lief mit 89 % der Geschwindigkeit ohne Retbleed-Minderungen (retbleed=off) oder mit 71 % der Leistung des Xeon E3-1280 v5-Servers, bei dem alle CPU-Sicherheitsminderungen deaktiviert waren (mitigations=aus).