Diskussion um Core-2-Duo-Bugs

Um bestimmte Fehler von Intels aktuellen Core-2-Duo-Prozessoren hat sich eine Diskussion zwischen Open-Source-Software-Entwicklern entsponnen. Es geht darum, ob diese Fehler potenzielle Sicherheitsrisiken darstellen, weil sie sich möglicherweise als Schwachstellen von Schadsoftware ausnutzen lassen.

Laut Intel besteht kein Sicherheitsrisiko; der Hersteller empfiehlt aber, seine Prozessoren immer mit aktuellen Microcode-Updates zu betreiben, also ein BIOS-Update oder einen Betriebssystem-Patch einzuspielen, wenn sie neue Microcode-Versionen für den jeweils vorhandenen Prozessor bringen. Die Möglichkeit der Microcode Updates wurde bei x86-Prozessoren unter anderem deshalb geschaffen, um nachträglich erkannte Bugs korrigieren zu können. Der Microcode kann einem Prozessor aber theoretisch auch komplett neue Befehle beibringen.

Microsoft hat kürzlich ein solches Update für zahlreiche Windows-Versionen veröffentlicht, schon zuvor hatten zahlreiche PC-Hersteller BIOS-Updates für Rechner mit Core-2-Duo-Prozessoren herausgebracht.

Laut einer Diskussion zwischen Linux-Entwicklern auf der Linux Kernel Mailinglist (LKML) spielen aktuelle Linux-Distributionen die Microcode-Updates auch standardmäßig bei Internet-Updates ein; die neueste Microcode-Version 1.17, die ein Auftreten des diskutierten Fehlers verhindern soll, ist aber bislang in kaum einer aktuellen Distribution von vornherein enthalten (separat erhältlich als Intel Microcode Update Utility for Linux).

Die Diskussion um die Bedeutung des Core-2-Duo-Fehlers hat der OpenBSD- und OpenSSH-Gründer Theo de Raadt mit einem Beitrag auf der Mailingliste openbsd-misc losgetreten. Darin kritisiert der auch sonst wenig zimperliche De Raadt Intel scharf für die Fehler und spricht von möglichen Sicherheitsproblemen, beschreibt aber die konkreten Angriffsmöglichkeiten nicht genau (Raadt kritisiert bei dieser Gelegenheit übrigens auch gleich AMD). Tatsächlich beschreibt Intel bisher nirgendwo genau, welche der zahlreichen Core-2-Duo-Bugs das Microcode Update korrigiert.

Im Forum der Webseite RealWorldTech hat sich bereits Linus Torvalds zu den fraglichen Core-2-Duo-Fehlern geäußert und schätzt sie für aktuelle Linux-Versionen schlicht als bedeutungslos ein.

Diskussionen über die Bedeutung von Prozessorfehlern gibt es immer wieder, legendär ist der berühmte FDIV-Bug des Pentium, der Intel wegen einer Umtauschaktion vor 12 Jahren eine halbe Milliarde US-Dollar gekostet hat. Seither dokumentiert Intel die CPU-Bugs öffentlich und hat zwischenzeitlich auch schon einen Chipsatz und einen weiteren Prozessor zurückgerufen. Auch AMD-Prozessoren sind immer wieder mal von Bugs betroffen.

Der ehemals beim CPU-Entwickler Transmeta beschäftigte Torvalds meint zu den Bugs der x86-Prozessoren von AMD und Intel, dass diese eine stark überhöhte Aufmerksamkeit genießen. Alle Prozessoren hätten Fehler, die bei den sehr weit verbreiteten Universalprozessoren, für die es zahllose Betriebssysteme und Programmierer gebe, besser öffentlich dokumentiert würden als bei den Spezialprozessoren, bei denen eben nur eine kleine Entwicklerschar über Probleme informiert würde.

Weil alle Mikroprozessoren Fehler enthalten, versorgen ihre Hersteller Hardware-Entwickler und Programmierer mit Hinweisen, wie sich diese Bugs umschiffen lassen. Die Fehlerdokumentation erfolgt je nach Hersteller mehr oder weniger öffentlich und schnell; Intel pflegt die sogenannten Specification Updates, AMD die Revision Guides. Manche der von Intel euphemistisch "Errata" genannten CPU-Fehler lassen sich durch Veränderungen der CPU-Initialisierung (also per BIOS-Update) beheben, manche per Microcode Update (per BIOS oder Betriebssystem), einige korrigieren die Prozessorfirmen in optimierten Neuauflagen der CPU-Kerne, also in neuen CPU-"Steppings". Die meisten CPU-Fehler treten mit realem Code sehr selten auf, weshalb sie die Prozessorhersteller typischerweise selbst in Laborversuchen unter extremen Bedingungen finden.

Die Beurteilung der Bedeutung der aktuellen Core-2-Duo-Fehler ist schwierig. Die Diskussion der Open-Source-Entwickler hat sich vor allem an der "Specification Clarification AI1" entzündet, in der Intel erklärt, wie Betriebssysteme die TLB Invalidation handhaben sollten. Dabei geht es um das Verwerfen von Daten in bestimmten Puffern, den Translation Look-Aside Buffers (TLB).

Zu den von Theo de Raadt als potenziell kritisch eingestuften Fehlern gehört unter anderem das Erratum AI99, Updating Code Page Directory Attributes without TLB Invalidation May Result in Improper Handling of Code #PF. Eine Page Fault Exception (#PF) spielt unter anderem beim sogenannten No-Execute-Speicherschutz (NX, von Microsoft Data Execution Prevention/DEP, von AMD Enhanced Virus Protection/EVP und von Intel Execute Disable genannt) eine wichtige Rolle. Das Problem besteht nun darin, dass Core-2-Prozessoren #PF mit niedrigerer Priorität behandeln als eine Debug Exception (#DB) oder einen General Protection Fault (#GP). Deshalb kann es unter bestimmten Bedingungen dazu kommen, dass #PF falsch verarbeitet wird – laut Intel allerdings nur dann, wenn gleichzeitig die drei folgenden Bedingungen zutreffen:

• Ein Eintrag im Page Directory (PDE) wird verändert ohne den zugehörigen TLB-Eintrag ungültig zu machen
• Die Code-Ausführung wechselt auf eine andere Speicherseite (Code Page), wobei gleichzeitig - die Adresse der neuen Speicherseite dem modifizierten PDE entspricht - und das Accessed-Bit (A) des Page-Table-Eintrags (PTE) der Speicheradresse leer ist
• Nach dem Wechsel der Speicherseite eine von zwei bestimmen Exception-Kombinationen eintritt, nämlich entweder - #DB und #PF - oder Code Segment Limit Violation (also #GP) und #PF

Die drei Bedingungen dürften nur selten zusammentreffen; ein Exploit, der diese Schwachstelle ausnützt, müsste wohl außerdem mit hohen Zugriffsrechten laufen. De Raadt erwähnt ferner allerdings noch die Errata AI65, AI79, AI43, AI39 und AI90 im aktuellen Specification Update Nr. 14. Intel beschreibt die Auswirkungen der Fehler nicht sehr genau; anscheinend schwächen einige von ihnen aber ebenfalls die NX-Speicherseitenmarkierung.

32-Bit-Linux-Distributionen nutzen Hardware-Speicherschutzfunktionen wie NX kaum, weil man dazu einen PAE-tauglichen Kernel braucht, den man manuell installieren müsste. Außerdem gibt es auch Software-Tricks, die vor denselben Angriffen schützen sollen wie die NX-Speicherseitenmarkierung (etwa PaX). Die NX-Funktion schützt ohnehin nur vor bestimmten Arten von Angriffen. (ciw)