Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Sonntag, 21 März 2021 | Blog: 1 | No: 46717
Gerade macht der Fund zweier undokumentierter Intel-Instruktionen die Runde, mit denen man angeblich (ebenfalls undokumentierten) Microcode-State in der CPU verändern kann.
Das klingt jetzt erst mal nicht gut, aber bisher gibt es zu wenig Informationen, um das wirklich sagen zu können. Es gibt ja auch Instruktionen, mit denen man aus einem Userspace-Programm heraus Kernelspeicher schreiben kann. Aber das darf man halt nicht und alles was das dann tut ist einen Fehler werfen.
Das wird hier auch so sein.
Insofern würde ich mir das aus Anwendersicht erstmal noch keine Sorgen machen, zumindest bis nähere Details veröffentlicht werden.
Das ist nicht die erste undokumentierte Instruktion, die bei Intel gefunden wird. Solche Instruktionen sind im Allgemeinen fürs interne Testen gedacht und dann vergessen worden. Es gibt da eine ganz legendäre namens LOADALL, die es zu 80286-Zeiten mal gab (auf 80386 gab es auch eine LOADALL-Instruktion, die aber subtil anders war). Damit konnte man dann zum Beispiel ohne Wechsel in den Protected Mode auf Speicher jenseits des 1. Megabytes zugreifen.
Nach undokumentierten Instruktionen zu suchen ist nicht sonderlich schwer und der Suchraum ist auch nicht so groß, insofern laufen da seit vielen Jahren Leute herum und probieren Opcodes aus. Manchmal finden sie was, manchmal nicht. Es gibt da z.B. eine undokumentierte Breakpoint-Instruktion.
Jedenfalls ... dass es da Wege geben würde, den Microcode-State zu ändern, war ja irgendwie klar. Intel shippt seit einer Weile Microcode-Updates und BIOS-Updates, die ihre Bugs im Feld fixen sollen. Das leuchtet ein, dass es da also einen Mechanismus geben wird.
#UD heißt Undefined Instruction, das ist der Fehler, den man kriegt, wenn man einen nicht existierenden Opcode auszuführen versucht. Die CPU muss also in einem bestimmten Debug-Zustand sein, um die Instruktion überhaupt als gültig zu erkennen, und in den kommt man normalerweise nicht. Die Management Engine könnte den Zustand herbeiführen, schätze ich mal, aber da haben du und ich ja keinen Zugriff drauf. Ähnlich ist das bei dieser Breakpoint-Instruktion auch. Die funktioniert nur, wenn die CPU in einem ICE läuft (oder vielleicht kann man das auch auf normalen CPUs anschalten aber ich weiß nicht wie).
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Sonntag, 21 März 2021 | Blog: 1 | No: 46717
der Fund zweier undokumentierter Intel-Instruktionen
Das klingt jetzt erst mal nicht gut, aber bisher gibt es zu wenig Informationen, um das wirklich sagen zu können. Es gibt ja auch Instruktionen, mit denen man aus einem Userspace-Programm heraus Kernelspeicher schreiben kann. Aber das darf man halt nicht und alles was das dann tut ist einen Fehler werfen.
Das wird hier auch so sein.
Insofern würde ich mir das aus Anwendersicht erstmal noch keine Sorgen machen, zumindest bis nähere Details veröffentlicht werden.
Das ist nicht die erste undokumentierte Instruktion, die bei Intel gefunden wird. Solche Instruktionen sind im Allgemeinen fürs interne Testen gedacht und dann vergessen worden. Es gibt da eine ganz legendäre namens LOADALL, die es zu 80286-Zeiten mal gab (auf 80386 gab es auch eine LOADALL-Instruktion, die aber subtil anders war). Damit konnte man dann zum Beispiel ohne Wechsel in den Protected Mode auf Speicher jenseits des 1. Megabytes zugreifen.
Nach undokumentierten Instruktionen zu suchen ist nicht sonderlich schwer und der Suchraum ist auch nicht so groß, insofern laufen da seit vielen Jahren Leute herum und probieren Opcodes aus. Manchmal finden sie was, manchmal nicht. Es gibt da z.B. eine undokumentierte Breakpoint-Instruktion.
Jedenfalls ... dass es da Wege geben würde, den Microcode-State zu ändern, war ja irgendwie klar. Intel shippt seit einer Weile Microcode-Updates und BIOS-Updates, die ihre Bugs im Feld fixen sollen. Das leuchtet ein, dass es da also einen Mechanismus geben wird.
#UD heißt Undefined Instruction, das ist der Fehler, den man kriegt, wenn man einen nicht existierenden Opcode auszuführen versucht. Die CPU muss also in einem bestimmten Debug-Zustand sein, um die Instruktion überhaupt als gültig zu erkennen, und in den kommt man normalerweise nicht. Die Management Engine könnte den Zustand herbeiführen, schätze ich mal, aber da haben du und ich ja keinen Zugriff drauf. Ähnlich ist das bei dieser Breakpoint-Instruktion auch. Die funktioniert nur, wenn die CPU in einem ICE läuft (oder vielleicht kann man das auch auf normalen CPUs anschalten aber ich weiß nicht wie).
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
