29

Hardware- und Nachrichten-Links des 28./29. März 2020

Für eine gewisse Verwirrung sorgt derzeit eine Aufstellung im PC_Shopping-Forum zum Level2-Cache von Intels "Rocket Lake", da dort nunmehr nur 512 kByte Level2-Cache für jene im Jahr 2021 anstehenden Desktop-Prozessoren ausgewiesen werden. Dies widerspricht etwas der Tiger-Lake-Abstammung, da die dort verwendeten "Willow Cove" CPU-Kerne über 1,25 MB Level2-Cache verfügen – wie die Aufstellung im PC_Shopping-Forum auch selber angibt. Natürlich ist eine Cache-Gleichheit zwischen Tiger Lake und Rocket Lake trotz gleicher Architektur kein Zwang, bei dieser 14nm-Desktop-Auskopplung könnte Intel auch bewußt andere Cache-Größen ansetzen, gerade beim (nicht genannten) Level3-Cache. Dennoch ändert man auf Ebene von Level1- und Level2-Cache gewöhnlich nichts (auch nicht für Derivate wie "Rocket Lake"), da die Konzeption der ganzen CPU-Architektur in aller Regel an diesen "internen" Cache-Größen hängt. Demzufolge ergibt sich derzeit die These, das Rocket Lake am Ende nicht Tiger-Lake-basiert, sondern "nur" Ice-Lake-basiert sein könnte. Technolgisch dürfte dies allerdings keinen großen Unterschied machen, da Tiger Lake von der Architektur her weitgehend Ice Lake ist, Intels eigene Kern-Roadmap hierbei nur Unterschied im Cache-System, "Transistoren-Optimierungen" (wohl eher bezogen auf die 10nm-Fertigung) und bei den Sicherheits-Features sieht – aber eben keinen generellen Sprung bei der CPU-Architektur respektive der IPC-Performance.

L1 Daten L1 Instr. L2-Cache L3-Cache
Intel Skylake bis Comet Lake 32 kByte 32 kByte 256 kByte (inkl.) 2 MByte (inkl.)
Intel Skylake-SP/X (inkl. Cascade & Cooper Lake) 32 kByte 32 kByte 1024 kByte (inkl.) 1408 kByte (exkl.)
Intel Ice Lake 32 kByte 48 kByte 512 kByte (inkl.) 2 MByte
Intel Tiger Lake 48 kByte 32 kByte 1280 kByte 3 MByte
Intel Rocket Lake 48 kByte 32 kByte 512 kByte (?) ?
AMD Zen/Zen+ 32 kByte 64 kByte 512 kByte (inkl.) 2 MByte (exkl.)
AMD Zen 2 32 kByte 32 kByte 512 kByte (inkl.) 4 MByte (exkl.)
Alle Angaben immer pro CPU-Kern, bei Tiger Lake & Rocket Lake (noch) unter Irrtum-Vorbehalt.

Dass die Tiger-Lake-Testsamples derzeit teilweise so viel besser herauskommen als bisherige Ice-Lake-Prozessoren, hängt auch eher daran, das Tiger Lake nun endlich auf Takt kommt und somit die mit Ice Lake schon gebotenenen erheblichen IPC-Verbesserungen auch besser in eine reale Performance-Steigerung umsetzen kann. Letztendlich wäre es also für Rocket Lake nicht ganz so entscheidend, ob man von der Ice-Lake- oder der Tiger-Lake-Architektur abstammt – Hauptsache, man kann den mittels Ice Lake gebotenen IPC-Sprung zu von Intel gewohnten Taktraten dann auch im Desktop-Segment anbieten. Nebenbei interessant an den Ausführungen im PC_Shopping-Forum ist die Angabe von Tiger-Lake-basierten Mobile-Prozessoren der H-Klasse (45W TDP) mit (angeblich) gleich 8 CPU-Kernen. Dies wäre bei der Kern-Anzahl deutlich mehr als von allen anderen 10nm-Prozessoren der Consumer-Klasse seitens Intel bisher geboten – und ist daher ein wenig in Frage zu stellen, denn bisher zeigte sich (das immerhin bereits in diesem Sommer/Herbst zu erwartende) Tiger Lake maximal als Vierkern-Sample.

Anfang der Woche ergab sich eine erste schwere Sicherheitslücke unter Windows 7, welche Microsoft nun nicht mehr für dieses ältere Betriebssystem (sondern nur noch für Windows 10) patchen wird. Zwar gab es kurz nach dem Auslaufen des Windows-7-Supports in diesem Januar bereits eine kritische Lücke im Internet Explorer, gegenüber jener kann man sich allerdings recht einfach durch den Verzicht auf diesen Browser schützen. Die neuerliche Lücke sieht auf den ersten Blick harmloser aus, hat es aber dennoch in sich, weil laut Heise & WinFuture hierbei ein von PDF-Dokumenten (eventuell) benutzter Schriftartenmanager ("Adobe Type Manager Font Driver") angegriffen wird – was letztlich alle PDF-Dokumente betrifft, welche somit eine generelle Sicherheits-Gefahr darstellen können. Der hierzu gern notierte Tipp, die Dokumenten-Vorschau im Windows Explorer abzuschalten, ist im übrigen nur halbgar, weil die Lücke natürlich auch beim Öffnen des Dokuments wirkt, wie Microsoft eindeutig erklärt. Ein wirklich funktionierender Workaround für ältere Betriebssysteme liegt laut Microsoft in der Deaktivierung der bewussten Schriftartenmanager-Datei "ATMFD.DLL" in der Windows-Registry – doch abseits dessen wird es von Microsoft keine weitere Hilfe oder gar einen Fix zu diesem Problem auf Windows 7 mehr geben. Damit ist relativ schnell der Stand erreicht, das ein wirklich gravierendes Sicherheitsproblem unter Windows 7 existiert, welche einen Angriff auf dieserart Installationen ziemlich einfach macht – immerhin ist der Austausch von PDF-Dokumenten heutzutage das normalste von der Welt.

Ein einziges verseuchtes Dokument könnte dabei schon zur "Remote-Code-Ausführung" führen – sprich das jemand aus der Ferne Code in den Rechner einschmuggelt und jenen nachfolgend zu übernehmen versucht. Die allerdings einfachste Lösung der ganzen Problematik ist dabei jedoch weder Microsoft (warum auch) als auch unabhängigen Sicherheits-Experten (erstaunlicherweise) aufgefallen: Der ganze schöne Angriff funktioniert natürlich nicht, wenn Windows Explorer wie auch das PDF-Anzeigeprogramm für den Internet-Zugriff gesperrt sind. Und sicherlich müssen auf 99% aller PC-Systeme beide Programme auch nicht zwingend im Internet operieren (sinnvolle Ausnahmen gibt es natürlich, keine Frage), bei der übergroßen Mehrheit der Systeme gibt es keinerlei Nutzwert für einen Internet-Zugriff von Windows Explorer und Adobe Reader (oder alternativem PDF-Programm). Da das verseuchte PDF-Dokument bei diesem Angriffsweg selber keinen Schadcode enthält, sondern nur zum Nachladen von Schadcode aus dem Internet mißbraucht wird, reicht die Kontrolle darüber, welches Programm ins Internet gehen darf, um sich vor dieser Lücke (auch unter Windows 7) zu schützen. Selbiges ist zu realisieren mittels diverser Software-Firewalls, was allerdings etwas Konfigurationsarbeit durch einen erfahrenen (oder lernwilligen) Benutzer voraussetzt, somit ergo keineswegs eine Lösung für Jedermann darstellt. Insofern darf dieser Fall natürlich trotzdem als Schuß vor den Bug der letzten Windows-7-Nutzer gesehen werden, welche gemäß der aktuellen Umfrage immer noch bei 7-8% liegen.