• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Intel - Hardwarebug

C

CrimsonKing

Guest
Das ist eine deutlich geringere Reaktion, als beim letzten WanaCry.
Das liegt daran, dass man - also die traditionell sehr linuxfreundlichen Medien - "WannaCry" prima ausschlachten konnte, um mit dem üblichen "Windows ist kaputt"-Clickbait Werbeeinnahmen zu generieren. "Alles ist kaputt" will keiner lesen.
 

-Nuke-

Well-Known Member
Es ist schwer eine Grenze zwischen "Fehler" und "Tja, doof gelaufen" zu ziehen. Das ist das Doofe an Seitenkanal-Angriffen. Aber immerhin wissen wir jetzt warum Intel bei I/O und Syscalls allgemein so dermaßen weit die Nase vorn hatte: Ihre "speculative execution" führte bereits Kernel-Code aus, obwohl sich der eigentliche Programmfluss noch im Userspace bewegte. Im Umkehrschluss wissen wir jetzt auch warum AMD bei I/O und Syscalls allgemein das Nachsehen hatte: Sie tun das nicht. Während Intel den "Fehler" schon 1995 begangen hat, haben ARM und Apple den Fehler erst kürzlich begangen.

Arbeitet der Prozessor falsch, oder macht er einen Fehler? Eher nein. Lässt sich durch die Arbeitsweise abhören was der Prozessor getan hat? Ja. Ist alles zusammen ein ganz großes Fehlverhalten: Ja.

Analog dazu kann man die Implementierung eines Krypto-Algorithmus ansehen. Jeder der noch nie was von Seitenkanal-Angriffen gehört hat, kann Bound-Checks, Typ-Prüfungen und Co. machen. Sein Code ist durch Seitenkanal-Angriffe anfällig. Man muss aktiv dagegen vorgehen. Laufzeiten glätten, Dummy Code einbauen und Co. Zeug was mit der "naiven Sicherheit des Codes" allgemein recht wenig zu tun hat.

Im Endeffekt können wir jetzt nur etwas Performance wegwerfen (Meltdown) und das Problem dauerhaft fixen. Mit Spectre V1 und V2 müssen wir jedoch einfach leben. Entweder wir haben schnelle CPUs, die wir ab und zu mal ausbremsen müssen (Hey, Syscalls sind wieder teuer), oder wir bauen konsequent langsamere CPUs. Vermutlich wird es eher wieder darauf hinauslaufen, dass gerade "der neue heiße Scheiß" im Software-Markt sich mal wieder an Syscall-Optimierung ran machen muss und dass ein Computer nicht mehr so viele VMs verträgt.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
Okay, etwas ausführlicher: Spectre basiert auf dem Ausnutzen von Seiteneffekten. Seiteneffekte lassen sich mit entsprechenden Aufwand zwar oft verhindern, in der Praxis vermeidet man diesen Aufwand aber meist oder ist sich des Risikos gar nicht bewusst. Daher würde ich Spectre nicht als Bug einordnen, sondern eher als eine letztendlich unvermeidbare Nebenwirkung von Dingen wie Spekulativer Ausführung.

Meltdown resultiert daraus, dass die CPU das Supervisor Bit einer Instruktion nicht beim Pipeline Entry prüft, sondern irgendwann später, wenn es den Herren denn mal recht ist. Man kann hier argumentieren, dass es eine gewollte Designentscheidung sein kann, aber in dem Fall hätten die Alarmglocken hinsichtlich Seiteneffekte eigentlich laut schrillen müssen. Entweder haben sie es nicht oder man hat sie ignoriert. Daher Pfusch.

Allgemein halte ich Spectre aber für wesentlich problematischer. Denn wie ich oben irgendwo schon schrieb ist Meltdown in ein paar Wochen gepatcht und damit gegessen. Spectre und ähnliche Probleme werden uns noch auf Jahre verfolgen.
 
Analog dazu kann man die Implementierung eines Krypto-Algorithmus ansehen. Jeder der noch nie was von Seitenkanal-Angriffen gehört hat, kann Bound-Checks, Typ-Prüfungen und Co. machen. Sein Code ist durch Seitenkanal-Angriffe anfällig. Man muss aktiv dagegen vorgehen. Laufzeiten glätten, Dummy Code einbauen und Co. Zeug was mit der "naiven Sicherheit des Codes" allgemein recht wenig zu tun hat.
Wenn das die Konsequenzen sind, was für einen Sinn hat dann noch der schnelle Prozessor denn was auf der einen Seite gewonnen wird, wird auf der anderen verloren. Und wenn sichere Programmierung derartig aufwendig wird dann kann man wohl zurecht nur noch von ein "bißchen" Sicherheit ausgehen was vom potenten Angreifern leicht auszuhebeln sein dürfte. Mir scheint dass da die gesammte Geschäftsgrundlage im Eimer ist und es stellt sich die Frage ob die Entwicklung von Prozessoren und Software der letzten Jahrzente sich nicht als eine konzeptionelle Sackgasse herausstellen wird.
 
Weils noch keiner hier geposted hat: Es gibt inzwischen ein intel microcode update in OpenBSD -current.

CVSROOT: /cvs
Module name: src
Changes by: patrick@cvs.openbsd.org 2018/01/11 15:31:09

Modified files:
sys/arch/amd64/amd64: acpi_machdep.c cpu.c
sys/arch/amd64/conf: files.amd64
sys/arch/amd64/include: cpufunc.h specialreg.h
Added files:
sys/arch/amd64/amd64: ucode.c

Log message:
Update the Intel microcode once the root filesystem has been mounted.
This depends on the intel-firmware package that contains newer Intel
microcode which will be installed automatically by fw_update(1).

The update should happen much earlier since updating the microcode can
add or remove not only feature flags but also whole features. For now
only update feature flags that are relevant to Spectre.

Initial diff from sf@
Tested by bluhm@
ok deraadt@
https://marc.info/?l=openbsd-cvs&m=151570987406841&w=2
 
Themenstarter #163
Kennt ihr momentan auch dieses Problem aus dem Bekanntenskreis:
PC fährt seit Update sehr langsam hoch und benötigt unmengen an Zeit für den Anmeldeprozess (unter Win10).

Könnte man sowas aufs Meltdown/Spectre Update schieben oder eher Zufall?

EDIT: Obs wirklich nach dem Update war weiß ich nicht, der Zeitraum würde einfach passen
 
Bei mir und auf der Arbeit merk ichs auch nicht, aber bei Kollegen/Bekannten mit älteren Laptops ist der PC teilweise sehr langsam (im Boot/Login) und nach Aussage seit anfang des Jahres.
Aber das wurde doch bereits thematisiert und auch nicht verschwiegen:

Der Performanceeinbruch oder die Leistungseinbuße ist bei älteren Rechnern signifikant spürbar und bei aktuellen Rechnern mit viel schnellerer CPU kaum bis garnicht. Zumindest ist das bei privaten Nutzern so, um die scheint es ja hier zu gehen.
 
Themenstarter #167
Bei meinem älteren Windows 10 Notebook (TP X61, Core2Duo 2x 1,8 Ghz, 4GB Ram) hab ich glaub ich bislang nichts bemerkt. Der bootet auch recht flott.

Villeicht ein anderes Windows oder Hardware-Problem?
 
Themenstarter #169
Villeicht ein anderes Windows oder Hardware-Problem?
Du meintest Windows(-Problem) oder Hardware-Problem denke ich mal, denn Win10 hatte ich ja bereits erwähnt.

Die Software auf dem Rechner war recht schlank und die Festplatte relativ leer. RAM wurde kaum genutzt und die CPU-Auslastung war normal. Hm vlt ist die Festplatte defekt? Ich denke das Update schließe ich erstmal aus und schau mir den Rest an, ich kann mir eine so signifikante Leistungseinbußung durch das Update kaum vorstellen
 

zuglufttier

Well-Known Member
Das ist doch immer das Problem bei Windows: Irgendwann wird das Teil langsam und man muss neu installieren, weil ein Debugging fast unmöglich wird.

Solche Aussagen machen nur Sinn, wenn man ordentlich mit einem frischen System testet. Lange Bootzeiten dürften auch rein gar nichts mit der CPU zu tun haben.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
Wenn es noch nicht geschehen ist, würde ich auf den Windows-Kisten erst einmal eine komplette Datenträgerbereinigung inklusive dem Entfernen alter Wiederherstellungspunkte durchführen. Auch eine Datenträgeroptimierung kann Wunder wirken, selbst bei SSDs. Ist der Systemstart danach noch immer extrem langsam, sollte man sich mal anschauen was alles automatisch mitgestartet wird. Irgendwie hat sehr viele Windows-Software die unangenehme Angewohnheit sich dort reinzuzecken.
 
Evtl. hilt es auch einfach mal "richtig" Herunterfahren mit Großschreibtaste -> Herunterfahren, sonst macht der auch nur sonnen hybriden standbymodus. Oder evtl. mal im Taskmanager beobachten ob irgendetwas auffällig ist. (Mehr details -> Dann auf den Reiter Details). Oder auch unter "Benutzer" im Taskmanager evtl. mal den Datenträger im Auge behalten.
 
Themenstarter #173
Wenn es noch nicht geschehen ist, würde ich auf den Windows-Kisten erst einmal eine komplette Datenträgerbereinigung inklusive dem Entfernen alter Wiederherstellungspunkte durchführen. Auch eine Datenträgeroptimierung kann Wunder wirken, selbst bei SSDs. Ist der Systemstart danach noch immer extrem langsam, sollte man sich mal anschauen was alles automatisch mitgestartet wird. Irgendwie hat sehr viele Windows-Software die unangenehme Angewohnheit sich dort reinzuzecken.
msconfig > Systemstart + Dienste bereinigen, sowie installierte Programme durchsuchen und bereinigen gehört bei mir immer zum Standart

Ich schaus mir bei Gelegenheit nochmal genauer an, evtl finde ich noch ein paar Dinge die ich rauswerfen kann