Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren

[Monsta]

Der Hacker schreibt ein Programm, welches Spectre ausnutzt. Selbstverständlich compilt er es mit einem alten compiler. Dann lässt er es auf einer virtuellen Maschine in der Cloud laufen. Somit kann er Daten klauen.

Und wie soll das Programm auf meinen Computer kommen?

[gravitationsfeld]

Der Hacker schreibt ein Programm, welches Spectre ausnutzt. Selbstverständlich compilt er es mit einem alten compiler. Dann lässt er es auf einer virtuellen Maschine in der Cloud laufen. Somit kann er Daten klauen.
Nein, du hast es nicht verstanden.

Es gibt Mitigations die der Compiler automomatisch in ein Programm einfuegt. Diese schuetzen gegen einen Angriff von Spectre. Das hat ueberhaupt nichts damit zu tun Hacker kompilieren oder nicht.

[PrivateCeralion]

Nein, du hast es nicht verstanden.

Es gibt Mitigations die der Compiler automomatisch in ein Programm einfuegt. Diese schuetzen gegen einen Angriff von Spectre. Das hat ueberhaupt nichts damit zu tun Hacker kompilieren oder nicht.

Das heißt, Programme können durch das Compilen gegen Spectre geschützt werden.Wie wird denn der Kernel sicher?

[PrivateCeralion]

Das ist auch noch interessant:
https://twitter.com/FPiednoel/status/953442231519559681

That looks legitimate, but I am really not happy that an x86 binary can turn off the Patching against #Meltdown and #Spectre "

Zur Info, Francois Piednoël war 20 Jahre principal engineer bei Intel.

[Ganon]

Das heißt, Programme können durch das Compilen gegen Spectre geschützt werden.Wie wird denn der Kernel sicher?

Ein Kernel wird in der Regel mit dem gleichen Compiler kompiliert. ;) Zusätzlich braucht der Kontext-Wechsel Userspace<->Kernelspace noch extra Absicherung, die manuell erfolgt.

[vanquish]

Das ist auch noch interessant:
https://twitter.com/FPiednoel/status/953442231519559681

That looks legitimate, but I am really not happy that an x86 binary can turn off the Patching against #Meltdown and #Spectre "

Zur Info, Francois Piednoël war 20 Jahre principal engineer bei Intel.

Das Programm macht nichts anderes als via Registry die Patches ein- und auszuschalten (Admin-Recht erforderlich). Deaktiviert ist das ganze erst nach einem Reboot.
Mehr als ein erster Hotfix ist das auch von Microsoft nicht. Im Grunde muss man aber wohl erst den ganzen Code für jedes einzelne Programm durchgehen und ggf. entsprechende Gegenmaßnahmen ergreifen. Das kann dauern und wird viel Testerei und Instabilitäten mit sich bringen. Da wird der ein oder andere wohl froh um den Schalter sein.
Es würde mich wundern, wenn Microsoft den direkten Zugriff auf die Hardware bei dieser Gelegenheit nicht restriktiver gestaltet. Aber absolute Sicherheit bringt das auch nicht. Selbst wenn Intel in zwei, drei Jahren überarbeitete Prozessoren herausbringt. Auch diesen wohnt der nächste grosse Fehler bereits inne. Und es wird wieder ein Team geben, das mit Know-How und Geld an solchen Dingen forschen mag... Zu welchem Zwecke auch immer. Der Sicherheit wegen? oO wohl kaum ...

[lumines]

Und es wird wieder ein Team geben, das mit Know-How und Geld an solchen Dingen forschen mag... Zu welchem Zwecke auch immer. Der Sicherheit wegen? oO wohl kaum ...

Was wäre die Alternative? Nicht forschen, den Kopf in den Sand stecken und so tun, als sei alles in Ordnung? Man kann nur die Fehler aufdecken und daraus Konsequenzen ziehen.

[yummy_candy]

Allein schon sämtliche Kryptoroutinen erfordern ein Forschen nach Schwachstellen.

[Ganon]

Was wäre die Alternative? Nicht forschen, den Kopf in den Sand stecken und so tun, als sei alles in Ordnung? Man kann nur die Fehler aufdecken und daraus Konsequenzen ziehen.

Ist ja nun auch nicht der erste Fall. WEP und WPA waren sicherheitstechnisch auch Reinfälle und mussten letztendlich vom Konsumenten selbst ausgetauscht werden. Da war die Antwort auch: Leb damit oder kauf dir was neues.

Genauso wie es jedes Gerät außerhalb des Support-Zeitraums des Herstellers betrifft, vollkommen unabhängig davon ob das Sicherheitsproblem in Hardware oder in Software vorliegt: Leb damit oder kauf dir was neues.

Hier haben wir wenigstens Bemühungen das Problem überhaupt in den Griff zu kriegen und nicht nur "Kauf dir was neues" zu hören :D

[vanquish]

Ich stelle das Forschen nach Schwachstellen nicht in Frage. Ich stelle mir aber schon die Frage WER und WARUM.

Google hat endlos Geld. Microsoft hat endlos Geld. Intel hat endlos Geld. Würde es diesem Dreigestirn nur um die Sicherheit gehen würde man annehmen, dass sie sich zusammen engagieren und nicht jeder zig XYZ-Teams für die Sicherheit beschäftigt. Aber glaubt Ihr nur weiter an den Weihnachtsmann und daran, dass alle so wie VW, nur um euer bestes wollen. ;)

[Ganon]

Ich stelle mir aber schon die Frage WER und WARUM.

Wer: Forscher (bezahlt und/oder angestellt von unterschiedlichen Unternehmen)
Warum: Sicherheitslücken finden und schließen (lassen)

Alles Andere ist reine Verschwörungstheorie und führt zu nichts.

Und wenn eine handvoll Forscher sich ein mögliches Sicherheitsproblem vornehmen, dann bringt es nichts noch 1000 andere Forscher mit dran zu hängen. Mit jeder weiteren Person steigt der Kommunikations- und Verwaltungsoverhead. Da ist es sinnvoller viele kleinere Teams an vielen unterschiedlichen Problemen arbeiten zu lassen, statt alle an einem Problem.

[lumines]

Google hat endlos Geld. Microsoft hat endlos Geld. Intel hat endlos Geld. Würde es diesem Dreigestirn nur um die Sicherheit gehen würde man annehmen, dass sie sich zusammen engagieren und nicht jeder zig XYZ-Teams für die Sicherheit beschäftigt. Aber glaubt Ihr nur weiter an den Weihnachtsmann und daran, dass alle so wie VW, nur um euer bestes wollen. ;)

Äh, Microsoft, Intel und Google sind Unternehmen. Dass die nicht die Speerspitze der Forschung darstellen, weil sie eben damit beschäftigt sind Gewinn zu machen, sollte klar sein. Etwas anderes würde ich auch nicht erwarten. Dass sie da in ihrem eigenen Interesse forschen, sollte auch klar sein. Da das Interesse bei Microsoft und Google aber relativ breit gefächert ist, weil sie praktisch alles rund um Hardware und die Infrastruktur des Internets betrifft, sollte man sich aber auch nicht wundern, wenn die eben auch einmal ein bisschen in den CPUs rumstochern.

[vanquish]

Da stimme ich dir zu. Auch mit dem Teams etc. Man kann es aber dann auch anders Kommunizieren und alle einbinden. Da muss man dann nicht bis kurz vor Weihnachten warten bis man das ganze anderen OS-Entwicklern mitteilt.

Sowohl der Auftraggeber hat Motive als auch der Forscher. Ich weiss es ist müssig darüber zu diskutieren, da wir nicht alle Informationen haben/kennen. Auch die Tatsache, dass man nur allzu leicht in Verschwöhrungstheorien abgleiten kann ist mir durchaus bewusst. Aber man sollte nicht so tun als ob Intel, Google (das Project Zero finanziert) und Microsoft nicht in der Lage sein sollten in Fragen der Sicherheit zusammen zu arbeiten. Das muss natürlich in unterschiedlichen Teams passieren (allein schon wegen der unterschiedlichen Blickwinkel).

Die NASA hat früher (60/70) einmal ganz gut vorgemacht wie das funktioniert. Beim US-Militär funktioniert das bisweilen immer noch. Und da sind zig Firmen daran beteiligt. Es braucht mir daher keiner zu erzählen, dass diese grossen drei in grundsätzlichen Sicherheitsfragen nicht zusammen arbeiten könnten wenn sie wollten.

Und wenn Intel nicht die Speerspitze der Grundlagenforschung ist was Microprozessoren anbelangt, dann weiss ich auch nicht wer es sein soll ... Weder der Russe noch der Chinese können da mithalten. Bis vor ein paar Jahren war im OS Bereich Windows auch hier die Speerspitze. An die hohe Unterstützung der Geräteanzahl kommt aber auch heute kein Android heran. Und zu Google muss ich nicht wirklich was sagen. Nimmt man noch Facebook dazu sind alle vier US Konzerne die das Leben der meisten Menschen hier bestimmen zusammen. Vom Arbeitsalltag über das Surfen im Internet und dem Telefnoieren mit der Familie. Das einzige was noch fehlt wäre das Auto. Aber der Google Assistent schafft auch das noch. :D

EDIT: Mir ist klar dass es sich hier um Unternehmen handelt. Aber diese bestimmen überwiegend unser Leben heutzutage. Damit einher geht auch Verantwortung. Das gilt nicht nur für VW oder!?

[vanquish]

Aber zurück zum Theama des Threads. Kann mir wer sagen, was die beiden Parameter aussagen sollen:

BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False

Sie werden angezeigt, wenn ich das von Microsoft bereitgestellte Skript für den Spectre/Meltdown-Test laufen lasse. Wenn ich das richtig interpretiere ist eine "Mitigation" nicht aktiviert, weil in Hardware nicht vorhanden.

EDIT: Ich Rindvieh ... Hab's kapiert ... Ist alles gut.

[lumines]

Die NASA hat früher (60/70) einmal ganz gut vorgemacht wie das funktioniert. Beim US-Militär funktioniert das bisweilen immer noch. Und da sind zig Firmen daran beteiligt. Es braucht mir daher keiner zu erzählen, dass diese grossen drei in grundsätzlichen Sicherheitsfragen nicht zusammen arbeiten könnten wenn sie wollten.

Sowohl die NASA als auch das US-Militär werden aber von der US-Regierung finanziert. Das ist doch alles staatlich.

Und wenn Intel nicht die Speerspitze der Grundlagenforschung was Microprozessoren anbelangt ... Weder der Russe noch der Chinese können da mithalten. Bis vor ein paar Jahren war im OS Bereich Windows auch hier die Speerspitze.

Der Marktanteil sagt nicht besonders viel über die Bedeutung für die Forschung aus. Ob Intel jetzt eine Milliarde oder zwei Milliarden CPUs verkauft, bringt das Wissen über Prozessoren nicht voran. Genau so verhält sich das mit Windows. Es ist doch ziemlich bezeichnend, dass sich gerade bei Betriebssystemen und deren Architektur praktisch nichts mehr seit GNU/Linux, BSD und Windows getan hat. Heute ist alles entweder NT-basiert oder Unix-verwandt. Insofern wahrscheinlich nicht das beste Beispiel.

Genau so verhält es sich mit Prozessoren: RISC-V wird wahrscheinlich einen stärkeren Einfluss auf die Architektur unserer Rechner nehmen als eine neue Generation von Intel-CPUs. Die Leute hinter RISC-V werben jetzt sogar aktiv dafür, dass man damit CPUs bauen kann, die stärker auf Sicherheit getrimmt sind als x86, weil man von Anfang an alles daran verifizieren und das dann selbst in Silizium gießen können wird. Sicher nicht uninteressant für manche Bereiche.

EDIT: Mir ist klar dass es sich hier um Unternehmen handelt. Aber diese bestimmen überwiegend unser Leben heutzutage. Damit einher geht auch Verantwortung. Das gilt nicht nur für VW oder!?

Du schreibst das so, als würde ich Intel, Google und Co. verteidigen. Das mache ich natürlich nicht. Ich glaube nur, dass es gewisse Grenzen gibt, aus denen solche Unternehmen nicht einfach ausbrechen können. Wenn sich Intel zwischen Forschung und Gewinn entscheiden muss, werden sie immer Letzteres wählen.

VW ist ja noch einmal etwas anderes. Die haben ja bewusst bei Abgastests getäuscht. Intel dagegen hat "nur" 20 Jahre ein paar ehemals exotische Sicherheitsprobleme ignoriert. Da werden die Grenzen schon verschwommener, was richtig und falsch ist. Man könnte natürlich sagen, dass Intel fast 20 Jahre mit geborgter Leistung gewirtschaftet hat, aber wenn sich rausgestellt hätte, dass solche Angriffe wie Spectre oder Meltdown doch nicht praktikabel gewesen wären, dann hätten sie Leistung brach liegen lassen.

[vanquish]

Sowohl die NASA als auch das US-Militär werden aber von der US-Regierung finanziert. Das ist doch alles staatlich.
Ist mir klar. Schaue ich mir die Lieferkette von VW an. Funktioniert das dort auch. Der einzige Unterschied ist, dass Sie Konkurrenten sind. Aber auch Konkurrenten können zusammen arbeiten. Joint Ventures gibt es genug. Auch bei den genannten untereinander. Oder Intel/AMD. Intel bekommt wohl AMD GPUs für ihre Halbleiter. usw. Wille und Weg.


Der Marktanteil sagt nicht besonders viel über die Bedeutung für die Forschung aus. Ob Intel jetzt eine Milliarde oder zwei Milliarden CPUs verkauft, bringt das Wissen über Prozessoren nicht voran. Genau so verhält sich das mit Windows. Es ist doch ziemlich bezeichnend, dass sich gerade bei Betriebssystemen und deren Architektur praktisch nichts mehr seit GNU/Linux, BSD und Windows getan hat. Heute ist alles entweder NT-basiert oder Unix-verwandt. Insofern wahrscheinlich nicht das beste Beispiel.

Genau so verhält es sich mit Prozessoren: RISC-V wird wahrscheinlich einen stärkeren Einfluss auf die Architektur unserer Rechner nehmen als eine neue Generation von Intel-CPUs. Die Leute hinter RISC-V werben jetzt sogar aktiv dafür, dass man damit CPUs bauen kann, die stärker auf Sicherheit getrimmt sind als x86, weil man von Anfang an alles daran verifizieren und das dann selbst in Silizium gießen können wird. Sicher nicht uninteressant für manche Bereiche.
Hierzu sage ich nichts weiter. Da wir aneinander vorbei reden. Das Teureste an der Entwicklung von Chips ist nicht deren Design sondern die Entwicklung der Technik für den Bau des entworfenen Designs. Intel liegt hier Meilen vor den anderen. Insbesondere was die Größe der Halbleiter anbelangt. Und ja Marktanteil sagt darüber nichts aus. Aber eben der technische Vorsprung beim effizienten Bau des entworfenen Designs. Ist auch eine Kosten-/Nutzen Frage. Auch die Sicherheit!


Du schreibst das so, als würde ich Intel, Google und Co. verteidigen. Das mache ich natürlich nicht. Ich glaube nur, dass es gewisse Grenzen gibt, aus denen solche Unternehmen nicht einfach ausbrechen können. Wenn sich Intel zwischen Forschung und Gewinn entscheiden muss, werden sie immer Letzteres wählen.

VW ist ja noch einmal etwas anderes. Die haben ja bewusst bei Abgastests getäuscht. Intel dagegen hat "nur" 20 Jahre ein paar ehemals exotische Sicherheitsprobleme ignoriert. Da werden die Grenzen schon verschwommener, was richtig und falsch ist. Man könnte natürlich sagen, dass Intel fast 20 Jahre mit geborgter Leistung gewirtschaftet hat, aber wenn sich rausgestellt hätte, dass solche Angriffe wie Spectre oder Meltdown doch nicht praktikabel gewesen wären, dann hätten sie Leistung brach liegen lassen.

Soviel unterscheiden sich die beiden nicht voneinander. Ich erinnere mich z. B. noch gut daran, wie Intel andere Unternehmen mit besonderen Bonusprogrammen und Nachlässen dazu animiert hat keine AMD CPUs zu verbauen. Nicht umsonst hat die EU dafür auch eine Strafe verhängt.

Die 20 Jahre alte Lücke ist mir ehrlich gesagt auch egal. Das habe ich früher in diesem Thread bereits kund getan. Das passiert halt.
Es sei aber angemerkt, dass es auch anders laufen hätte können. Ich weiss nicht mehr wo ich es gelesen hatte. Aber ein Forscher hat schon ein Jahr nach dem PentiumPro auf mögliche Seitenkanal-Attacken hingewiesen.

Ich nehme es hier keinem Übel wenn er den Counterpart einnimmt und die drei verteidigt. :D ... Es soll auch nicht so rüberkommen als ob ich einer Utopie anhänge. Mir kommt es nur so vor als ob jeder heutzutage nach Verantwortung fragt. Sie aber niemand wirklich einfordern will. Es kommt immer ein ABER: z. B. 2 Big 2 Fail (Banken), Arbeitsplätze (VW), Konkurrenzsituation (Intel/Microsoft/Google). Ich wünschte mir machmal, dass man solch grosse Unternehmen zerschlägt. So wie früher AT&T o. ä. Weil Sie letztendlich mehr Schaden anrichten als Nutzen. Das will nur niemand hören. ;)

[Complicated]

5. mal: Es wird immer auf das gleiche Paket verlinkt und es enthält alle Microcodes. Das Paket sagt nicht, dass es für Spectre ist (Meltdown sowieso nicht), noch dass alle der aufgelisteten CPUs ein Update bekommen hat.

Sorry, aber ich weiß echt nicht mehr was ich sonst noch dazu sagen soll, außer dass die Deutung von Hardwareluxx falsch ist und die Liste unnötig und redundant.
Vor allem könntest du mal aufhören so zu tun als ob das jemand behauptet hätte.

Sogar bei Hardwarelux steht eindeutig, dass der Patch enthalten sein KANN. Das beziehen sie einfach darauf, dass das Datum aktuell ist. Du musst lediglich aufhören damit zu unterstellen, dass jemand behauptet das IST so. Dann brauchst du auch nicht 5 mal das selbe schreiben, weil dir 5 mal jemand sagt er habe das überhaupt nicht behauptet. Das Verständnisproblem liegt hier ganz offensichtlich auf deiner Seite.

[Ganon]

Vor allem könntest du mal aufhören so zu tun als ob das jemand behauptet hätte.

Hardwarelux hat eine Liste spezifisch für Meltdown/Spectre Microcodes. Allerdings alles für Linux-Distributionen:
https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/45319-intel-kaempft-mit-schwerer-sicherheitsluecke-im-prozessor-design.html?start=14

Die Aussage ist eine Behauptung, kein "vielleicht", "kann sein", "möglicherweise". Und diese ist falsch. Ganz einfach. Die Liste zeigt weder die Liste der wirklich aktualisierten Microcodes, noch zeigt sie, welche Prozessoren gefixt wurden. Sie zeigt einfach nur die Liste aller Prozessoren, für die ein Microcode im Paket enthalten ist.

Deine "Vermutungen" darauf, einen Post weiter, habe ich ebenso korrigiert.

Wenn du dich durch die Korrekturen persönlich angegriffen fühlst, ist das ehrlich gesagt nicht mein Problem.

[Complicated]

Ja und im nächsten Beitrag
Es scheint also eine Liste zu sein von CPUs, welche ein update erhalten haben in 2018 - daher sind auch Itanium CPUs dabei. Wofür dieses Update ist, wird dadurch natürlich nicht klar. Vor allem wenn man die zurück gezogenen Updates in Betracht zieht.
Hardwareluxx schreibt:
Hier nennt Intel zahlreiche Modelle, deren Microcode bereits ein Update erhalten hat bzw. noch erhalten wird. Darunter sind auch Core-Duo- und Pentium-3-Prozessoren. Intel kann die Sicherheitslücke also auch schon bei den älteren Modellen schließen. Allerdings muss die Liste für jedes einzelne Modell weiter im Auge behalten werden, denn noch ist das Update nicht für jeden Prozessor verfügbar.
Was soll also das dauernde auf etwas hinweisen was längst geklärt ist?

[Ganon]

Ja und im nächsten Beitrag

Die Korrektur ist dafür, "dass die CPUs 2018 ein Update erhalten haben". Haben sie nämlich (noch) nicht. Auch ziemlich einfach verständlich gewesen. Und "welche ein update erhalten haben in 2018" ist auch kein "vielleicht", "möglicherweise" oder "könnte sein"...

edit: Ganz zu schweigen davon, dass die Aussage "bereits ein Update erhalten hat bzw. noch erhalten wird" auch falsch ist... Intel wird garantiert nicht den Pentium II patchen.

[stimulator]

Irgendwie nervt ihr beide, Ganon und Complicated. Könnt ihr nicht einfach verschwinden und weniger den Thread vollkacken?

[mboeller]

Irgendwie nervt ihr beide, Ganon und Complicated. Könnt ihr nicht einfach verschwinden und weniger den Thread vollkacken?
liegt IMHO doch nur an einer Person, wieso machst du auch den Ganon an?

[stimulator]

Weil beide sich einig sind dass sie sich uneinig sind, schon seit gefühlt hundert Seiten. Richtige Informationen gehen hier im Müll unter. Warum kann man sowas nicht per PN ausmachen?

[Birdman]

@Complicated

Luxx schreibt einfach Bullshit und wiegt damit User in falscher Sicherheit.
Auch was die Abdeckung der unterstützten Prozessoren angeht scheint Intel sein Versprechen halten zu können. Hier nennt Intel zahlreiche Modelle, deren Microcode bereits ein Update erhalten hat bzw. noch erhalten wird. Darunter sind auch Core-Duo- und Pentium-3-Prozessoren. Intel kann die Sicherheitslücke also auch schon bei den älteren Modellen schließen.
...
Hier die vollständige Liste:


Und es folgt eine Liste ALLER 2371 Prozessormodelle welche Intel seit 1995 und dem (Fast)Ur-Pentium mit 75Mhz Taktfrequenz jemals gefertig hat.

Also jeder der dies einfach so liest, MUSS aus den verwendeten Worten schliessen, dass Intel für alle diese CPUs ein Update rausgebracht hat oder bringen wird und das ist einfach nur falsch.

[Ganon]

schon seit gefühlt hundert Seiten. Richtige Informationen gehen hier im Müll unter. Warum kann man sowas nicht per PN ausmachen?

Es sind 4 Beiträge auf der letzten Seite... Genauso viel wie jetzt dein Beitrag (jedoch völlig Off-Topic und nicht On-Topic) verursacht hat.

Aber nur zur Info für dich: Die Diskussion um angebliche Microcode-Updates ist für mich an der Stelle auch vorbei. Für alles weitere kann ich nichts mehr ;)

[gedi]

Anderes Tool, gleiches Ergebnis.

http://up.picr.de/31552946kz.jpg


Nach wie vor Win 10 Build 17074, Maximus X Hero - Bios 1003

Die Performance geht aber reproduzierbar nach unten (8700k@5g). Z.B.

Cinebench R15 (Win 10 16299): 1653

Cinebench R15 (Win 10 17074): 1522

[Ganon]

Ich finde es übrigens immer wieder lustig wie Leute vor Meltdown und Spectre in akute Panik verfallen, aber sorglos irgendwelche (Closed-Source) Prüf-Tools von Dritten aus dem Netz laden und einfach ausführen :ugly:

Wenn ich kriminell wäre, wäre so ein Prüftool jetzt eine 1a Gelegenheit irgendwelchen Leuten einen Trojaner unterzujubeln.

[vanquish]

https://en.wikipedia.org/wiki/Steve_Gibson_(computer_programmer)
Das oben abgebildete Tool. Alternative ist das Microsoft Skript. Den Müll von Ashampoo, den fast jede Seite a la CHIP o. ä. zitiert, würde ich mit der Kneifzange nicht anfassen. Die haben früher mit ihren Programmen allen möglichen Schund nebenher mitinstalliert. Wie es heute aussieht weiss ich allerdings nicht. :D

[PrivateCeralion]

Ein Kernel wird in der Regel mit dem gleichen Compiler kompiliert. ;) Zusätzlich braucht der Kontext-Wechsel Userspace<->Kernelspace noch extra Absicherung, die manuell erfolgt.

Danke für die Erklärung :)

[Pirx]

Ich finde es übrigens immer wieder lustig wie Leute vor Meltdown und Spectre in akute Panik verfallen, aber sorglos irgendwelche (Closed-Source) Prüf-Tools von Dritten aus dem Netz laden und einfach ausführen :ugly:...
Woher weißt du, daß sie es sorglos tun?

Ich bin eher auch besorgt:ulol: darüber, daß man den Schutz insb. vor Meltdown einfach mal per Mausklick ausschalten kann.:lol: edit: ok, als Admin
Wobei es mir andererseits mit meinem FX relativ egal sein kann.

[Razor]

Oh mann Ganon,
Steve Gibson sagt Dir also nichts... ganz offensichtlich.

Hier mal mein Ergebnis dieses genialen Tools, welches wenigstens mal erklärt, warum es was wie wertet.
Es zeigt hervorragend auf, was man alles OHNE Admin-Rechte so zeigen kann und was MIT (siehe Buttons).

Das "Rote" ist überigens unter Win10 in sattes "Grün" gewandelt... gleiches System:
ASUS Z87-A mit i7-4770S (Haswell auf LynxPoint mit AMI Insyde EFI Bios)

NICHT von ASUS gepatcht, sondern von mir mit einem Bios aus 2014 und ein wenig... OK, ein wenig mehr... Recherche im iNet bzw. einschlägigen Foren.
Ergo: ein Bios, welches mit dem originalen Microcode von Intel (CPUID: 306C3) gepatcht wurde und ja, es enthält den PTI Flaw Fix:
INTEL Download Linux- Processor Microcode Data File (https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File)

Welche "Beweise" brauchst Du also noch, Ganon?

Nette Erkenntnisse zur Seite:
- Bios uCode-Stand = 19
- Win7 uCode-Stand = 1C
- Win10 uCode-Stand = 1E
- "mein" uCode-Stand = 23
(der nun auch unter Win7/10 ausgewiesen wird)

Fazit:
- Microsoft könnte das uCode-Update auch selber integrieren, tut es aber nicht (habe sie schon getan)
- ASUS könnte auch ältere Plattformen Patchen, tun es aber nicht (ist kein großer Aufwand)
- DELL hat am 2.1.2018 (!) "sein" Update für die paar T1700 in der Firma gebracht (Ebenfalls Haswell)... vorbildlich!
(vor allem, weil die "News" erst am 3.1. begannen ;-)

Der Gipfel ist aber, dass selbst meine "uralt" Haswell CPU Technologie an Board hat, den Meltdown-Fix in Hardware zu unterstützen... was unter Win10 geschieht, nicht aber unter Win7.

:up: DANKE Microschrott... vielen, vielen Dank! :up:
(und schönen Gruß an alle, die dieser "netten" Firma hinterher "määääähhhhhnnnnn"... erst keinen CPU-Support mehr, dann verhinderte Updates und nun DAS!)

Sorry, aber das Ganze ist "sauber" geplant und getimed worden.
Und wie man an meinem screen gut sehen kann, stammt der CPU-Fix für "meine" CPU vom 20.11.2017.

Anbei zudem die Release-Notes zum Microcode Release:
Intel Processor Microcode Package for Linux
20180108 Release

-- Updates upon 20171117 release --
IVT C0 (06-3e-04:ed) 428->42a
SKL-U/Y D0 (06-4e-03:c0) ba->c2
BDW-U/Y E/F (06-3d-04:c0) 25->28
HSW-ULT Cx/Dx (06-45-01:72) 20->21
Crystalwell Cx (06-46-01:32) 17->18
BDW-H E/G (06-47-01:22) 17->1b
HSX-EX E0 (06-3f-04:80) 0f->10
SKL-H/S R0 (06-5e-03:36) ba->c2
HSW Cx/Dx (06-3c-03:32) 22->23
HSX C0 (06-3f-02:6f) 3a->3b
BDX-DE V0/V1 (06-56-02:10) 0f->14
BDX-DE V2 (06-56-03:10) 700000d->7000011
KBL-U/Y H0 (06-8e-09:c0) 62->80
KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80
KBL-H/S B0 (06-9e-09:2a) 5e->80
CFL U0 (06-9e-0a:22) 70->80
CFL B0 (06-9e-0b:02) 72->80
SKX H0 (06-55-04:b7) 2000035->200003c
GLK B0 (06-7a-01:01) 1e->22
Wer's nicht weiß: hexadezimale Notation des Wertes "306C3".
Und jetzt wollen wir noch mal scharf nachdenken, was da wohl zwischen den Releases vom 17.11.2017 und 8.1.2018 an einer Haswell CPU gepatcht wurde.
OK, ist jetzt wirklich nicht wirklich kompliziert... aber man muss sich zumindest mal die Mühe machen und "lesen", was bekannter Maßen bildet.

Also, Ganon, was nun?

Razor

Spectre & Meltdown Vulnerability
and Performance Status

Vulnerable to Meltdown: NO
Vulnerable to Spectre: NO
Performance: SLOWER
(full details below)

In early 2018 the PC industry was rocked by the revelation that common processor design features, widely used to increase the performance of modern PCs, could be abused to create critical security vulnerabilities. The industry quickly responded, and is responding, to these Meltdown and Spectre threats by updating operating systems, motherboard BIOSes and CPU firmware.

Protection from these two significant vulnerabilities requires updates to every system's hardware-its BIOS which reloads updated processor firmware-and its operating system-to use the new processor features. To further complicate matters, newer processors contain features to minimize the performance impact of these important security improvements. But older processors, lacking these newer features, will be significantly burdened and system performance will suffer under some workloads.

This InSpectre utility was designed to clarify every system's current situation so that appropriate measures can be taken to update the system's hardware and software for maximum security and performance.

This system's present situation:

• This 64-bit version of Windows has been updated for full awareness of both the Spectre and the Meltdown vulnerabilities. If the system's hardware (see below) has also been updated, this system will not be vulnerable to these attacks.

• This system's hardware has been updated with new features required to allow its operating system to protect against the Spectre vulnerabilities and/or to minimize their impact upon the system's performance. (Protection from the Meltdown vulnerability does not require BIOS or processor updates.)

• This system's Intel processor provides high-performance protection from the Meltdown vulnerability. A properly updated operating system will be able to provide protection without significant system slowdown.

• This system's Intel processor provides high-performance protection from the Meltdown vulnerability, but this version of Windows is not taking advantage of those features to offer that protection without performance penalties. (It could and should!) You may wish to considering disabling this system's Meltdown protection until it is offered at lower system performance cost.

Due to the potential performance impact of these vulnerability protections, which may be particularly burdensome on older hardware and operating systems that cannot be updated, either one or both of these protections may be disabled with Windows registry settings. This system's "protection disable" is currently set as follows:

• The system's registry is configured to enable both of the Spectre and Meltdown protections. Within the bounds of any limitations described above, Windows will work with the system's processor to prevent the exploitation of these vulnerabilities.

Guidance & Observations

The Windows OS installed on this young Intel-based system is employing the slowest approach for preventing Meltdown vulnerability attacks despite the fact that this system's modern processor does support high-speed prevention. This is something that Microsoft could fix if they chose to. (They did it for the latest Windows 10.) The question is: Will they step up and do what they should? or will they use this as additional pressure to push users where they clearly do not wish to go?

When enabled and active, both of these vulnerability protections come at some cost in system performance, and Meltdown attack protection may be quite expensive on older systems or under versions of Windows where Microsoft has not bothered to implement high-speed solutions. If this system's performance is more important than security, either or both of the vulnerability protections can be disabled to obtain greater performance.

When InSpectre is run with elevated administrative privilege, each button below toggles its respective protection on or off. Any changes will take effect after the system is restarted. Each button will be disabled if its protection is not available to be changed.

For more information see GRC's InSpectre web page (https://www.grc.com/inspectre.htm)

Copyright © 2018 by Gibson Research Corporation

[Ganon]

Also, Ganon, was nun?

Es folgt nun meine Erkenntnis, dass du den Thread vermutlich nicht mitverfolgt hast. Du berichtest absolut nichts Neues. Aber danke für die Zusammenfassung.

Nebenbei gibt es kein BIOS-Update gegen Meltdown. Das Hardwarefeature zur Eindämmung des Performance-Hits heißt PCID und INVPCID. Das Erste gibt's seit Sandy-Bridge, das Zweite seit Haswell.

edit: Und so allgemein: Die "Empfehlung"/"Ratschlag"/"Hinweis" des Tools, dass man sich vielleicht wünscht den Meltdown-Fix aus Performance-Gründen zu deaktivieren ist einfach mal voll daneben. Bei Spectre kann man ja noch diskutieren. Aber Meltdown nicht, nein, so gar nicht.

[Freestaler]

edit: Und so allgemein: Die "Empfehlung"/"Ratschlag"/"Hinweis" des Tools, dass man sich vielleicht wünscht den Meltdown-Fix aus Performance-Gründen zu deaktivieren ist einfach mal voll daneben. Bei Spectre kann man ja noch diskutieren. Aber Meltdown nicht, nein, so gar nicht.

Generell bin ich ja bei dir, hier jedoch noch den Hinweis, in einer Zeit von "cumulativenupdates" find ich es okay. Die grc tools sind generell nicht für den ultra-DAU gedacht. Und das ist okay. Wer nicht lesen will, okay. Auch tools für leute mit it verstand dürfen ein gui haben. .. ps: Auch ein messer kann gefährlich sein. Generell ist die Situation sowieso strange.. powershell scripts vo ms sind nur peinlich, intel und amd haben auch nix. Fraglich.

[Schnoesel]

Sicherheitslücke Spectre: Intel bestätigt Reboot-Problem nach BIOS-Update

https://www.computerbase.de/2018-01/spectre-bios-update-reboot-problem/

"Vor einer Woche wurden in diesem Zusammenhang noch ausschließlich Haswell und Broadwell genannt, aber auch Ivy Bridge, Sandy Bridge, Skylake und Kaby Lake sind „in einigen Konfigurationen“ betroffen."

Ich bin schockiert wie vielen anscheinend die Sicherheit ihres PCs am Arsch vorbei geht (siehe CB Kommentare). Alles dabei von "existiert doch schon so lang und nie ist was passiert" bis "ich habe eh nix zu verbergen". Es ist unfassbar.

[Dorn]

Was machen die User welche nie ein BIOS microcode updaten bekommen werden? Die Großzahl der PCs von Endanwender werden doch eh niemals ein BIOS update installieren. Wissen ja auch nicht mal was das ist...

[lumines]

Was machen die User welche nie ein BIOS microcode updaten bekommen werden? Die Großzahl der PCs von Endanwender werden doch eh niemals ein BIOS update installieren. Wissen ja auch nicht mal was das ist...

Na ja, die meisten Notebook-Besitzer mit dedizierter GPU und Windows sehen auch fast nie Updates für ihre Treiber. Mit WebGL kann man da dann auch haufenweise lustige Sachen anstellen. Insofern haben wir da ein ähnliches Beispiel, bei dem relativ hardwarenahe Probleme nie behoben werden und aus Erfahrung kann man da sagen, dass exakt nichts passiert. Es ist eben sicherheitstechnisch ein bisschen Russisch Roulette.

[Ganon]

Ich bin schockiert wie vielen anscheinend die Sicherheit ihres PCs am Arsch vorbei geht (siehe CB Kommentare). Alles dabei von "existiert doch schon so lang und nie ist was passiert" bis "ich habe eh nix zu verbergen". Es ist unfassbar.

Das ist ja das was ich vor ewig vielen Seiten ja mal kritisiert habe. Es wird imo viel zu sehr auf der Performance rumgeritten als auf den Sicherheitsproblemen.

Was machen die User welche nie ein BIOS microcode updaten bekommen werden? Die Großzahl der PCs von Endanwender werden doch eh niemals ein BIOS update installieren. Wissen ja auch nicht mal was das ist...

Zumindest was sie machen sollten: Weiterhin nicht jeden Kram von irgendwo ausführen und regelmäßig Browser-Updates installieren (Site-Isolation aktivieren für Chrome-Nutzer), Adblocker installieren. Bei den meisten Notebooks von größeren Herstellern kommen BIOS Updates übrigens über irgendwelche Live-Update Tools. Die sollten sie auch durchführen, auch ohne zu wissen was das ist.

Vielleicht reicht Microsoft ja auch noch mal ein Patchset nach, was die Auswirkungen von Spectre verringert, auch ohne BIOS Update. Vielleicht geschieht auch noch ein Wunder und MS verteilt die Microcode-Updates über den Windows-Updater.

[deekey777]

Ich finde es übrigens immer wieder lustig wie Leute vor Meltdown und Spectre in akute Panik verfallen, aber sorglos irgendwelche (Closed-Source) Prüf-Tools von Dritten aus dem Netz laden und einfach ausführen :ugly:

Wenn ich kriminell wäre, wäre so ein Prüftool jetzt eine 1a Gelegenheit irgendwelchen Leuten einen Trojaner unterzujubeln.
Das Tool ist von hier: https://www.grc.com/inspectre.htm

BOGUS “SmartScreen” WARNING from Edge and IE11 Browsers
Windows Defender “SmartScreen” appears to have decided that InSpectre is malware. This also happened briefly after the release of our Never10 utility. In this case, it is likely due to the fact that InSpectre's initial release was triggering anti-virus scanners due to the program's use of a specific registry key used to enable and disable the Meltdown and Spectre protections. The second release obscures its use of that (apparently worrisome) key and now appears to pass through most A/V without trouble. So we are hopeful that this SmartScreen false alarm will disappear soon.

In the meantime, PLEASE do not get a copy of this program from any 3rd-party download site, since that one could actually be malicious. If you have any non-Microsoft web browser (Chrome, Firefox, Opera, etc.) you should be able to obtain and use InSpectre without trouble. If you have a friend who is using some other computer (Windows 7 has no problem with this either) ask them to grab it from here and send it to you. Since the program is only 122k (written in assembly language) it's feasible to eMail it.

Erinnert mich an beA, als am 22.12.2017 auch empfohlen wurde, Warnungen zu ignorieren.

[Dorn]

Vielleicht reicht Microsoft ja auch noch mal ein Patchset nach, was die Auswirkungen von Spectre verringert, auch ohne BIOS Update. Vielleicht geschieht auch noch ein Wunder und MS verteilt die Microcode-Updates über den Windows-Updater.
Hoffen wirs ansonsten bricht eine neue Ära an. Nicht auszumalen was hier auf viele zu kommt, welche keinen Schutz haben.

[unl34shed]

Ja aber dann wäre Microsoft ja der Böse, da die Patches sicher Performance kosten werden. Das versteht der DAU doch nicht...

[Fusion_Power]

Ich mache mir momentan ehr Sorgen dass ich so rein noch gar nix über Pläne für zukünftige Chips ohne diese Lücken gehört hab, nicht dass wir von nun an nur noch auf performance-fressende Software-frickeleien angewiesen sind. Weil man hat den Eindruck, die Hersteller wollen oder können diese Schwachstellen im Chipdesign gar nicht so einfach ändern.

[Screemer]

windows kann doch eigentlich auch microcode im bootprozess füttern. warum wird das nicht so gemacht?

[lumines]

windows kann doch eigentlich auch microcode im bootprozess füttern. warum wird das nicht so gemacht?

Wahrscheinlich will MS damit nichts zu tun haben. Man schiebt sich wahrscheinlich den schwarzen Peter hin und her. Anders kann ich mir das jedenfalls nicht erklären.

[Screemer]

die haben doch schon mehrere male microcodeupdates (https://support.microsoft.com/de-de/help/3064209/june-2015-intel-cpu-microcode-update-for-windows) für intel forciert (https://support.microsoft.com/de-de/help/936357/a-microcode-reliability-update-is-available-that-improves-the-reliabil) und bei so gravierenden lücken will man sich raus halten?!

[Birdman]

Vielleicht geschieht auch noch ein Wunder und MS verteilt die Microcode-Updates über den Windows-Updater.
Das tun sie doch bereits.
Dass sie dies grundsätzlich nicht möchten und auf BIOS-Updates/Mobo-Hersteller verweisen kann durchaus sein, bzgl. Spectre haben Sie aber bereits Microcodes verteilt.
Darum auch der Terz um den vor einigen Tagen von Microsoft wieder zurückgezogene "Patch", da dieser Haswell und Co. Systeme instabil gemacht hat.

[Bucklew]

Sammelklage gegen AMD wegen falscher Aussagen über Spectre/Meltdown:

https://overclock3d.net/news/cpu_mainboard/amd_hit_with_class_action_lawsuit_over_spectre_vulnerability/1

[Ganon]

Das tun sie doch bereits.
Dass sie dies grundsätzlich nicht möchten und auf BIOS-Updates/Mobo-Hersteller verweisen kann durchaus sein, bzgl. Spectre haben Sie aber bereits Microcodes verteilt.
Darum auch der Terz um den vor einigen Tagen von Microsoft wieder zurückgezogene "Patch", da dieser Haswell und Co. Systeme instabil gemacht hat.

Und welches Update soll das sein? KB-Nr? Ich hab nur gelesen, dass sie das für ihre aktuelle Surface Reihe rausgebracht haben, aber nicht allgemein für jeden.

edit: Meiner Meinung nach war das Boot-Problem Update im Zusammenhang mit dem Meltdown-Fix und AMD CPUs. Und das Haswell Ding, war im Zusammenhang Lenovo BIOS Update.

[Th3o]

Sammelklage gegen AMD wegen falscher Aussagen über Spectre/Meltdown:

https://overclock3d.net/news/cpu_mainboard/amd_hit_with_class_action_lawsuit_over_spectre_vulnerability/1
Da wollen sich nur ein Paar Anwaltsgeier bereichen

[Blediator16]

Sammelklage gegen AMD wegen falscher Aussagen über Spectre/Meltdown:

https://overclock3d.net/news/cpu_mainboard/amd_hit_with_class_action_lawsuit_over_spectre_vulnerability/1

Win für die Anwälte mehr auch nicht. Haben scheinbar nichts zu tun.

[Schnoesel]

The Rosen Investment Rights Law Firm has confirmed that they have filed a class action lawsuit against Advanced Micro Devices (AMD) on behalf of those who purchased stocks between February 21st, 2017 and January 11th, 2018 over the vulnerability of the company's products to Spectre.

Vor allem dieser Satz ergibt doch keinen Sinn. Dazu müste man AMD erst mal nachweisen schon vorher über die Sicherheitslücke Bescheid gewusst zu haben.

Naja is nicht mein Problem.

[eratte]

Richtig müsste es heißen:

"Sammelklage gegen AMD wegen angeblich falscher Aussagen über Spectre/Meltdown"

Bei Bucklew natürlich nicht ;)

[kruemelmonster]

Nebenbei gibt es kein BIOS-Update gegen Meltdown. Das Hardwarefeature zur Eindämmung des Performance-Hits heißt PCID und INVPCID. Das Erste gibt's seit Sandy-Bridge, das Zweite seit Haswell.

PCID gibt es seit Westmere. Keine Ahnung ob Nehalem es auch schon hatte, Clarkdale hat es definitiv nicht. Bzgl Lynnfield: schau ich heute Abend mal auf meinen X3470 rauf. hat wie Clarkdale kein PCID.

edit: Und so allgemein: Die "Empfehlung"/"Ratschlag"/"Hinweis" des Tools, dass man sich vielleicht wünscht den Meltdown-Fix aus Performance-Gründen zu deaktivieren ist einfach mal voll daneben. Bei Spectre kann man ja noch diskutieren. Aber Meltdown nicht, nein, so gar nicht.

Auch wenn ich sowohl die Seite grc.com als auch die Tools seit langem schon schätze, bzgl des Hinweises hast du absolut recht, das geht gar nicht.

[Ganon]

PCID gibt es seit Westmere.

Dort anscheinend aber nur in einigen Xeon-CPUs. Consumer CPUs haben das wohl nicht. Ein Intel Mitarbeiter hatte auch nur hier (https://patchwork.kernel.org/patch/10035481/) gesagt "PCIDs are generally available on Sandybridge and newer CPUs.".

[sapito]

interessantes interview mit Daniel Groß von der TU Graz

https://www.golem.de/news/meltdown-und-spectre-dann-sind-wir-performancemaessig-wieder-am-ende-der-90er-1801-132224.html

"Dann sind wir performancemäßig wieder am Ende der 90er"
Wir haben mit einem der Entdecker von Meltdown und Spectre gesprochen. Er erklärt, was spekulative Befehlsausführung mit Kochen zu tun hat und welche Maßnahmen Unternehmen und Privatnutzer ergreifen sollten.
Ein Interview von Hauke Gierow

[Ganon]

Skyfall und Solace sind auch schon in den Startlöchern.

https://skyfallattack.com/

Skyfall and Solace are two speculative attacks based on the work highlighted by Meltdown and Spectre.

Full details are still under embargo and will be published soon when chip manufacturers and Operating System vendors have prepared patches.

Mal gucken wer davon alles betroffen ist und wie schwerwiegend das dann ist.

[Gorkon]

Da braucht es ja bald nen YT-Kanal "Honest Vulnerabilities Trailers" wenns schon Teaser zu Sicherheitslücken gibt X-D

[Setsul]

Benennen wir Sicherheitslücken jetzt ernsthaft nach James Bond Filmen?

[Razor]

Aber danke für die Zusammenfassung.
gerne...

Nebenbei gibt es kein BIOS-Update gegen Meltdown. Das Hardwarefeature zur Eindämmung des Performance-Hits heißt PCID und INVPCID. Das Erste gibt's seit Sandy-Bridge, das Zweite seit Haswell.
Da berichtest Du mir nichts Neues, aber danke für die Details.

edit: Und so allgemein: Die "Empfehlung"/"Ratschlag"/"Hinweis" des Tools, dass man sich vielleicht wünscht den Meltdown-Fix aus Performance-Gründen zu deaktivieren ist einfach mal voll daneben. Bei Spectre kann man ja noch diskutieren. Aber Meltdown nicht, nein, so gar nicht.
Microsoft macht das mit nur einem einzigen Reg-Key möglich... DAS würde mich viel eher beunruhigen.
Dich nicht?

Ergo: man macht die Öffentlichkeit drauf aufmerksam und bringt M$ dazu, das Problem ein wenig konkreter, vor allem aber konsequenter anzugehen.
Die "Instrumentalisierung" der ganzen Problematik ist etwas, dass sich derzeit recht klar abzeichnet...

Interessant übrigens, was DELL zum T1700 Bios-Update schreibt:
Dell Precision T1700 System BIOS

This package provides the BIOS update for Dell Precision T1700 running in the following Operating Systems: Windows and DOS.
Fehlerkorrekturen und Verbesserungen
Fixes
- Update to the latest CPU microcode to address CVE-2017-5715. [<Spectre2]
- Updated Intel ME Firmware to address security advisories INTEL-SA-00086 (CVE-2017-5711 & CVE-2017-5712) & INTEL-SA-00101(CVE-2017-13077, CVE-2017-13078 & CVE-2017-13080)
Das fast ebenso große, wenn nicht größere Problem INTEL-SA-00086 wurde erst jetzt gepatcht...

Razor

[crux2005]

Ich finde es übrigens immer wieder lustig wie Leute vor Meltdown und Spectre in akute Panik verfallen, aber sorglos irgendwelche (Closed-Source) Prüf-Tools von Dritten aus dem Netz laden und einfach ausführen :ugly:

Wenn ich kriminell wäre, wäre so ein Prüftool jetzt eine 1a Gelegenheit irgendwelchen Leuten einen Trojaner unterzujubeln.

Machen sie auch. :(
http://www.pcgamer.com/watch-out-for-phishing-emails-linking-to-fake-meltdown-and-spectre-patches/

[Gorkon]

Skyfall und Solace sind auch schon in den Startlöchern.

https://skyfallattack.com/



Mal gucken wer davon alles betroffen ist und wie schwerwiegend das dann ist.
*Könnte* auch ein Hoax sein...

https://twitter.com/TheRegister/status/954065341713235973?ref_src=twsrc%5Etfw

[Ganon]

*Könnte* auch ein Hoax sein...

Wäre natürlich schön. Ist gerade schon genug Arbeit :D

[deekey777]

http://winfuture.de/news,101555.html

Damit meldet der Ashampoo-Checker, dass mein Tablet (endlich) gegen Meltdown geschützt ist. :uup:

[pnume]

Wenn Meltdown und Spectre CPU Leitung kosten, ists da nicht eine gute Chance für DX12?

Nur mal so ein kurzer Gedanke.

[StefanV]

Wenn Meltdown und Spectre CPU Leitung kosten, ists da nicht eine gute Chance für DX12?

Nur mal so ein kurzer Gedanke.
Nein, weil es nur System Aufrufe betrifft.


Sprich wenn das Spiel z.B. auf das Dateisystem zugreifen muss, bricht die Leistung zusammen.

[Marodeur]

Benennen wir Sicherheitslücken jetzt ernsthaft nach James Bond Filmen?

Scheint so.

[DrumDub]

http://winfuture.de/news,101555.html

Damit meldet der Ashampoo-Checker, dass mein Tablet (endlich) gegen Meltdown geschützt ist. :uup: toll. das tool tuts bei mir nicht.

[Razor]

Nimm das gestern in den News verlinkte InSpectre:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-19-januar-2018

Gut, dass in diesem Fall die Meinung der "Moderation" und der Site-Betreiber auseinander gehen.
Allerdings muss man auch diesen attestieren, die "full details below" NICHT gelesen zu haben...

"SLOWER" wird nur dann ausgewiesen, wenn der Meltdown-Fix ohne CPU-Unterstützung läuft... was bei allen OS Versionen unterhalb von Win10 der Fall ist.
Die (vollständige) Hardware-Unterstützung gibt es übrigens seit Haswell, nicht erst seit Skylake und wird unter Win10 vollkommen korrekt vom Tool ausgewiesen.

Razor

P.S.: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11607643#post11607643

[Poook]

Hatte das schon im Oneplus thread angesprochen, aber da scheint es unterzugehen.

Wie bekommt man nicht mehr supportete aber betroffene Android Smartphones auf einen "sicheren" Zustand. In meinem Fall ein Oneplus Two (Snapdragon 810 entspricht ARM57).

[exzentrik]

Hatte das schon im Oneplus thread angesprochen, aber da scheint es unterzugehen.

Wie bekommt man nicht mehr supportete aber betroffene Android Smartphones auf einen "sicheren" Zustand. In meinem Fall ein Oneplus Two (Snapdragon 810 entspricht ARM57).

Lineage OS (https://download.lineageos.org/oneplus2) würde sich da anbieten. Das hat aber unter Umständen diverse Kinderkrankheiten und nicht die vollständige Sicherheitsstufe eines offiziell gepflegten Android. Aber bevor man ein Mobilgerät, das zuletzt vor 6 Monaten bis gar ein paar Jahren Sicherheits-Patches gesehen hat (und damit eigentlich als sicherheitstechnischer Sondermüll betrachtet werden muss), weiternutzt, kann man besser Lineage OS ausprobieren.

[vanquish]

Ich bezweifle, dass diese alten Geräte jemals ein Update erhalten. Wenn es kein passendes ROM von LineageOS gibt, sieht es schlecht aus. Bei Samsung ist mit dem S6 Schluss. Das S5 und S4 bleibt außen vor. Die alten 3.xx Kernel und die dazu gehörenden Treiber wird niemand mehr anpassen. Es wird sich alles an den fünf Jahren von Intel orientieren.

[lumines]

Die alten 3.xx Kernel und die dazu gehörenden Treiber wird niemand mehr anpassen.

Das wird wahrscheinlich das größte Problem sein. Die ganzen Custom ROMs profitieren ja immer von der Upstream-Entwicklung, aber für manche Sachen wird es erst ab Linux 4.14 Patches geben. Das heißt irgendwer bei LOS müsste die ganzen alten Kernel nehmen und die Patches aus neueren Linux-Versionen an die alten Versionen anpassen, was eventuell nicht so einfach möglich ist.

Das sind keine Änderungen, die man Mal eben blind mergt. Deshalb wäre ich auch sehr vorsichtig einfach blind Custom ROMs als Lösung dafür zu empfehlen. Viele Geräte werden die relevanten Patches nie sehen. Auch nicht mit Custom ROMs.

[Poook]

Lineage OS (https://download.lineageos.org/oneplus2) würde sich da anbieten. Das hat aber unter Umständen diverse Kinderkrankheiten und nicht die vollständige Sicherheitsstufe eines offiziell gepflegten Android. Aber bevor man ein Mobilgerät, das zuletzt vor 6 Monaten bis gar ein paar Jahren Sicherheits-Patches gesehen hat (und damit eigentlich als sicherheitstechnischer Sondermüll betrachtet werden muss), weiternutzt, kann man besser Lineage OS ausprobieren.

Sind drei Monate, macht es aber nicht besser..

Wäre halt schade, weil es macht immer noch seinen Job leistunsmässig.

[Annator]

Hatte das schon im Oneplus thread angesprochen, aber da scheint es unterzugehen.

Wie bekommt man nicht mehr supportete aber betroffene Android Smartphones auf einen "sicheren" Zustand. In meinem Fall ein Oneplus Two (Snapdragon 810 entspricht ARM57).

Vielleicht sollte man das direkt mal dem Hersteller fragen. Wäre gut wenn die mal druck von ihrer Kundschaft bekommen.

[Dino-Fossil]

Linus being Linus im Bezug auf einige der Linux Kernel Patches: :biggrin:

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html (http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html)

[Ganon]

Vielleicht sollte man das direkt mal dem Hersteller fragen. Wäre gut wenn die mal druck von ihrer Kundschaft bekommen.

Ja, wie lumines schon sagte sind Custom ROMs hier keine Lösung und doof gesagt: Vermutlich kann der Hersteller des Gerätes auch nicht viel machen. Denn der Hersteller des Geräts bezieht seine grundlegende Android-Version auch nur vom SoC-Hersteller und auch der hört irgendwann auf bestimmte SoCs zu patchen.

Da ARM leider keine "Standard Plattform", sondern jeder SoC mehr oder weniger für sich ein eigenes, neues System ist, ist die Zulieferer-Kette hier ziemlich lang.

Linus being Linus im Bezug auf einige der Linux Kernel Patches: :biggrin:

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html (http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html)

Wobei es hier mehr um mögliche Absichten von Intel geht das Problem (Spectre V2) nicht in Hardware zu fixen, sondern es bei den IBRS Patches dauerhaft belässt und "nur" IBRS allgemein etwas optimiert. Quasi ein dauerhafter Workaround und das stößt bei ihm natürlich sauer auf.

[Dino-Fossil]

Wobei es hier mehr um mögliche Absichten von Intel geht das Problem (Spectre V2) nicht in Hardware zu fixen, sondern es bei den IBRS Patches dauerhaft belässt und "nur" IBRS allgemein etwas optimiert. Quasi ein dauerhafter Workaround und das stößt bei ihm natürlich sauer auf.

Jo, sicherlich auch zurecht. Er hat halt seine übliche, sehr direkte Art das auszudücken.

[Poook]

Vielleicht sollte man das direkt mal dem Hersteller fragen. Wäre gut wenn die mal druck von ihrer Kundschaft bekommen.

Gefragt und ignoriert.

[Ganon]

Hmm, entgegengesetzt aller sonstigen Meinungen im Internet, scheinen IBM POWER Systeme doch von Meltdown betroffen zu sein, wenn wohl auch auf eine andere Art und Weise. Etwas schwieriger zu benutzen, da es prinzipiell einen Permission-Check gibt, der aber ggf. zu spät greift:

https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=aa8a5e0062ac940f7659394f4817c948dc8c0667

On some CPUs we can prevent the Meltdown vulnerability by flushing the
L1-D cache on exit from kernel to user mode, and from hypervisor to
guest.

This is known to be the case on at least Power7, Power8 and Power9. At
this time we do not know the status of the vulnerability on other CPUs
such as the 970 (Apple G5), pasemi CPUs (AmigaOne X1000) or Freescale
CPUs. As more information comes to light we can enable this, or other
mechanisms on those CPUs.

The vulnerability occurs when the load of an architecturally
inaccessible memory region (eg. userspace load of kernel memory) is
speculatively executed to the point where its result can influence the
address of a subsequent speculatively executed load.

In order for that to happen, the first load must hit in the L1,
because before the load is sent to the L2 the permission check is
performed. Therefore if no kernel addresses hit in the L1 the
vulnerability can not occur. We can ensure that is the case by
flushing the L1 whenever we return to userspace. Similarly for
hypervisor vs guest.

In order to flush the L1-D cache on exit, we add a section of nops at
each (h)rfi location that returns to a lower privileged context, and
patch that with some sequence. Newer firmwares are able to advertise
to us that there is a special nop instruction that flushes the L1-D.
If we do not see that advertised, we fall back to doing a displacement
flush in software.

For guest kernels we support migration between some CPU versions, and
different CPUs may use different flush instructions. So that we are
prepared to migrate to a machine with a different flush instruction
activated, we may have to patch more than one flush instruction at
boot if the hypervisor tells us to.

In the end this patch is mostly the work of Nicholas Piggin and
Michael Ellerman. However a cast of thousands contributed to analysis
of the issue, earlier versions of the patch, back ports testing etc.
Many thanks to all of them.

[Gipsel]

Da wäre es bald interessant zu wissen, was im Schnitt schneller ist: Das Flushen des L1 oder das Unmappen des Kernelspeichers beim Wechsel ins Userland. So richtig performant hört sich das mit dem L1-Flush nämlich auch nicht an, insbesondere wenn man viele kleine Syscalls hat.

[Lord Wotan]

Linus Torvalds nennt die Fixes von Intel "pure garbage"

Auf seinem Block nennt der Linux Schöpfer Linus Torvalds die Fixes von Intel bezüglich Spectre und Meltdown "pure garbage".

"From Linus Torvalds <>
Date Sun, 21 Jan 2018 13:35:59 -0800
Subject Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation
share 0
share 937
On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
>> All of this is pure garbage.
>>
>> Is Intel really planning on making this shit architectural? Has
>> anybody talked to them and told them they are f*cking insane?
>>
>> Please, any Intel engineers here - talk to your managers.
>
> If the alternative was a two-decade product recall and giving everyone
> free CPUs, I'm not sure it was entirely insane.

You seem to have bought into the cool-aid. Please add a healthy dose
of critical thinking. Because this isn't the kind of cool-aid that
makes for a fun trip with pretty pictures. This is the kind that melts
your brain.

> Certainly it's a nasty hack, but hey — the world was on fire and in the
> end we didn't have to just turn the datacentres off and go back to goat
> farming, so it's not all bad.

It's not that it's a nasty hack. It's much worse than that.

> As a hack for existing CPUs, it's just about tolerable — as long as it
> can die entirely by the next generation.

That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.

So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.

Honestly, that's completely unacceptable too.

> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit — just "you don't have to worry any more, it got better".

It's not "weird" at all. It's very much part of the whole "this is
complete garbage" issue.

The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".

So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint.

I'm sure there is some lawyer there who says "we'll have to go through
motions to protect against a lawsuit". But legal reasons do not make
for good technology, or good patches that I should apply.

> We do need the IBPB feature to complete the protection that retpoline
> gives us — it's that or rebuild all of userspace with retpoline.

BULLSHIT.

Have you _looked_ at the patches you are talking about? You should
have - several of them bear your name.

The patches do things like add the garbage MSR writes to the kernel
entry/exit points. That's insane. That says "we're trying to protect
the kernel". We already have retpoline there, with less overhead.

So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.

If this was about flushing the BTB at actual context switches between
different users, I'd believe you. But that's not at all what the
patches do.

As it is, the patches are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.

WHAT THE F*CK IS GOING ON?

And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons.

It's mis-designed for two major reasons:

- the "the interface implies Intel will never fix it" reason.

See the difference between IBRS_ALL and RDCL_NO. One implies Intel
will fix something. The other does not.

Do you really think that is acceptable?

- the "there is no performance indicator".

The whole point of having cpuid and flags from the
microarchitecture is that we can use those to make decisions.

But since we alread

[exzentrik]

Das wird wahrscheinlich das größte Problem sein. Die ganzen Custom ROMs profitieren ja immer von der Upstream-Entwicklung, aber für manche Sachen wird es erst ab Linux 4.14 Patches geben. Das heißt irgendwer bei LOS müsste die ganzen alten Kernel nehmen und die Patches aus neueren Linux-Versionen an die alten Versionen anpassen, was eventuell nicht so einfach möglich ist.

Das sind keine Änderungen, die man Mal eben blind mergt. Deshalb wäre ich auch sehr vorsichtig einfach blind Custom ROMs als Lösung dafür zu empfehlen. Viele Geräte werden die relevanten Patches nie sehen. Auch nicht mit Custom ROMs.

Dieser Umstand könnte sich ja mit Project Treble zum Positiven ändern. Mal abwarten. Ich lege aber Wert drauf, dass ich nicht einfach unkritisch jemanden ein Custom ROM empfehle, sondern nahelege, es mal zu evaluieren. Das geringere Übel ist es ohne Frage, Lineage OS zu nutzen, statt ein schon seit Monaten oder Jahren nicht mehr aktualisiertes offizielles Android. Vor allem, wenn man sich kein neues Gerät mit aktivem Support leisten kann oder will.

Ob das eigene Gerät von Lineage wie gewünscht abgedeckt wird (auch was Spectre und Co angeht), muss derjenige dann natürlich selbst recherchieren. So viel Eigeninitative darf man in einem IT-Forum erwarten.

[lumines]

Dieser Umstand könnte sich ja mit Project Treble zum Positiven ändern. Mal abwarten.

Treble spielt sich über dem Kernel ab.

Ob das eigene Gerät von Lineage wie gewünscht abgedeckt wird (auch was Spectre und Co angeht), muss derjenige dann natürlich selbst recherchieren. So viel Eigeninitative darf man in einem IT-Forum erwarten.

Die jeweiligen Commits zu durchwühlen ist in einem IT-Forum auch nicht wirklich üblich. Das mache ich vielleicht bei einigen Projekten, die mich wirklich interessieren, aber es ist schon mit ein bisschen Aufwand verbunden und auch gerade dann, wenn man Patches zwischen Geräten vergleichen will. Bei ARM-SoCs ist die Entwicklung ja teilweise schon sehr stark fragmentiert. Nicht alle benutzen den gleichen Kernel und die Patches werden ziemlich sicher je nach CPU und Kernel ein bisschen unterschiedlich sein.

[BBig]

Was für ein riesen Fiasko, vor allem, wenn man sich überlegt:
Nach 6 Monaten tröpfeln inkomplette Software-Updates langsam ein, Kernel-Updates sind nicht fertig, gar getestet und BIOS-Updates sind nicht nur nicht bereit, sondern legen PCs lahm:

Meltdown und Spectre: Intel zieht Microcode-Updates für Prozessoren zurück @ heise.de (https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Intel-zieht-Microcode-Updates-fuer-Prozessoren-zurueck-3948447.html)
Die Probleme reißen nicht ab: Intel rät davon ab, die zuvor bereitgestellten CPU-Microcode-Updates einzuspielen, die zum Schließen der Sicherheitslücke Spectre Variante 2 (Branch Target Injection, BTI, CVE-2017-5715) nötig sind. Einige PC-Hersteller haben zuvor bereitgestellte BIOS-Updates mit diesem Microcode-Updates wieder von ihren Webseiten genommen. Auch einige Linux-Distríbutionen ziehen Microcode-Updates zurück.



Z.B. USN-3531-2: Intel Microcode regression (https://usn.ubuntu.com/usn/usn-3531-2/)
USN-3531-1 updated Intel microcode to the 20180108 release. Regressions
were discovered in the microcode updates which could cause system
instability on certain hardware platforms. At the request of Intel, we have
reverted to the previous packaged microcode version, the 20170707 release.


== // ==

Wie stellt sich Intel das eigentlich vor? Den LKML-Eintrag von Linus (http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html) hatten wir ja schon, und ich sehe das genauso.

Intel hatte 6 Monate Zeit es zu fixen; ist aber nicht passiert. Wollen oder können sie es nicht fixen?
Was heute alles digital läuft und Intel-Hardware und IP ist in ~90% aller PCs. Sollen die alle "unsicher" im Netz sein? Keine Ahnung, wie Intel sich das vorstellt.

Vll ist wirklich Zeit für Is it time for open processors? @ lwn.net (https://lwn.net/Articles/743602/)

[Poook]

Wenn es nur 6 Monate wären. Wenn man sich die Berichte so durchliest klingt es eher so als wüsste Intel davon seit 2,5 Jahren. Die "Entdecker" haben das ja auch nur entdeckt weil Intel denen verdächtige Fragen gestellt hat.

[Loeschzwerg]

Vll ist wirklich Zeit für Is it time for open processors? @ lwn.net (https://lwn.net/Articles/743602/)

Nur wenn schnell und auch die Entwicklung zügig voran geht. Zudem muss die Infrastruktur passen (z.B. Grafikkarten + Treiber) und über eine x86/x64 Emulation würde ich auch nicht meckern ^^

[Ätznatron]

Wenn es nur 6 Monate wären. Wenn man sich die Berichte so durchliest klingt es eher so als wüsste Intel davon seit 2,5 Jahren. Die "Entdecker" haben das ja auch nur entdeckt weil Intel denen verdächtige Fragen gestellt hat.

Erst seit 2,5 Jahren?

Intel weiss seit Anbeginn davon, es sind keine Laien dort tätig, die aus reinem Dilettantismus ein Scheunentor derartigen Ausmasses implementiert haben, welches besonders für Geheimdienste so wunderbar vorteilhaft war/ist.

Sie sind jetzt erst aufgeflogen.

[Lord Wotan]

Intel kann man nur noch als Kunden verarscher bezeichnen. https://windowsunited.de/2018/01/23/peinlich-intel-raet-nutzern-von-meltdown-und-spectre-patches-ab/

[Armaq]

Es wird noch krasser. Der Performance Impact von wirklichen Fixes und nicht von diesen Nebelkerzen ist wohl noch viel krasser als bisher veröffentlicht. Jeder der Rechenleistung verkauft und das auf Basis von Intel CPUs macht, hat jetzt ein richtiges Problem.

[Dorn]

Es wird noch krasser. Der Performance Impact von wirklichen Fixes und nicht von diesen Nebelkerzen ist wohl noch viel krasser als bisher veröffentlicht. Jeder der Rechenleistung verkauft und das auf Basis von Intel CPUs macht, hat jetzt ein richtiges Problem.
Um spectre zu 100% zu fixen müsste die Sprungvorhersage ausgeschaltet werden.

[Ganon]

Nicht unbedingt die Sprungvorhersage. Mehr die "Speculative Execution", d.h. das Ausführen von Code, der noch gar nicht zur Ausführung dran ist. z.B. die Raspberry Pi CPU macht auch Sprungvorhersage, lädt aber im nachfolgenden Schritt nur die noch kommenden Instruktionen. Ausgeführt werden diese aber nicht und somit wird nicht Speicher von irgendwo im Vorfeld gelesen.

[Dorn]

Was aber auch ein krasser einschnitt auf die performance hat. Wenn das auch bei Intel bzw. Ähnlichen CPUs gut möglich wäre?

[Ganon]

Was aber auch ein krasser einschnitt auf die performance hat. Wenn das auch bei Intel bzw. Ähnlichen CPUs gut möglich wäre?

Klar wäre das ein krasser Einschnitt in die Performance. Aber 100%ige Sicherheit ist hier auch gar nicht notwendig. AMD zeigt ja, dass man Variant 2 auch prima in Hardware "near zero risk" fixen kann und mit etwas Software-Hilfe dann auch zu "zero risk". Und andere CPUs kriegen halt Software-Fixes für Variant 2 und 3.

Und Variant 1 wird halt "einfach" in Software "gefixt", kostet dann natürlich auf allen CPUs, egal welcher Hersteller, etwas Leistung. Aber die Leistung ist immer noch weit über den immunen CPUs.

Man muss aber nicht dauernd annehmen, dass von nun an alle aktuellen CPUs nur noch Leistungen eines Taschenrechners liefern.

edit: Anders ausgedrückt: Syscalls werden jetzt wieder teurer. Das muss aber nicht heißen, dass man jetzt Userspace-Code deswegen unbedingt torpedieren muss, indem man einfach alles abschaltet. Stattdessen sollte man in der Software sich wieder Gedanken um Syscall-Optimierung machen. Das hilft dann auch nicht-betroffenen CPUs.

[Armaq]

Wenn ich Performance brauche und Sicherheit nicht links liegen lassen kann, dann werden diese Fixes extrem teuer.

[Ganon]

Wenn ich Performance brauche und Sicherheit nicht links liegen lassen kann, dann werden diese Fixes extrem teuer.

Darum geht's gerade gar nicht. Es geht um den Einsatz "immuner" CPUs als Alternative.

[Ganon]

So als Randbemerkung für Linux-Nutzer: Wem die Performance-Einschnitte hart treffen, der kann ja überlegen auf Intels Clear Linux Distribution umzusteigen. Hier ist die Performance in den geliebten Microbenchmarks nach KPTI immer noch stellenweise weit über der Performance in anderen Distributionen ohne KPTI: https://www.phoronix.com/scan.php?page=article&item=5distros-post-spectre&num=1

Clear Linux liefert halt, anders als andere Distributionen, keine "generic x86-64" Binaries aus, sondern hat durch bestimmte Compiler-Tricks (Function Multi-Versioning) generell Code für viele CPU-Konfigurationen da z.B. SSE4, AVX, AVX2 und AVX512. Wird dann halt zur Laufzeit das benutzt was die CPU kann.

[Gipsel]

Um spectre zu 100% zu fixen müsste die Sprungvorhersage ausgeschaltet werden.Für Spectre v2 nicht unbedingt. Hier würde es bereits extrem helfen, wenn Sprünge nicht mehr fehlidentifiziert werden können (man also die Sprungvorhersage nicht mit an anderer Adresse liegendem Code fehltrainiert werden kann). Dann wird das Indizieren in den BTB etwas teurer (Transistoren + Stromverbrauch) und man muß eine Handvoll mehr Bits vergleichen (nicht mehr nur 12 oder so wie intel das momentan macht, sondern am besten alle 48 Bits der physischen Adresse [oder wie groß der physische Adressraum gerade ist] oder wenn man virtuelle Adressen benutzt, dann eben die komplette virtuelle Adresse + Prozeß-ID). Der Grund, warum AMD weniger anfällig für Spectre v2 ist, soll ja gerade sein, daß sie die komplette Adresse zum Indizieren des BTBs benutzen (angeblich komplette virtuelle Adresse aber ohne Prozeß-ID, deswegen nicht 100% theoretisch sicher, aber eben deutlich schwerer zu nutzen). Die Nutzung von PCIDs (process context identifier) erfordert übrigens ebenfalls OS-Updates (mit alten OS-Versionen geht es also nicht), denn irgendwer muß die ja setzen, um die verschiedene Prozesse auseinanderzuhalten.

Und für Spectre v1 müßte man halt bei sicherheitsrelevantem Kram (Browser/Sandboxes) für jeden Bounds-Check die Spekulation gezielt kurz mal ausknipsen können.

[Ganon]

Hier in einer langen Mail die Details, was die 3 neuen Befehle in Intels Microcode so tun und was das Problem von Skylake+ eigentlich ist:

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html

Ich zitiere das hier mal nicht, weil so lang.

[x-force]

so langsam sehe ich den staat in der pflicht intel zu enteignen und alle patente frei verfügbar zu machen, so daß der weg für schnelle sichere prozessoren frei wird.

[Sven77]

Hm, also wieder altes Bios drauf?

[lumines]

so langsam sehe ich den staat in der pflicht intel zu enteignen und alle patente frei verfügbar zu machen, so daß der weg für schnelle sichere prozessoren frei wird.

Oder einfach RISC-V fördern.

[Ganon]

Oder einfach RISC-V fördern.

Ist natürlich immer eine gute Idee offene Projekte zu fördern, aber sobald man hier eine halbwegs performante CPU bauen will, kriegt man eben auch wieder mindestens eines der Probleme rein.

Anders als ARM ist RISC-V ist ja auch nur eine ISA und kein Prozessor-Modell, soweit ich weiß. Man braucht also schon noch irgendwo mehr als nur die ISA an sich. Irgendwer muss den Kram dann ja auch wieder bauen.

Und man sieht ja an Meltdown so schön, dass man komplett ISA unabhängig ein Problem in eine CPU bauen kann. Intel, ARM/Qualcom, Apple und IBM haben es geschafft :D Bei Spectre Variant 2 haben es ja wohl auch so ziemlich alle verkackt bis auf AMD.

[Lord Wotan]

https://www.computerbase.de/2018-01/linus-torvalds-intel-spectre-patch-garbage/


Bleibt ja nur AMD

[vanquish]

RISC-V gut und schön. Am Ende muss es aber auch jemand kaufen. AMD kam unter die "Räder", da sie in ihrer Hochzeit weniger verkauften als sie verkaufen hätten müssen um mit Intel Schritt halten zu können. Apple hat zusammen mit IBM den PowerPC (der wenn ich mich recht erinnere irgendwann einmal RISC als Grundlage hatte) zu Grabe getragen. Intel hatte hat seit 2005 praktisch gar keine Konkurrenz mehr. Selbst mit Ryzen erhohlt sich AMD nur langsam und ich zweifle daran, dass AMD zu einem ernst zunehmenden Konkurrenten aufsteigen wird und entwicklungstechnische Akzente setzen kann. Will man jetzt noch RISC-V (mit staatlichen Mitteln; andere Optionen sehe ich da eher nicht) pushen ist das nichts weiter als Geld verbrennen. Der Kunde entscheidet am Ende mit seiner Nachfrage. Jetzt hat er ja wieder eine Wahl. ;)

[kruemelmonster]

Hier in einer langen Mail die Details, was die 3 neuen Befehle in Intels Microcode so tun und was das Problem von Skylake+ eigentlich ist:

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html

Ich zitiere das hier mal nicht, weil so lang.

Danke für den Link.

[gravitationsfeld]

so langsam sehe ich den staat in der pflicht intel zu enteignen und alle patente frei verfügbar zu machen, so daß der weg für schnelle sichere prozessoren frei wird.
:facepalm:

[Sven77]

;D sowas hätts unterm Erisch nisch gegebe

[StefanV]

Welche x86 Patente hält denn Intel, die noch wichtig sind?
Die Originalen sind abgelaufen.
AMD64 ist nicht Intel.

Bleibt nur SSE und AVX...

Aber X-Force hat schon nicht Unrecht, dass Patente nicht zum Ausschluss von Wettbewerb genutzt werden sollten...
Am besten das ganze deutlich entschlacken oder abschaffen, weil sie dem Fortschritt im Weg stehen. Aber das ist ja gerad nicht soo das THema...

PS: 2 Jahre fürn Patent wäre OK, maximal 5...

[Loeschzwerg]

Gibt doch AMD und sogar Zhaoxin (VIA)... passt doch.

[sun-man]

Selbst mit Ryzen erhohlt sich AMD nur langsam und ich zweifle daran, dass AMD zu einem ernst zunehmenden Konkurrenten aufsteigen wird und entwicklungstechnische Akzente setzen kann.
Meiner Meinung nach entscheidet das die Nachfrage bei den Systemhäusern. Was dieser Mist gerade an Unruhe in den IT Abteilungen verursacht ist nicht wirklich schön. Hier müssen hunderte ESX Cluster gepatcht werden. Wenn der Kunde hier jetzt sagt "OK FA XY. Wie schaut es aus mit AMD Systemen. Was könnt Ihr uns anbieten" dann ist das eben so. Der Homeuser muss, IMHO, da kaum am Rad drehen. Dummerweise scheinen die Patche es aber auch für den Homeuser schlimm zu machen.

Sparc gibts ja auch noch. Dummerweise hat Oracle SUN so klein gemacht das sie kaum noch was zu sagen haben. Hier gibts zwar einige >=M7 Systeme, aber das Ende ist trotzdem Nahe.

[Poook]

PS: 2 Jahre fürn Patent wäre OK, maximal 5...

Das sollte immer vom Patent, bzw. dem Aufwand und der Konkurrenzsituation abhängen. 5Jahre sind bei Softwarepatenten viel zu lang. Bei neuen Medikamenten, also nicht ein altes plus Vitamin C oder ein gedrehtes Molekül, kann man froh sein nach zehn Jahren eine FDA Genehmigung zu bekommen.

[vanquish]

Meiner Meinung nach entscheidet das die Nachfrage bei den Systemhäusern. Was dieser Mist gerade an Unruhe in den IT Abteilungen verursacht ist nicht wirklich schön. Hier müssen hunderte ESX Cluster gepatcht werden. Wenn der Kunde hier jetzt sagt "OK FA XY. Wie schaut es aus mit AMD Systemen. Was könnt Ihr uns anbieten" dann ist das eben so. Der Homeuser muss, IMHO, da kaum am Rad drehen. Dummerweise scheinen die Patche es aber auch für den Homeuser schlimm zu machen.

Sparc gibts ja auch noch. Dummerweise hat Oracle SUN so klein gemacht das sie kaum noch was zu sagen haben. Hier gibts zwar einige >=M7 Systeme, aber das Ende ist trotzdem Nahe.
Mit dem Nachfrager/Kunden waren schon alle am Markt beteiligten gemeint. Die großen Systemhäusern HP, DELL, Lenovo, Apple, etc. bauen sowohl für Consumer als auch für Business-Kunden. Der Market-Share ist recht ausgewogen:

Q1 2017: (http://www.thehindubusinessline.com/multimedia/dynamic/03200/bl20_PC_desktop_sh_3200058f.jpg)

Com Desktop 28,2%
Com Notebook 22%
Cons Desktop 10%
Cons Notebook 38.4%

Das heißt, dass der MediaMarkt/Aldi-Kunde sehr wohl einen erheblichen Einfluss auf das hat was die o. g. Unternehmen produzieren. Letztendlich ist es für einen Büro-PC heutzutage nicht mehr von Bedeutung ob Intel oder AMD. Alle sind schnell genug. Es ist eine von der IT dem eigenen "Geschmack" angepasste getroffene Entscheidung. Server sind, im Vergleich zu PCs die überall stehen, nur eine "Randerscheinung", mit denen sich viel Geld verdienen lässt. Aber dieses Segment entscheidet nicht über die Marktmacht von Intel auf dem "normalen" PC-Markt. Für den Normal-Privat/Büro-Anwender sollte es keine Rolle spielen ob Intel oder AMD.

Der größte Konkurrent für Intel ist derzeit der Smartphone/IoT-CPU Markt. Aber ich habe von ARM noch nicht gehört, dass Sie jetzt auch Desktop CPUs entwicklen wollen.

[lumines]

Aber ich habe von ARM noch nicht gehört, dass Sie jetzt auch Desktop CPUs entwicklen wollen.

Machen sie ja indirekt mit ihren High-End-Kernen. Ob die dann jemand in Silizium für PCs gießt, ist natürlich eine andere Frage.

Anders als ARM ist RISC-V ist ja auch nur eine ISA und kein Prozessor-Modell, soweit ich weiß. Man braucht also schon noch irgendwo mehr als nur die ISA an sich. Irgendwer muss den Kram dann ja auch wieder bauen.

Und man sieht ja an Meltdown so schön, dass man komplett ISA unabhängig ein Problem in eine CPU bauen kann. Intel, ARM/Qualcom, Apple und IBM haben es geschafft :D Bei Spectre Variant 2 haben es ja wohl auch so ziemlich alle verkackt bis auf AMD.

Mit RISC-V könnte man allerdings von Anfang an gewisse Probleme schon versuchen zu umgehen.

[vanquish]

Ah OK. Ich war der Meinung, dass es diesbezüglich einmal eine Ankündigung gab. Sicher war ich mir allerdings nicht. Vor allem ob das Projekt noch lebt.

Es wäre wünschenswert wenn sich da einmal etwas tun würde. Aber da müsste erst einmal eine dieser Milliardäre viel Geld in die Hand nehmen und Intel Paroli bieten wollen. Ich bin da skeptisch. Ich denke, dass sich erst wieder etwas tut, wenn Intel entwicklungstechnisch am Ende ist (also so bei 5nm). Dann könnten die Karten tatsächlich neu gemischt werden. Was noch ein "paar" Jahre dauern wird.

[Poook]

Ah OK. Ich war der Meinung, dass es diesbezüglich einmal eine Ankündigung gab. Sicher war ich mir allerdings nicht. Vor allem ob das Projekt noch lebt.

Es wäre wünschenswert wenn sich da einmal etwas tun würde. Aber da müsste erst einmal eine dieser Milliardäre viel Geld in die Hand nehmen und Intel Paroli bieten wollen. Ich bin da skeptisch. Ich denke, dass sich erst wieder etwas tut, wenn Intel entwicklungstechnisch am Ende ist (also so bei 5nm). Dann könnten die Karten tatsächlich neu gemischt werden. Was noch ein "paar" Jahre dauern wird.

Könnte aus China kommen.

https://m.heise.de/newsticker/meldung/Ohne-Meltdown-Luecke-Chinesische-x86-Prozessoren-KX-5000-vorgestellt-Angriff-auf-AMDs-ZEN-2-mit-KX-3948635.html

[Gorkon]

https://www.computerbase.de/2018-01/sard-verbinnen-intel-spectre-meltdown/

Kein Kommentar :ulol:

[LadyWhirlwind]

https://www.computerbase.de/2018-01/sard-verbinnen-intel-spectre-meltdown/

Kein Kommentar :ulol:

Wundert das wen? Öffentlich können die ja nicht zugeben dasss die CPU's fehlerhaft sind, weil dann Garantie und Gewährleistungsrechte greiffen. Tatsächlich könnte es sogar ein Problem sein, wenn sie sich so verhalten als ob die CPUs fehlerhaft sind, ohne es zuzugeben.

Aber um Reaktionen kommen Sie nicht herum. Sie müssen also die Kunden beruhigen, gleichzeitig aber auch die Linie verteidigen das ihre CPUs keine Mängel aufweisen.

[Razor]

Momentan ist jeder Schritt falsch, den Intel machen könnte... und die ganze Welt schaut zu.
Ergo: professionelle Hilfe suchen, um die nächsten Schritte genau zu planen.

Letztlich könnte dies das Aus für eines der 50 größten Unternehmen der Welt bedeuten.
Noch ist der Aktienkurs im Lot, was sich aber sehr schnell ändern könnte.

Razor

[Ganon]

"Das Aus" ist schon arg übertrieben ;)

Intels PR war halt jetzt eben nicht die Beste in letzter Zeit und dazu noch der Microcode Rückruf. Vermutlich ist der Microcode Rückruf gerade das Größere von beiden Problemen, da man nun die Server alle noch mal patchen und rebooten muss. Und natürlich eben der Aufwand der Hersteller, die besonders früh reagiert und nun natürlich damit direkt die Arsch-Karte gezogen haben. Da werden vermutlich gerade nicht wenig Leute Schadensersatz fordern, rein aufgrund des Microcode-Update-Updates.

Die Debatte rund um die Sache, ob Meltdown nun ein Fehler im Sinne eines Defekts ist, ist da vermutlich eher zweitrangig. Das wird am Ende einer ganzen Reihe von Richtern irgend ein Richter endgültig entscheiden und dann hat man dabei noch Apple mit im Boot. Die würden vermutlich auch nicht gerne hören wollen, dass ihre iPhones per-Definition nun kaputt waren und sind.

[StefanV]

Letztlich könnte dies das Aus für eines der 50 größten Unternehmen der Welt bedeuten
LOL, nein.
Solang die Hardcore Intel Fans hinter dem Unternehmen stehen und den Mist verteidigen, wird sich da nicht viel ändern.


Nur im Server/Workstation Markt schaut es momentan etwas blöder aus...
Aber das ist auch ein eher träger Markt, bei dem auch der eine oder andere Intel Advokat zu finden ist...

Aber im Consumer Markt schaut es momentan fantastisch für Intel aus.

[gravitationsfeld]

Oh Gott Stefan. Als ob irgendwelche "Hardcore Intel Fans" irgend etwas mit dem Erfolg des Unternehmens zu tun haetten.

Der Laden laeuft weil Amazon, Google, Dell und Apple die Chips kaufen, nicht wegen Stefan Mueller mit Bling-Bling-Gaming-Hardware.

Wo es weh tun koennte ist im Cloud-Bereich, falls dort wirklich vermehrt auch Alternativen (sprich AMD) eingesetzt werden.

[x-force]

:facepalm:
tut mir leid, wenn du keinen wirtschaftswissentschaftlichen hintergrund wie ich hast :comfort:

wenn du nett fragst, erklär ich dir vllt warum das sinnvoll wäre.

[BBig]

Bootfehler nach Windows-Update auch bei neuen Systemen (http://www.planet3dnow.de/cms/36216-bootfehler-nach-windows-update-auch-bei-neuen-systemen/)
@ planet3dnow.de

Wer das Treiben in den letzten Wochen seit Bekanntwerden der Sicherheitslücken in modernen Prozessoren verfolgt hat, der mag kaum glauben, dass die Forscher Hard- und Software-Hersteller angeblich schon im letzten Sommer über die Angriffszenarien informiert haben; so hektisch wie derzeit gepatcht und wieder zurückgezogen wird.

[gravitationsfeld]

tut mir leid, wenn du keinen wirtschaftswissentschaftlichen hintergrund wie ich hast :comfort:

wenn du nett fragst, erklär ich dir vllt warum das sinnvoll wäre.
Ich bin ja voll neidisch auf deinen wirtschaftswissentschaftlichen Hintergrund, aber in welcher Realitaet und unter welcher Regierung soll das bitte passieren? Trump? ;D

[x-force]

ich habe nirgendwo geschrieben, wo das passieren solle... das was richtig wäre, wird selten umgesetzt, wie du ja vllt selbst schon erkannt hast.
trotzdem sollte ab und zu mal gesagt werden, was richtig wäre, um nicht ausschließlich lügen und marketing märchen in seinem kopf zu haben.

[lumines]

Ich bin ja voll neidisch auf deinen wirtschaftswissentschaftlichen Hintergrund, aber in welcher Realitaet und unter welcher Regierung soll das bitte passieren? Trump? ;D

Vor allem wird x86 nicht automatisch sicher, wenn die Patente ungültig gemacht werden. ARM-Kerne können auch viele Unternehmen bauen und trotzdem haben wir in einigen Sicherheitslücken wie Spectre.

ich habe nirgendwo geschrieben, wo das passieren solle... das was richtig wäre, wird selten umgesetzt, wie du ja vllt selbst schon erkannt hast.
trotzdem sollte ab und zu mal gesagt werden, was richtig wäre, um nicht ausschließlich lügen und marketing märchen in seinem kopf zu haben.

Richtig wäre andere ISAs als x86(_64) zu fördern. Wir müssen nicht den ganzen Ballast mitschleppen. Heute hat man sehr viel mehr und ausgereiftere Werkzeuge um eine CPU-Architektur sicher zu gestalten. Ich denke gerade die letzten Lücken haben gezeigt, dass viele CPU-Hersteller sich dagegen sträuben im Zweifelsfall den langsamen, aber sicheren Weg zu gehen. Sogar jetzt scheint Intel ja die Lücken nicht wirklich mit kommenden CPUs fixen zu wollen.

[gravitationsfeld]

Welcher Ballast? Hast du dir mal ARM angesehen? Das ist genauso ein Gewuelst wie x86. Die ganzen erfolgreichen Architekturen die lange am Markt sind wurden endlos erweitert. PowerPC ist wahrscheinlich noch am saubersten.

[x-force]

Sogar jetzt scheint Intel ja die Lücken nicht wirklich mit kommenden CPUs fixen zu wollen.

das ist auch einer der größeren gründe, warum der laden geschlossen gehört.
aus einer marktbeherrschenden stellung heraus, kann man nicht einfach sagen, wir entwickeln scheiße und das ist gut so.

nach allem was ich immer gelesen habe, heißt es, daß ein dritter (ernstzunehmender) player nicht kommen wird, weil intel und amd(in zweiter instanz dann auch arm,ibm und andere) für quasi alles patente halten. darum muss man das feld für weitere konkurrenz öffnen.

patente töten innovation, an diesem beispiel sollte man es recht einfach begreifen können.

ich bin mir auch alles andere als sicher, daß die patente die intel hält sich ausschließlich auf x86 technologie beziehen. wer sagt dir, daß da nicht etwas beschrieben wird, was grundsätzlich für jede art von cpu nötig ist?

und dann gibt es ja noch reine patenttrolle und halbe patenttrolle wie arm, die weitere innovationen behindern.

[StefanV]

Vor allem wird x86 nicht automatisch sicher, wenn die Patente ungültig gemacht werden. ARM-Kerne können auch viele Unternehmen bauen und trotzdem haben wir in einigen Sicherheitslücken wie Spectre.
Unter ARM Kernen hast du aber eine wesentlich größere Varianz, von denen einige weniger stark anfällig für diese Attacke sein sollen als andere.

Die Samsung Exynos sollen z.B. recht gut sein, die A75 oder wie die hießen, nicht ganz so gut.

[Ganon]

Unter ARM Kernen hast du aber eine wesentlich größere Varianz, von denen einige weniger stark anfällig für diese Attacke sein sollen als andere.

Was aber nicht daran liegt, dass es ARM ist, sondern dass die CPUs größtenteils unter den Punkten "Low Power" und "Billig" gebaut werden. Das war und ist bei ARM-CPUs nunmal im Grunddesign verankert, weswegen Intel hier kaum Konkurrenz liefern kann. Alle ARM CPUs die auch nur in die Nähe von Intel CPUs kommen haben doch alle die gleichen Probleme, auch Meltdown.

Und wenn wir gerade alle schon wegen -5% bis -20% so dermaßen verzweifelt sind, dann sind ARM CPUs sowieso schon am weitesten von einer "Lösung" weg.

[StefanV]

erst einmal:
Wie ist deine EInschätzung zu dem Schlamassel? Wie würdest du beurteilen, wie stark die Prozessoren betroffen sind?

Als ob irgendwelche "Hardcore Intel Fans" irgend etwas mit dem Erfolg des Unternehmens zu tun haetten.
Ja, haben sie weil so Reichhaltig.
Und in den richtigen Positionen können die schon das ganze Problem runterspielen.
Und das ist dann wieder der übliche Teufelskreis...


Der Laden laeuft weil Amazon, Google, Dell und Apple die Chips kaufen, nicht wegen Stefan Mueller mit Bling-Bling-Gaming-Hardware.
Ja und wieviele von den Entscheidungsträger sind eher Intel zu- als abgeneigt? Und wieviele würden grundsätzlich kein AMD verbauen??
Das Ist doch eines der Probleme, auch insbesondere in Hinblick auf die Monokultur, die wir gerade haben...

Es wird ja immer gern von "Diversity" gesprochen, aber bei Technologiethemen, wo das am nötigsten ist, haben wir nur die Wahl zwischen 2 Sachen, wenn wir Glück haben...


Wo es weh tun koennte ist im Cloud-Bereich, falls dort wirklich vermehrt auch Alternativen (sprich AMD) eingesetzt werden.
Könnte, wenn denn umgerüstet werden würde oder müsste.
In dem HPC Bereich halte ich es für wahrscheinlicher, weil dem Wissenschaftler ist es total egal, worauf seine Berechnungen laufen. Der wird schon der IT Abteilung regelmäßig Feuer unterm Hintern machen, die dann schauen muss, wie sie die Rechenleistung möglichst preiswert erhöhen können.


Bei Game und Webservern scheint der Performance Impact ja am schlimmsten zu sein....

Aber mal abwarten und Tee rauchen, was passiert und ob einige umdenken...

[StefanV]

Was aber nicht daran liegt, dass es ARM ist, sondern dass die CPUs größtenteils unter den Punkten "Low Power" und "Billig" gebaut werden.
Völliger Unsinn!
Das liegt am unterschiedlichen Geschäftsmodell!

Arcon Risc Machine entwickelt den Befehllssatz und auch noch ein paar 'Referenzimplementierungen', fertigen tun sie NÜSCHT.

Sie lizensieren sowohl den Befehlssatz als auch ihre Referenz Implementierungen an jeden, der ein Interesse hat, ihre Prozessoren zu verwenden. Oder sogar selbst welche zu bauen.

DESWEGEN haben wir so viele verschiedene ARM Designs, weil die verantwortlichen das Design verkaufen/verleihen!
Das hat Intel vor langer langer Zeit auch mal gemacht...

Das war und ist bei ARM-CPUs nunmal im Grunddesign verankert
vor ~35 Jahren als man das entwickelt hat, ja.
Aber heute schaut die Welt ganz anders aus, da ist die Frage ob das heute noch genau so ausschaut...
Weil in den letzten ~35 Jahren oder so ist einiges an neuen Befehlen, Betriebsmodi usw hinzu gekommen...

[Rancor]

Vor Ryzen war AMD aber schlicht und einfach nicht konkurrenzfähig. Es gab absolut keinen technischen Grund Server mit Opteron CPUs zu kaufen.

Ich hoffe das wird sich jetzt ändern. Bei uns gehen die ersten HP Proliant Server mit Epyc CPUs schon zu den Kunden =)

[Ganon]

Aber heute schaut die Welt ganz anders aus, da ist die Frage ob das heute noch genau so ausschaut...
Weil in den letzten ~35 Jahren oder so ist einiges an neuen Befehlen, Betriebsmodi usw hinzu gekommen...

Ja, und ARMs neuste Kreation ist auch betroffen von Spectre V1, V2 und Meltdown. ARM ist wie x86 eine proprietäre Architektur in der Hand eines einzelnen Unternehmens... so, was genau bringt ein Wechsel?

Wo es weh tun koennte ist im Cloud-Bereich, falls dort wirklich vermehrt auch Alternativen (sprich AMD) eingesetzt werden.

AMD muss hierzu aber den OS-R&D Bereich wieder aufbauen, den sie vor Jahren abstoßen mussten. Die Kinderkrankheiten in der aktuellen Reihe in Kombination mit Non-Windows Systemen waren bisher einfach zu hoch.
Aktuell besteht z.B. das Problem, dass die CPUs in Low-Power States (C6) in Kombination mit einigen RCU-Flags direkt wegpennen und sterben. Der Watchdog hält dann das System an.

Solche Sachen und die ganzen Sachen davor müssen einfach im Vorfeld entdeckt und behoben werden, nicht erst Monate später. Und der Entdecker sollte AMD im Testlabor sein, nicht der Kunde. Bisher ist der Kundenkreis klein. Wenn ein großer Cloud-Anbieter auf sowas stößt, dann hat das viel schlimmere Folgen als wenn Max Mustermann sich in einem Forum darüber beschwert. Und das wollen wir alle nicht.

[HOT]

Microsoft und Baidou sind schon mal zwei Kunden, die Vorreiter für AMD sein könnten, da sich andere Unternehmen hieran orientieren bei der Hardwareauswahl. Sprich: Wenn sich solche Cloud-Giganten dafür entscheiden, bestätigt das nicht die üblichen Vorurteile, die StefanV meinte und die viele Leute in dem Bereich mit sich herumschleppen.

[Birdman]

Bzgl. den Intel Microcodes sieht es ja so aus, dass die bisher erschienenen komplett und für alle CPU Generationen fubar sind. (also nicht nur Haswell)
VMWare hat jedenfalls das entsprechende Security-Bulletin dahin erweitert und auch noch extra erwähnt, dass die Probleme damit alle Prozessoren seit Haswell/IvyBridge bis und mit Skylake-SP betreffen.

[][immy]

Vor allem wird x86 nicht automatisch sicher, wenn die Patente ungültig gemacht werden. ARM-Kerne können auch viele Unternehmen bauen und trotzdem haben wir in einigen Sicherheitslücken wie Spectre.



Richtig wäre andere ISAs als x86(_64) zu fördern. Wir müssen nicht den ganzen Ballast mitschleppen. Heute hat man sehr viel mehr und ausgereiftere Werkzeuge um eine CPU-Architektur sicher zu gestalten. Ich denke gerade die letzten Lücken haben gezeigt, dass viele CPU-Hersteller sich dagegen sträuben im Zweifelsfall den langsamen, aber sicheren Weg zu gehen. Sogar jetzt scheint Intel ja die Lücken nicht wirklich mit kommenden CPUs fixen zu wollen.
Warum verteufelst du jetzt x86/x64?
Das tolle ist ja, das auch alte Software noch wunderbar läuft. Und neues muss nicht unbedingt besser sein. Die Probleme von neuen Sachen sieht man meist erst relativ spät, d.h. was neues bringt dir erst mal wenig. Und was neues ohne Software noch weniger. Ist das neue nicht schneller als das alte (und eventuell noch effizienter) bringt dir das neue auch nix.

Klar wäre es schön wenn man PCs hätte wo man so ziemlich jeden Prozessor reinstecken könnte, aber das geht halt nicht ohne Standards und x86/x64 ist so ein Standard.
ARM ist da noch ein ganzes stück schlimmer. Hier gibt es innerhalb der Familie große Unterschiede.
Zudem Intel und AMD CPUs unterstützen zwar beide x86/x64 "Code", sind aber intern vollkommen unterschiedlich aufgebaut. Freiheiten haben CPU Hersteller hier genug. Sie können ja auch jederzeit Extra-Funktionen bereitstellen. Allerdings sind sonderlocken bei Entwicklern (im allgemeinen) nie sehr beliebt solange sie nicht Standard sind.
Hat ne Ewigkeit gedauert bis sich MMX, x64, SSE, AVX, ... durchgesetzt haben. Erst muss halt etwas in der breiten Masse unterstützt werden, bevor es sinnvoll wird es zu verwenden.

[Ganon]

[immy;11613504']Warum verteufelst du jetzt x86/x64?

Das Problem ist hauptsächlich, dass Intel bestimmt wer eine (halbwegs potente) x86 CPU bauen darf und wer nicht. Durch die über Jahre entstandene Abhängigkeit an x86 durch Windows ist das ein nicht gerade unbedeutender Fakt.

Der Weg hier raus führt nur in die allgemeine Inkompatibilität, weg von Windows, weg von x86-CPUs. Wie realistisch ist das? Selbst das Microsoft/Qualcomm Duo hat Stress mit Intel wegen ihrer "x86-on-ARM" Sache.

Und ARM ist da kein Stück besser. Ist das gleiche in Grün. Aber offene Alternativen haben entweder kein Geld oder kein Interesse. Der Servermarkt ist da architekturmäßig sicherlich flexibler, da hier recht viel Open Source Software zum Einsatz kommt, aber hier zählt auch "billig und schnell" und da sieht es dann auch wieder nicht so rosig aus. Wer stellt sich schon einen 20000€ IBM POWER Server hin für eine LAMP Anwendung?

Somit hast du einen immer wiederkehrenden Teufelskreis.

[Lehdro]

Solche Sachen und die ganzen Sachen davor müssen einfach im Vorfeld entdeckt und behoben werden, nicht erst Monate später. Und der Entdecker sollte AMD im Testlabor sein, nicht der Kunde.
Gilt sowas auch für Intel oder nur für AMD?

Im Sinne von Meltdown und Spectre bekommt diese Kritik (der Kunden) an AMD ja eine ganz neue Würze. Denn AMD kümmert sich immerhin und hat den Bonus zu sagen "neue Architektur". Sie sagen nicht einfach "war schon immer so", "wenn ihr wollt hier ist ein Microcodeupdate", "oh halt ist kaputt - baut es trotzdem erstmal ein". Eine Woche vorgespult und Intel sagt: "Halt Stop!" und es kommt ein neues...irgendwann. Da lacht sich doch der neutrale Beobachter ins Fäustchen...
Und die Krönung des ganzen ist das Verhalten welches Linus Torvalds anprangert - Intel scheint keinerlei Absichten zu haben sowas in Zukunft direkt ab Werk zu fixen weil es eben "kein Fehler" ist. Lol.

[Ganon]

Gilt sowas auch für Intel oder nur für AMD?

Gilt auch für Intel, aber Intel arbeitet auch am Kernel mit und hat schon entsprechende Bits und Fixes für die übernächste CPU Generation drin.

Bei AMD fährt man leider aktuell alle Nase lang gegen eine Wand und der Support seitens AMD ist eher mager. Wir hatten in 2017 ein (nun) CPU Errata Problem, der gefixt werden musste, wir hatten den Produktionsfehler der diverse Kernel-Entwickler vor Rätsel gestellt und AMD einfach lange nichts gesagt hat und nun haben wir ein Problem, dass die CPU Kerne bei längerer Idle-Zeit wegpennen und nicht mehr aufwachen.

Hier muss AMD einfach schneller und im Vorfeld agieren und nicht erst nach Fund beim Kunden reagieren. Bugs in den CPUs hat jeder Hersteller und auch Kernel haben Bugs. Aber die sollte, wie gesagt, der Hersteller im Testlabor finden und nicht der Kunde der vor einem gecrashten PC steht. AMD muss hier unbedingt wieder wie damals in der Kernel-Entwicklung mitmischen. Die Linux-Entwickler wissen nicht was AMD so in ihren Laboren rumliegen hat, um hier im Vorfeld schon was tun zu können.

[Pirx]

Es wird doch sicher Kontakte von AMD zu den Kernelentwicklern geben. AMD steigt gerade erst wieder ernsthaft in den Markt ein. Intel wird auch solche Probleme haben, trotz der Fixes, die sie schon für die überüberüberübernächste CPU-Generation einpflegen.
Ist hier iwie OT und klingt wie ein weiteres Ablenkungsmanöver, gerade vor dem Hintergrund der aktuellen Entwicklung.

[aufkrawall]

und nun haben wir ein Problem, dass die CPU Kerne bei längerer Idle-Zeit wegpennen und nicht mehr aufwachen.

Das soll es doch schon seit Kaveri geben?
Ich frage mich auch, ob das wirklich mit jedem Board auftritt.

[Ganon]

Das soll es doch schon seit Kaveri geben?
Ich frage mich auch, ob das wirklich mit jedem Board auftritt.

Woran es liegt weiß halt keiner. Kann ein Kernel-Bug sein, der nur bei AMD auftritt, kann ein BIOS Fehler sein, kann ein CPU Fehler sein. Ist halt immer doof, wenn es beim Kunden passiert. Wissen & Fixen kann es nur AMD. Immerhin ist es der CPU-Kern, der nicht nicht mehr ansprechbar ist.

Und für Leute, die mir wieder sonst was unterstellen wollen: Der Kontext sind Intel-Alternativen und die Kritik, dass der Wechsel von einem proprietären System zum anderen proprietären System keine dauerhafte Lösung ist.

[lumines]

das ist auch einer der größeren gründe, warum der laden geschlossen gehört.
aus einer marktbeherrschenden stellung heraus, kann man nicht einfach sagen, wir entwickeln scheiße und das ist gut so.

nach allem was ich immer gelesen habe, heißt es, daß ein dritter (ernstzunehmender) player nicht kommen wird, weil intel und amd(in zweiter instanz dann auch arm,ibm und andere) für quasi alles patente halten. darum muss man das feld für weitere konkurrenz öffnen.

Das setzt nicht tief genug an. Anstatt alles auf x86 auszurichten sollte man die Abhängigkeit dazu verringern.

Welcher Ballast? Hast du dir mal ARM angesehen? Das ist genauso ein Gewuelst wie x86. Die ganzen erfolgreichen Architekturen die lange am Markt sind wurden endlos erweitert. PowerPC ist wahrscheinlich noch am saubersten.

Klar, ARM ist keine Alternative. MIPS sollte man nicht vergessen, auch wenn RISC-V wahrscheinlich alle Anwendungsgebiete für MIPS verdrängen wird.

[immy;11613504']Warum verteufelst du jetzt x86/x64?
Das tolle ist ja, das auch alte Software noch wunderbar läuft. Und neues muss nicht unbedingt besser sein. Die Probleme von neuen Sachen sieht man meist erst relativ spät, d.h. was neues bringt dir erst mal wenig. Und was neues ohne Software noch weniger. Ist das neue nicht schneller als das alte (und eventuell noch effizienter) bringt dir das neue auch nix.

Damit verlangen wir viel zu wenig. Mit der festen Abhängigkeit zu x86 pappen wir ein künstliches Verfallsdatum auf den Code. Wäre es nicht viel schöner, wenn der Code zwischen den Architekturen portabel wäre? Es gibt da so eine freie Sammlung an Compilern, mit der man aus portablen C seinen Code einfach für andere Architekturen kompilieren kann. Wäre das nicht viel schöner als die Software an eine Architektur zu koppeln?

Man sieht ja, dass sich viele eine Welt ohne x86 schon gar nicht mehr vorstellen können. Wir sind mittlerweile so weit, dass wir es als massiven Einschnitt empfinden, wenn uns jemand x86 wegnehmen würde. Wie konnte es überhaupt so weit kommen? Ist da nicht etwas massiv schiefgelaufen?

[immy;11613504']Klar wäre es schön wenn man PCs hätte wo man so ziemlich jeden Prozessor reinstecken könnte, aber das geht halt nicht ohne Standards und x86/x64 ist so ein Standard.

Du kannst auch nicht auf jedes Mainboard jede CPU packen.

[immy;11613504']ARM ist da noch ein ganzes stück schlimmer. Hier gibt es innerhalb der Familie große Unterschiede.

Aktuell gibt es eigentlich nur ARMv7 und ARMv8. Alles abseits davon ist eher auf dem Abstellgleis.

[gravitationsfeld]

LLVM bitcode ist nicht portabel. Das ist ein weitverbreiteter Irrtum.

[Ganon]

LLVM bitcode ist nicht portabel. Das ist ein weitverbreiteter Irrtum.

Hat das gerade einer behauptet? Ich lese da gerade "portabler C Code".

Aber generell könnte man auf Basis von Bytecode schon CPU-portable Anwendungen schaffen. Das ist ja die Idee hinter Java (und .NET), nur noch ein Level darüber (OS-portabel). Ich glaube Apple bietet (fordert?) das ja schon an, dass die Anwendungen als LLVM Bitcode ausgeliefert werden. Android selbst ist im SDK die CPU auch egal, erst beim NDK wird es "kritisch".

Ist halt nur gerade kein Bedarf da, dem LLVM Laufzeitsystem ein "AnyCPU" Flag zu geben, gerade da C-Code ja eben ganz gerne mal böse CPU-abhängig sein kann. Prinzipiell möglich ist es aber.

[Birdman]

Aber generell könnte man auf Basis von Bytecode schon CPU-portable Anwendungen schaffen.
Aber wollen wir auch den Performance-Regress hierfür in Kauf nehmen?

[Ganon]

Aber wollen wir auch den Performance-Regress hierfür in Kauf nehmen?

Dass dabei die Performance sinkt ist gar nicht gesagt. LLVM IR deckt recht viele CPU-Features in einer portablen Art und Weise ab. Auch SIMD wird abgebildet. Man muss einfach nur vor dem ersten Start den Bytecode in Maschinencode übersetzen und dann ist im Prinzip alles fertig. Ist im GPU Bereich und Android Standard, dieses Vorgehen.

Hauptproblem ist, dass C-Code eben von Haus aus CPU-gebunden sein kann. Inline-ASM kann Clang auch nicht automagisch in LLVM IR umwandeln und bindet es einfach 1:1 ein. Auch alle SIMD-Routinen sind nicht abgebildet. Auch einige Datenstrukturen können aus Clang CPU-gebunden "rausfallen". D.h. wenn man sowas wollen würde, ist noch Arbeit nötig. Der Vorgang ist aber aktuell schon immer so, dass aus dem Compiler-Frontent eine IR rausfällt, die dann in Maschinencode gewandelt wird. Man würde nur die zwei Schritte voneinander trennen.

Wie ich schon mal irgendwo in dem Thread sagte: CPU-Optimiert ist unsere heutige PC-Software sowieso nicht zwangsläufig (darum ist ClearLinux im Vergleich so fix). In der Regel wird für generic x86-64 kompiliert. Der Entwickler selbst muss hier manuell vorgehen, wenn er a) portabel zwischen Intel und AMD sein will und b) moderne CPU Features wie AVX benutzen möchte. Oder er sagt selbst: Erst ab CPU-Generation X lauffähig. Sorgt auch immer für Shitstorm (No Man's Sky mit SSE4.1 oder Destiny 2 mit SSSE3).

LLVM IR könnte in der Theorie (!) sogar zu besserer Geschwindigkeit führen. Ist dafür aber aktuell nicht ausgelegt.

[dildo4u]

Sicherheitslücke Spectre: Intel empfiehlt OEMs die ersten Updates einzustellen

https://www.computerbase.de/2018-01/dell-hp-lenovo-spectre-updates-zurueckgezogen/

[RoNsOn Xs]

Btw es gibt für das Asrock-Skylake-System von 2016 (das meiner Freundin) immer noch kein neues Bios, was gegen Spectre helfen soll. Was ist da los?

https://www.asrock.com/mb/Intel/Fatal1ty%20Z170%20Gaming%20K4/index.de.asp?cat=Download&os=BIOS

[Michalito]

a: Asrock ist noch nicht soweit.
b: Intel auch noch nicht. s.o., daher, dann eigentlich auch kein anderer..

[RoNsOn Xs]

Achso`Dachte es seien schon vergangene Woche einige Rollouts gewesen, von denen ich vermeintlich gelesen hätte.

[Dorn]

Achso`Dachte es seien schon vergangene Woche einige Rollouts gewesen, von denen ich vermeintlich gelesen hätte.
Alle für die Tonne, Intel muss nachsitzen. Ich hole schon mein Popcorn für den zweiten Versuch raus.

[gravitationsfeld]

Hat das gerade einer behauptet? Ich lese da gerade "portabler C Code".
Kommerzielle Applikationen werden wohl kaum ihren Source-Code ausliefern. Die einzige Alternative ist also eine Zwischenrepraesentation wie Java-Bytecode.

Dass dabei die Performance sinkt ist gar nicht gesagt. LLVM IR deckt recht viele CPU-Features in einer portablen Art und Weise ab.
Willst du mich verarschen? Zuerst sagst du, dass es nicht relevant ist, weil es um C-Code geht und im naechsten Satz behauptest du dann DOCH, dass LLVM IR portabel ist.

LLVM IR ist nicht portabel. Und wird es auch nie sein: https://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-platform-independent-llvm-bitcode

[Schnoesel]

Spectre: Details zu Microcode-Updates für CPUs von AMD

https://www.computerbase.de/2018-01/spectre-microcode-update-cpu-amd-details/

[Ganon]

Kommerzielle Applikationen werden wohl kaum ihren Source-Code ausliefern. Die einzige Alternative ist also eine Zwischenrepraesentation wie Java-Bytecode.

Genau das sagte ich ja. Die Hersteller könnten a) die Anwendung für jede CPU durchkompilieren die das OS so unterstützt oder b) eine IR ausliefern. Apple macht übrigens Variante b, mit den Problemen, dass man seine Sprache eben an Apples LLVM Fork anpassen muss. Wie Android funktioniert muss ich dir sicherlich auch nicht erklären.


Willst du mich verarschen? Zuerst sagst du, dass es nicht relevant ist, weil es um C-Code geht und im naechsten Satz behauptest du dann DOCH, dass LLVM IR portabel ist.

Nein, ich habe gesagt, dass LLVM IR portabel sein könnte und teilweise ist (weil du es zur Sprache gebracht hast), jedoch C hier im Regelfall einen Strich durch die Rechnung macht und LLVM IR in der aktuellen Fassung dafür nicht ausgelegt ist. Übrigens genau das was du dazu verlinkt hast. Bitte alles Lesen was Leute schreiben, nicht nach dem ersten Satz aufhören und "deinen Charm" versprühen.

[gravitationsfeld]

Die Praxis spricht eine andere Sprache. ABIs, Alignment-Regeln usw. machen dem einen Strich durch die Rechnung. Du brauchst automatische Speicherverwaltung um dem Herr zu werden, weil du keine konkreten Offsets kompilieren kannst.

[Achill]

https://www.computerbase.de/2018-01/spectre-microcode-update-cpu-amd-details/

Sehr interessant ist auch der letzte Absatz:


[..]
Intel wiederum würde laut Heise auch in diesem Fall ab Broadwell ein Microcode-Update benötigen, das dem Konzern aktuell viele Probleme bereitet. Ältere Intel-CPUs wären hingegen ebenfalls ohne Aktualisierung sicher, falls Microsoft die Retpoline-Technik in Windows einbauen sollte.


Das würde auch die Problematik mit älteren CPUs und MB umschiffen, wo Bios-Updates nicht kommen werden bzw. erst sehr spät.

[Birdman]

Hu, dann gibts also "3 Stufen" Intel CPUs, bzg. einer möglichen Spectre_v2 Mitigation?

a) pre-Broadwell
b) Boradwell bis KabyLake
c) Skylake bis ???

Oder hat sich Computerbase allenfalls vertan?
Weil in der Linux/Kernel Community dreht sich aktuell imho alles um Skylake und dass bei dieser CPU die aktuellen Methoden (u.A. Retpoline) bei Spectre_v2 nichts bringen, alles davor aber abgedeckt sei.

[Ganon]

Weil in der Linux/Kernel Community dreht sich aktuell imho alles um Skylake und dass bei dieser CPU die aktuellen Methoden (u.A. Retpoline) bei Spectre_v2 nichts bringen, alles davor aber abgedeckt sei.

Sie bringen nicht "nichts". Skylake wird damit nur nicht "100%ig" abgesichert und eine Retpollne-Erweiterung auf Skylake+ ist in Arbeit. Es gibt hier einfach noch einen weiteren Angriffsvektor.

Dazu kannst du noch mal den Link von hier lesen: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11612025&postcount=1597

[Monsta]

Naben zusammen,

falls es einen interessiert.

Seit heute ist der GCC 7.3 Stable, mit Full Repoline support.

Ich habe den 4.15rc9 Kernel damit Kompiliert.

http://prntscr.com/i5lmzb

Da der Compiler noch nicht im Gentoo repository ist, und es auch noch etwas dauert bis der dort Stable ist. Werde ich nicht mein ganzes System neu übersetzen.

http://prntscr.com/i5lmzb

[Ganon]

Hier übrigens der Output von einem aktuellen ArchLinux:

Spectre and Meltdown mitigation detection tool v0.32

Checking for vulnerabilities on current system
Kernel is Linux 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i7-4750HQ CPU @ 2.00GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
> STATUS: VULNERABLE (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

[Sephiroth]

Naben zusammen,

falls es einen interessiert.

Seit heute ist der GCC 7.3 Stable, mit Full Repoline support.

Ich habe den 4.15rc9 Kernel damit Kompiliert.

http://prntscr.com/i5lmzb

Da der Compiler noch nicht im Gentoo repository ist, und es auch noch etwas dauert bis der dort Stable ist. Werde ich nicht mein ganzes System neu übersetzen.

der ist im repo (https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/gcc/gcc-7.3.0.ebuild) aber hat noch keine keywords. daher einfach mit ** als keyword akzeptieren (https://wiki.gentoo.org/wiki/Knowledge_Base:Accepting_a_keyword_for_a_single_package).
If the mask is because no KEYWORDS are defined, use the ** notation:

~sys-apps/portage-9999 **

ps.
https://www.phoronix.com/scan.php?page=article&item=gcc8-mindirect-thunk&num=1
By default GCC isn't enabling -mindirect-branch but the default value is "keep" to keep indirect calls unmodified.

Retpoline-patched kernels automatically make use of -mindirect-branch=thunk in the kernel build when available for full kernel protection. But you can also build user-space packages with -mindirect-branch=thunk to avoid speculative indirect calls within application code.

[Monsta]

der ist im repo (https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/gcc/gcc-7.3.0.ebuild) aber hat noch keine keywords. daher einfach mit ** als keyword akzeptieren (https://wiki.gentoo.org/wiki/Knowledge_Base:Accepting_a_keyword_for_a_single_package).

Ich hatte mir einfach ein eigenes Ebuild gemacht. Und aus meinen eigenes Portage genutzt.

Aber danke für die Info

[Lehdro]

Hu, dann gibts also "3 Stufen" Intel CPUs, bzg. einer möglichen Spectre_v2 Mitigation?

a) pre-Broadwell
b) Boradwell bis KabyLake
c) Skylake bis ???

Oder hat sich Computerbase allenfalls vertan?
Weil in der Linux/Kernel Community dreht sich aktuell imho alles um Skylake und dass bei dieser CPU die aktuellen Methoden (u.A. Retpoline) bei Spectre_v2 nichts bringen, alles davor aber abgedeckt sei.
Es gibt bei Intel zwei Stufen:
Alles bis einschließlich Haswell und alles ab Broadwell. Deine Liste macht keinen Sinn da Skylake nach Broadwell kam und Kabylake sowie auch Coffeelake im Grunde auch nur Skylakes sind.

Ich habe das mit den Alternativen jetzt so verstanden:
So wie momentan unter Windows gepatcht wird mit den drei extra Befehlen (IBRS, STIBP, IBPB) passiert folgendes:

+ Patch schon verfügbar
+ funktioniert sofort mit jeder Software
- braucht bei AMD Microcodeupdates
- braucht bei Intel Microcodeupdates
- Leistungseinbußen auf aktuellen CPUs
- größere Leistungseinbußen auf älteren Intel CPUs

Mit Retpoline:

+ AMD braucht keine Microcodeupdates
+ Alles von Intel unterhalb von Broadwell braucht kein Microcodeupdate
+ kleinere Leistungseinbußen im Vergleich bei älteren Intel CPUs
- "größere" Leistungseinbußen bei neueren Intel CPUs
- Intel braucht ab Broadwell wieder Microcodeupdates
- Microsoft müsste alles neu patchen (Riesenaufwand gegenüber der jetzigen Lösung)

Sehe ich das so richtig?

[Freestaler]

@Lehdro

- Messbare (ua. auch relevante) Leistungseinbußen auf aktuellen CPUs Intel, AMD noch unklar da microupdate noch nicht veröffentlicht

Mit Retpoline:

- Microsoft müsste alles neu patchen (Riesenaufwand gegenüber der jetzigen Lösung) -> Müssen sie evtl sowieso, da 3. Januar und nach besserung um 19. Januar wohl doch da und dort noch ein bug haben.

[lumines]

Chrome 64 für Desktop und Android ist übrigens raus und hat die ersten Abmilderungen gegen Spectre dabei. Vielleicht lieber einmal früher als später den Browser neu starten.

[Ganon]

[...]
Mit Retpoline:

+ AMD braucht keine Microcodeupdates
+ Alles von Intel unterhalb von Broadwell braucht kein Microcodeupdate
+ kleinere Leistungseinbußen im Vergleich bei älteren Intel CPUs
- "größere" Leistungseinbußen bei neueren Intel CPUs
- Intel braucht ab Broadwell wieder Microcodeupdates
- Microsoft müsste alles neu patchen (Riesenaufwand gegenüber der jetzigen Lösung)

Sehe ich das so richtig?

Wie schon mal geschrieben: Eine Retpoline-Erweiterung für Skylake+ ist in Arbeit. Ansonsten ist es der aktuelle Stand der Dinge, ja.

[vanquish]

Ich finde den spectre-meltdown-checker mittlerweile etwas "strange". Einmal ohne "options" und einmal mit "options". Siehe Anhang. :freak:

Was ist da jetzt wohl richtig? :( ... Ich befürchte, dass die erweiterte Abfrage wohl richtig liegt. ^^ Warum zum Geier wird hier nicht mehr alles abgefragt, so wie vorher auch.

[Ganon]

Das liegt daran, dass es aktuell unmengen von Kernel-Konfiguationen umherfliegen, die allesamt nicht Mainline sind. Wie die Beschreibung des Tools sagt, kann es auch nur so gut es geht ermitteln, aber nicht 100%ig garantieren.

Auf der einen Seite sagt halt das Kernel-Interface "Jup, Patch ist da", auf der anderen Seite wurde dein Kernel aber noch nicht mit einem Retpoline GCC kompiliert.

Bei mir sieht es ohne "--no-sysfs" so aus: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11614200&postcount=1661

[vanquish]

Verstehe ich es dann richtig, dass beides erfüllt sein muss um einigermaßen sicher zu sein bzw. als "nicht verwundbar" zu gelten. Oder reicht es wenn der Kernel mit retpline option compiliert wurde?
Ich würde fast meinen, dass ein compile mit retpoline option ohne den entsprechend aktualisierten Compiler nicht so toll ist, da der Compiler ja noch immer "falsche" Optimierungen enthalten kann.
Und gibt es eine Möglichkeit den Kernel abzufragen mit welchem Compiler er kompiliert wurde? Ich dachte uname geht ... Finde aber nichts.

[Ganon]

Verstehe ich es dann richtig, dass beides erfüllt sein muss um einigermaßen sicher zu sein bzw. als "nicht verwundbar" zu gelten. Oder reicht es wenn der Kernel mit retpline option compiliert wurde?
Ich würde fast meinen, dass ein compile mit retpoline option ohne den entsprechend aktualisierten Compiler nicht so toll ist, da der Compiler ja noch immer "falsche" Optimierungen enthalten kann.

Zwei verschiedene Dinge. Das eine ist die Retpoline Funktionalität im Kernel selbst, bei einem Syscall, das Andere ist der "Selbstschutz" indem die verwendete Software (hier der Kernel) entsprechend kompiliert wurde.

[vanquish]

ah, ok, danke.

EDIT: cat /proc/version
Linux version 4.14.15-1-ARCH (builduser@heftig) (gcc version 7.2.1 20180116 (GCC)) #1 SMP PREEMPT Tue Jan 23 21:49:25 UTC 2018

[Ganon]

Zur weiteren Info aus der Kernel KConfig:
arch/x86/Kconfig (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/Kconfig#n432)



config RETPOLINE
bool "Avoid speculative indirect branches in kernel"
default y
help
Compile kernel with the retpoline compiler options to guard against
kernel-to-user data leaks by avoiding speculative indirect
branches. Requires a compiler with -mindirect-branch=thunk-extern
support for full protection. The kernel may run slower.

Without compiler support, at least indirect branches in assembler
code are eliminated. Since this includes the syscall entry path,
it is not entirely pointless.




edit:
Und aus dem Makefile:

# Avoid indirect branches in kernel to deal with Spectre
ifdef CONFIG_RETPOLINE
RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern -mindirect-branch-register)
ifneq ($(RETPOLINE_CFLAGS),)
KBUILD_CFLAGS += $(RETPOLINE_CFLAGS) -DRETPOLINE
endif
endif

[vanquish]

und aus dem installierten/laufenden Kernel:

cat /sys/devices/system/cpu/vulnerabilities/spectre_v1

Vulnerable

gzip -cd /proc/config.gz | grep -i retpoline

CONFIG_RETPOLINE=y

gzip -cd /proc/config.gz | grep -i isolation | grep -i page

CONFIG_PAGE_TABLE_ISOLATION=y



So braucht man wenigstens kein "Tool". Und ob die Hardware gepatcht ist oder nicht interessiert mit Retpoline Kernel sowieso nur die Skylake+ User.

[F4USt]

Auf einmal ist ein Hardwarefix nicht mehr weit. Abwarten ...

http://www.pcgameshardware.de/CPU-Hardware-154106/News/Intel-CPUs-mit-Hardware-Fix-gegen-Spectre-und-Meltdown-angekuendigt-1248791/

[Denniss]

Nach über 6 Monaten gibt es keinen brauchbaren fix per Software (Microcode update) und dann wollen die plötzlich was in Hardware fixen die eine Vorlaufzeit von bald 2 Jahren hat ?!?

[Zone]

Ich finde das auch alles sehr merkwürdig. Erinnert sich noch jemand an den TLB Bug 2007 in den AMD K10 Prozessoren? Nach längerem Betrieb (ca. 2 Wochen?) konnten theoretisch Fehler im TLB auftreten die zum Absturz führten. Damals wurde AMD dafür verteufelt und hat auch viel Vertrauen im Server-Markt verloren den sich AMD erst kurz vorher mit den ersten Opteron Prozessoren erarbeitet hatte. AMD hatte nach Bekanntwerden des Bug damals die Auslieferung der Prozessoren gestoppt um den Fehler näher zu untersuchen. Später wurde ein Fix mittels BIOS Updates durch die Mainboardhersteller bereitgestellt. Dieser Fix hatte das Problem gelöst, jedoch sank auch die Performance je nach Anwendung mehr oder weniger stark. Das Problem war in der nächsten Hardware Revision von K10 dann auch behoben.

Und Intel heute? Patches werden verteilt, wieder zurückgezogen, erneut verteilt. Intel lässt merkwürdige Pressemitteilungen versenden und versucht sich herauszuwinden das mit ihren Prozessoren alles in Ordnung sei.

Ich will das nicht kleinreden. Das Sprectre und Meltdown Problem ist sehr komplex und so tief in der Architektur verwurzelt das man das nicht von heut auf morgen fixen kann.
Aber: Es war seit Sommer 2017 bekannt. Was macht Intel? Erst einmal Coffee Lake releasen (Vergleich damals AMD: Auslieferung gestoppt). Weiterhin: Das Problem reicht ja bis Sandy Bridge (2011), theoretisch musste man sich mindestens seit Pentium Pro (1995) mit Seitenkanalangriffen auseinander setzen und niemanden in den ganzen Jahren bei Intel ist nicht aufgefallen das es hier Angriffe möglich sind? Bei Intel mit ihrem Millarden Budget für F&E? Mit ihren 100.000 Mitarbeitern? Wirklich? Wir reden hier nicht von VIA, sondern vom Marktführer!

Übrigens sind kürzlich wieder die Quartalszahlen von Intel veröffentlicht worden. Natürlich eine Steigerung in Umsatz, Gewinn und Aktienkurs. Ich kann euch versichern das jenes auch im nächsten Jahr wieder so sein wird - trotz Spectre und Meltdown. Ihr mit eurem Konsumverhalten habt einen Anteil daran! Ist ähnlich wie bei Nvidia und der GTX 970. Der Kunde wird beschissen und kauft das Produkt trotzdem.

Ich habe seit 1997 AMD und Intel Produkte gekauft. Genauso wie ich die ganzen Jahre immer mal wieder 3dfx, Nvidia und ATI/AMD gekauft habe. 3dfx kann ich nicht mehr kaufen, Nvidia will ich seit 2015 nicht mehr kaufen (GTX970). Intel hatte ich nach der Geschichte mit den Anti-AMD Knebelverträgen in den 90er / 2000er noch einmal eine Chance gegeben, das passiert mir in absehbarer Zeit nicht mehr. Ich will damit nicht sagen das AMD heilig ist, da gab es mit Sicherheit auch fragewürdige Geschäftspraktiken in der Vergangenheit. Der Umgang von Intel an dieser Stelle ist jedoch mal wieder erbärmlich. AMD hat an der Stelle Glück das sie nur von Spectre Variante 1 betroffen sind, die Kommunikation seitens AMD ist hier aber auch verbesserungswürdig.

Der Nutzer hat es in der Hand, privat als auch auf Arbeit wenn ihr beruflich in entsprechender Verantwortung sitzt. Will ich Produkte einer Firma kaufen / einsetzen die mich / uns belügt? Zumindest wenn ich Alternativen habe und diese eine ähnliche Leistung bieten sollte die Auswahl nicht so schwer fallen: An dieser Stelle muss man keine Verschwörungstheoretiker oder Fanboy sein um hier seine Schlüsse zu ziehen.

[vanquish]

Nach über 6 Monaten gibt es keinen brauchbaren fix per Software (Microcode update) und dann wollen die plötzlich was in Hardware fixen die eine Vorlaufzeit von bald 2 Jahren hat ?!?

Würde die neue Hardware Ende 2018 erscheinen, wären seit Entdeckung der Lücke schon wieder 1,5 Jahre vergangen. Nimmt man jetzt an, dass für dieses Problem mehr Geld/Manpower als üblich investiert wird, kann man das halbe Jahr schon "einsparen". Die Frage ist ob dabei etwas sinnvolles heraus kommt. :D ... Ich würde ja darauf tippen, dass sie nicht mehr machen als z. B. den PCID-Ansatz etwas komplexer und straffer auszugestalten. K. A. ob das schon ausreichen würde.

[LadyWhirlwind]

Nach über 6 Monaten gibt es keinen brauchbaren fix per Software (Microcode update) und dann wollen die plötzlich was in Hardware fixen die eine Vorlaufzeit von bald 2 Jahren hat ?!?


Wahrscheinlich werden die neuen CPUs nur das was aktuell die Mikro-Code Updates machen bereits integriert haben...

[Ganon]

Wahrscheinlich werden die neuen CPUs nur das was aktuell die Mikro-Code Updates machen bereits integriert haben...

An der zukünftigen Prozessor Whitelist im Linux Kernel wird man es dann ja sehen. Der Linux Kernel führt ja eine öffentliche Bug-Liste:


$ cat /proc/cpuinfo | grep bug
bugs : cpu_meltdown spectre_v1 spectre_v2

[Pirx]

bringt ja auch mehr, neue, "sichere" CPUs zu verkaufen, als die "alten" mit Performanceverlusten sicher zu machen...
bis dahin wird wohl gemauert, Nebelkerzen geworfen und nichts zugegeben, geschweige denn entschuldigt - und das wird mehr oder weniger akzeptiert, ist ja Intel

[eratte]

bringt ja auch mehr, neue, "sichere" CPUs zu verkaufen, als die "alten" mit Performanceverlusten sicher zu machen...

Wirkt doch auch schon, genug Aussagen schon gelesen und gehört das man dann wartet und doch wieder intel kauft.

[Poook]

bringt ja auch mehr, neue, "sichere" CPUs zu verkaufen, als die "alten" mit Performanceverlusten sicher zu machen...
bis dahin wird wohl gemauert, Nebelkerzen geworfen und nichts zugegeben, geschweige denn entschuldigt - und das wird mehr oder weniger akzeptiert, ist ja Intel

Natürlich lohnt es sich die alten langsamer zu machen, da dann die neuen prozentual noch schneller sind.

[][immy]

bringt ja auch mehr, neue, "sichere" CPUs zu verkaufen, als die "alten" mit Performanceverlusten sicher zu machen...
bis dahin wird wohl gemauert, Nebelkerzen geworfen und nichts zugegeben, geschweige denn entschuldigt - und das wird mehr oder weniger akzeptiert, ist ja Intel
Nur hat Intel noch nichts sicheres und aktuelles. CL wurde grad erst gelauncht und das sogar obwohl sie schon über die Lücke bescheid wussten. Das man den Start nicht wenigstens verzögert hat bis die Lück geschlossen ist, ist vollkommen unverständlich.
Ich glaube nicht das Intel jetzt so schnell mit einer neuen CPU um die Ecke kommt wo sie das Problem behoben haben.
Bei AMD hingegen gibt es zwar durchaus auch Probleme, aber die Ausnutzungsgefahr geht wohl tatsächlich gegen 0. Das ist zwar immer noch nicht toll, aber immerhin haben sie derzeit ein Produkt (im Gegensatz zu Intel) das man schon mal als sicherer betrachten könnte.
Wird aber wohl nichts daran ändern das trotzdem alle möglichen Firmen weiterhin auf Intel setzen.

[Sephiroth]

Frage an die Linux user: womit muss ich denn meinen Kernel bauen, damit er gegen Spectre Variante 1 geschützt ist? Mit gcc 7.3.0 und Kernel 4.14.15 liefert mir "/sys/devices/system/cpu/vulnerabilities/spectre_v1 " noch "Vulnerable". Ist der fix dafür erst in Kernel 4.15 enthalten?

[yummy_candy]

Frage an die Linux user: womit muss ich denn meinen Kernel bauen, damit er gegen Spectre Variante 1 geschützt ist? Mit gcc 7.3.0 und Kernel 4.14.15 liefert mir "/sys/devices/system/cpu/vulnerabilities/spectre_v1 " noch "Vulnerable". Ist der fix dafür erst in Kernel 4.15 enthalten?


Laut Heise enthält deine Kernelversion noch keinen Schutz:
Linux 4.15 enthält noch keinen Schutz gegen die erste Spectre-Variante. Zum Schutz vor der zweiten braucht es Hilfe vom Compiler, die diesem Kernel-Image fehlt.

https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html?seite=2

[unl34shed]

bringt ja auch mehr, neue, "sichere" CPUs zu verkaufen, als die "alten" mit Performanceverlusten sicher zu machen...
bis dahin wird wohl gemauert, Nebelkerzen geworfen und nichts zugegeben, geschweige denn entschuldigt - und das wird mehr oder weniger akzeptiert, ist ja Intel

Die Nebelkerzen werden ja sogar von unserer Fachpresse dankend angenommen und verbreitet, siehe die ganzen News bgzl. "gefixter Hardware noch dieses Jahr". Auch wenn es utopisch ist.

Es wird aber wohl auch nur abgeschrieben, anstatt sich mal das Transkript dazu anzuschauen, dann das Hat Intel nicht mal behauptet!
Intel will nur Änderungen wegen Meltdown/Spectre einbauen. Würde die Lücke damit komplett geschlossen, hätte man das wohl auch genau so gesagt.

Und das mit den Änderungen deckt sich mit Intels erstem Statement, man will diese Jahr ein Produkt bringen, das den Software Workaround erleichtert.

[Sephiroth]

Laut Heise enthält deine Kernelversion noch keinen Schutz:


https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html?seite=2
thx ... also dann wohl erst mit 4.16

[HOT]

[immy;11615408']Nur hat Intel noch nichts sicheres und aktuelles. CL wurde grad erst gelauncht und das sogar obwohl sie schon über die Lücke bescheid wussten. Das man den Start nicht wenigstens verzögert hat bis die Lück geschlossen ist, ist vollkommen unverständlich.
Ich glaube nicht das Intel jetzt so schnell mit einer neuen CPU um die Ecke kommt wo sie das Problem behoben haben.
Bei AMD hingegen gibt es zwar durchaus auch Probleme, aber die Ausnutzungsgefahr geht wohl tatsächlich gegen 0. Das ist zwar immer noch nicht toll, aber immerhin haben sie derzeit ein Produkt (im Gegensatz zu Intel) das man schon mal als sicherer betrachten könnte.
Wird aber wohl nichts daran ändern das trotzdem alle möglichen Firmen weiterhin auf Intel setzen.

Klar ist das verständlich. Die wollten unter allen Umständen, dass Coffeelake den Ruf bekommt, den er hat. Meiner Ansicht nach war das sogar der Hauptgrund für den verfrühten Launch, obwohl der faktisch ja desaströs war, da ja erst jetzt, also den Zeitpunkt, den Coffeelake eigentlich hätte starten sollen, genügend 6-Kern-Dies zur Verfügung stehen.

[Linmoum]

Zen2 kommt laut Lisa Su (Earnings Call) mit entsprechenden Anpassungen für Sicherheitslücken wie Spectre.

[Pirx]

Nachdem Updates zurückgezogen wurden: bedeutet das, daß viele Server nach wie vor schutzlos im Netz dastehen?

[Thoro]

Kann es eigentlich sein, dass die ganzen Patches der letzten Tage/Wochen Einfluss auf die Performance von Websites haben? Die letzten Tage kommt mir das Internet teils relativ langsam vor, vor allem im TLS-Handshake mit Websites hängt der Browser schon mal gerne minutenlang - und ein paar Minuten später geht es dann wieder normal.

Kann das was mit dem ganzen Brimborium zu tun haben? (kann auch absolut sein, dass mir das vorher einfach nur nie aufgefallen ist und dass eh alles gleich ist)

[Birdman]

Nachdem Updates zurückgezogen wurden: bedeutet das, daß viele Server nach wie vor schutzlos im Netz dastehen?
Grundsätzlich ja, allerdings gilt das nur für Spectre_2. Meltdown und Spectre_v1 Patches sind ja schon länger draussen und werden viele auch eingespielt haben.

Bleibt daher nur Spectre_v2 und hier gilt:

- Unter Linux dank "Retpoline" Patches für ältere Intel CPUs bereits gefixt
- Grundsätzlich selbst auf Intel CPU's schwierig* zu triggern


* Es ist aufwändig/komplex da man genaue Kentnisse der Plattform und der darauf laufenden Applikationen haben muss. Relativ einfach ist da noch ein gezielter Angriff bei z.B. einem Cloud-Server wo man parallell zu andern VMs einen eigenen vServer hat.
Sehr schwer bis unmöglich ist allerdings irgendeine Scriptkiddie Malware, die man auf x-tausende Systeme loslässt und hofft "irgendwas" erreichen zu können.

[mironicus]

Für mein MSI-Laptop gab es vor kurzem noch ein Bios-Update wegen Spectre. Das wurde auch zurückgezogen. Zum Glück habe ich es nicht installiert.

[mboeller]

ouch! FeFe:


Mit dem alten Kernel:

bench: 164835678432 bytes in 24.7616 seconds.
bench: Throughput: 6.2GiB/sec
bench: Requests per second: 40

und mit dem neuen Kernel:

bench: 164870699232 bytes in 39.3921 seconds.
bench: Throughput: 3.9GiB/sec
bench: Requests per second: 25


http://blog.fefe.de/?ts=a48fe42c da stehen noch einige Erklärungen etc...

[lumines]

ouch! FeFe:



http://blog.fefe.de/?ts=a48fe42c da stehen noch einige Erklärungen etc...

Wow, das ist echt heftig. Das Web ist gerade eben um ein gutes Stück langsamer geworden.

[Poook]

Für mein MSI-Laptop gab es vor kurzem noch ein Bios-Update wegen Spectre. Das wurde auch zurückgezogen. Zum Glück habe ich es nicht installiert.

Same for me. Die Situation ist echt scheiße.

[Athlonxp]

ein weiteres tool zur überprüfung :)

https://www.computerbase.de/downloads/sicherheit/antimalware/inspectre/

[Dorn]

ein weiteres tool zur überprüfung :)

https://www.computerbase.de/downloads/sicherheit/antimalware/inspectre/
Äh, das ist alt und wurde hier schon oft genug behandelt. Guten Morgen...

[Pirx]

M/S kommen wohl "langsam" in der "Praxis" an

http://www.tomshardware.com/news/meltdown-spectre-malware-found-fortinet,36439.html

[StefanV]

Ob das ganze für den Equifax Leak letztes Jahr verantwortlich war, bei dem die Daten von so ziemlich jedem Amerikaner verloren gegangen sind?

[vanquish]

CVE-2017-5638 ... Apache

[gravitationsfeld]

Ob das ganze für den Equifax Leak letztes Jahr verantwortlich war, bei dem die Daten von so ziemlich jedem Amerikaner verloren gegangen sind?
Nein. Das war CVE-2017-9805. Stinknormaler Exploit. Hoer auf Verschwoerungstheorien zu erfinden.

[aufkrawall]

Ich hege etwas den Verdacht, dass entweder die Meltdown/Spectre-Fixes oder andere WU-Änderungen aus den letzten vier Wochen mir mein Atom x5-Z8300 Gerät etwas unvorhersehbar unzuverlässig gemacht haben. ProcessHacker (Treiber deaktiviert) blockiert das Herunterfahren, auch wenn seine Prozesse schon gar nicht mehr laufen. Gestern crashte mir mpv und wollte erst wieder nach einem Neustart starten. Irgendwann verabschiedete sich das System nach dem Installieren von Software mal mit einem Blackscreen ins Nirwana.
So etwas war in den Monaten vor Januar nie passiert.

[Rancor]

Ob das ganze für den Equifax Leak letztes Jahr verantwortlich war, bei dem die Daten von so ziemlich jedem Amerikaner verloren gegangen sind?

:facepalm:

Ohne Worte

[StefanV]

:facepalm:
Ohne Worte
Warum?
Wäre doch eine Möglichkeit, dass dieser Zustand in den tiefsten Tiefen des "Dark Webs" bekannt war?
Und die meisten dürften Intel Hardware einsetzen.

Und das kann man dann mindestens nutzen, um Passwörter zu dem System auszuspähen und Zugriff auf die Datenbank zu bekomme...

[vanquish]

Warum? Weil du zwischen einem bekannten Hack (Equifax) und der Intel Lücke(n) einen Zusammenhang hergestellt hast der nachweislich nicht existiert:

https://blogs.apache.org/foundation/entry/apache-struts-statement-on-equifax

Das kann man jetzt als Ignoranz, wissentliche Verbreitung falscher Nachrichten, Dummheit oder Besserwisserei bezeichnen. Was dahinter Steckt weisst nur du. :D

Niemand hier, denke ich, lässt den Gedanken außer acht, dass das bereits genutzt worden sein könnte. Allerdings wäre dies im Zweifel eben nicht nachweisbar. Was ja das "tolle" an dieser Lücke ist. Lediglich die Lücke die dem Hacker half auf das System zu gelangen ist ggf. nachweisbar. Außer der/die Hacker haben das Programm und den dazugehörigen Dump zurückgelassen.

Gleichwohl musst du aber auch erkennen, dass diese Lücke nicht von ein paar Hackern mit ein paar Computern gefunden werden konnte (außer in der Theorie). Sprich: Know-How, Technik und Zeit eine wesentliche Rolle gespielt haben (die brauchten ein halbes Jahr). In dieser Liga spielen wohl eher nur staatliche Stellen (oder Grosskonzerne mit Interesse). Es gibt wie bei dem o. g. Fall einfachere Methoden. Ein Admin macht nun mal Fehler und drauf ist im Zweifel viel mehr Verlass (vgl. Eqifax und falsches patch level einer einzigen library)! Der Bundestrojaner zeigt denke ich auch ganz gut warum. Und die Tatsache, dass die BRD soetwas von einer Privatfirma kauft zeigt auch das Know-How unserer Dienste. Aber wie gesagt, um diese Meltdown oder Spectre nutzen zu können musst du bereits auf einem System sein. Bist du erst auf einem System erleichtert/verkürzt Meltdown/Spectre ggf. die Arbeit. Ein passender Exploit für eine Datenbankanwendung könnte aber auch schneller sein. xD

In der Theorie war solch ein Angriff schon unmittelbar nach Veröffentlichung der CPUs denkbar. Die NSA, Russen und Chinesen kauften in den 90ern und 00er Jahren trotzdem fleissig Intel CPUs bis Snowden um die Ecke kam.

[StefanV]

Warum? Weil du zwischen einem bekannten Hack (Equifax) und der Intel Lücke(n) einen Zusammenhang hergestellt hast der nachweislich nicht existiert:

https://blogs.apache.org/foundation/entry/apache-struts-statement-on-equifax

Das kann man jetzt als Ignoranz, wissentliche Verbreitung falscher Nachrichten, Dummheit oder Besserwisserei bezeichnen. Was dahinter Steckt weisst nur du. :D
9JRLCBb7qK8
;-)


Niemand hier, denke ich, lässt den Gedanken außer acht, dass das bereits genutzt worden sein könnte. Allerdings wäre dies im Zweifel eben nicht nachweisbar. Was ja das "tolle" an dieser Lücke ist. Lediglich die Lücke die dem Hacker half auf das System zu gelangen ist ggf. nachweisbar. Außer der/die Hacker haben das Programm und den dazugehörigen Dump zurückgelassen.
genau das ist das Problem. Also im Zweifel könnte an meiner Verschwörungstheorie was dran sein ;)


Gleichwohl musst du aber auch erkennen, dass diese Lücke nicht von ein paar Hackern mit ein paar Computern gefunden werden konnte (außer in der Theorie). Sprich: Know-How, Technik und Zeit eine wesentliche Rolle gespielt haben (die brauchten ein halbes Jahr). In dieser Liga spielen wohl eher nur staatliche Stellen (oder Grosskonzerne mit Interesse).
Ja, richtig.
Nur gibt es eben auch einen Kriminellen Markt für solche Lücken. Gerade auch wenn man das (ggF mit Geduld) auch auf größere Brocken wie z.B. Equifax anwenden könnte...
Ist halt die Frage, ob sich das die entsprechenden Betriebe leisten könnten oder wollten.

[Exxtreme]

Ja, richtig.
Nur gibt es eben auch einen Kriminellen Markt für solche Lücken. Gerade auch wenn man das (ggF mit Geduld) auch auf größere Brocken wie z.B. Equifax anwenden könnte...
Ist halt die Frage, ob sich das die entsprechenden Betriebe leisten könnten oder wollten.
Bei Equifax sind die Hacker über eine Lücke eingedrungen die bekannt und längst gefixt war. Nur hätten die Webmaster dort den Fix auch einspielen müssen. Was sie wochenlang nicht gemacht haben.

[vanquish]

genau das ist das Problem. Also im Zweifel könnte an meiner Verschwörungstheorie was dran sein ;)
Nope. Nicht in Bezug auf das von dir genannte konkrete Beispiel Equifax. Genau darauf wurde jetzt mehrfach eingangen. Dies wurde/wird von dir gekonnt ignoriert. Irgendwelche anderen Verschwöhrungstheorien kannst du gerne im WWW verbreiten. Bis sie dir möglicherweise wieder jemand wiederlegt. Aber Verschwöhrungstheoretiker hält auch das nicht ab. Gibt ja auch heutzutage noch Leute die Raketen bauen um zu beweisen, dass die Erde eine Scheibe ist.

[Gorkon]

Ach deswegen nicht soooooo viel Leistungsverlust...dann ist ja alles klar :freak: (bitte nicht zu ernst nehmen ;))

http://blog.fefe.de/?ts=a485e7ee

Mir wird gerade ein Gerücht zugetragen, das ich hier mal unverifiziert weitergebe.
Und zwar soll Intel das Microcode-Update zurückgezogen haben, nicht weil es zu Crashes kommt, sondern weil der Microcode zu Überhitzungen führt, die sogar den Sockel beschädigen können. Die "unexpected reboots" in der Intel-Pressemitteilung sind laut dieses Gerüchtes dann nicht "oh hups ich boote mal" sondern ein "ach du Scheiße der Prozessor ist viel zu heiß, Not-Aus". Der Prozessor soll bei der Stelle aber schon über 150% des TDP gezogen haben. Angeblich soll das bei Amazon in der Cloud schon zu Hardware-Ausfällen geführt haben.

Wow, das würde erklären, wieso Intel die Updates so hastig zurückgezogen hat.

[aufkrawall]

Ein bisschen sehr viel Spekulatius, wann in der Realität würden CPUs ohne Drosselung denn großartig oberhalb ihrer TDP ziehen?
Edit: Ok, Server vielleicht.

Ausschließen kann mans natürlich nicht. Bei meinem Bruder mit ASRock Z87 Board bringt die Uefi-Erkennung eines neuen OS (also etwa nach Windows-Neuinstallation) reproduzierbar komplett die Temperaturüberwachung der CPU aus dem Tritt, sodass der Lüfter nicht höher dreht und das Teil irgendwann bei ~100°C in die Drosselung läuft. Man muss das Board dann vom Netz nehmen, damit es wieder funktioniert.

[Razor]

So ein quatsch... echt jetzt?
Demnächst werden Beschwörungen wieder IN sein, "Spectre" vom Rechner fern zu halten :rolleyes:

Razor

[Pirx]

wird sowieso verdächtig still um die Sache

[Der_Korken]

Ach deswegen nicht soooooo viel Leistungsverlust...dann ist ja alles klar :freak: (bitte nicht zu ernst nehmen ;))

http://blog.fefe.de/?ts=a485e7ee

Das würde auch den Namen "Meltdown" erklären :upara:

;D

[Opprobrium]

wird sowieso verdächtig still um die Sache
Wird es doch immer wenn abstrakte Sicherheitslücken auftauchen die sowieso niemand versteht. Wird schon schiefgehen, irgendwer wird sich schon drum kümmern. Bis dann halt das nächste WannaCry kommt. Dann gibt es wieder halbgare Sicherheitstipps in den Mainstream Medien, mahnende Worte von Politikern über Medienkompetenz und Neuland, große Weltverschwörungen werden ausgepackt etc. Bis dann wieder rauskommt, daß irgendwelche Teenager aus Versehen ganze Länder stillgelegt haben, weil sie ihren Zockerrivalen eins auswischen wollten oder so. :rolleyes:

[vanquish]

Still würde ich nicht sagen, gibt doch Nachrichten:

Update 05.02.2018 09:37 Uhr
Für den ersten NUC auf Basis von Apollo Lake und die Compute Card hat Intel zum Ende der letzten Woche die ersten neuen Microcodes ausgerollt. Diese sind nun die ersten, weil eben dort bereits ein fehlerhaftes BIOS veröffentlicht und später zurückgezogen wurde. Ansonsten ist insbesondere die NUC-Übersichtsseite zu den Updates noch extrem übersichtlich, 90 Prozent sind im Status TBD (to be defined) – sie kommen irgendwann.

Update 08.02.2018 08:59 Uhr
Intel hat nun die ersten aktualisierten Microcodes für Partner bereitsgestellt. Diese sind bisher aber nur für Skylake-Systeme vorgesehen, von Notebook-CPUs bis zu Desktop-Lösungen. Weitere sind aktuell im Beta-Status verteilt worden und sollen in Kürze folgen.

Quelle computerbase.de (https://www.computerbase.de/2018-01/spectre-bios-update-reboot-problem/)

Wird also nicht mehr allzu lange dauern bis alle vorgesehenen CPUs ein bereinigtes Microcode Update erhalten haben. Windows Patches sind ausgerollt bzw. teil-deaktiviert. Für Linux bleibt noch Spectre v1 übrig, was mit 4.16 kommen soll. Spectre v2 wird noch bereinigt und neben Retpoline auch noch der Microcode-Ansatz mit eingepflegt. ARM ist in der Mache und der Rest mit 2 Jahre+ alten Androids (außer einiger Flagschiffe) und 5 Jahre+ alten CPUs bleibt auf der Strecke. Danach dürfte in der Tat Stille einkehren und alles geht wieder gewohnt seinen Gang bis zum nächsten Rekordgewinn garniert mit einer Sicherheitslücke. :D

[aufkrawall]

Mit Linux 4.15.2 (Arch) meldet spectre-meltdown-checker.sh nun " __user pointer sanitization" Mitigation für Spectre Variant 1. Also alle drei Lücken ohne Microcode-Update mitigated (was wohl nicht 100% geschlossen heißt, aber Spectre ist ja ohnehin schon nicht so leicht ausnutzbar).

Edit: Die aktuelle Version von spectre-meltdown-checker.sh warnt auch davor, wenn der zurückgezogene instabile Mikrocode genutzt wird. Arch verteilt den leider noch standardmäßig. Wahrscheinlich ist es vernünftiger, mit aktuellem Kernel den Microcode aus dem November zu verwenden:
https://archive.archlinux.org/packages/i/intel-ucode/

[Birdman]

Edit: Die aktuelle Version von spectre-meltdown-checker.sh warnt auch davor, wenn der zurückgezogene instabile Mikrocode genutzt wird. Arch verteilt den leider noch standardmäßig. Wahrscheinlich ist es vernünftiger, mit aktuellem Kernel den Microcode aus dem November zu verwenden:
https://archive.archlinux.org/packages/i/intel-ucode/
Na ja, solange man keinen Code laufen lässt welcher IBRS und Konsorten verwendet, gibts ja keine Probleme mit dem "defekten" Microcode.
Von daher ist es nicht ganz so tragisch, zumal Arch dies selber ja auch wirklich nicht nutzt.
Problematisch würde es wohl erst, wenn man da irgendwas virtualisiert und das Guest-OS (z.B. Windows) die Befehle dann nutzt.

[Loeschzwerg]

http://blog.global.fujitsu.com/mainframes-mainly-unmoved-threat-spectre-meltdown/

In the specific case of Fujitsu mainframes, our BS2000 series using /390 processors are not affected by either Spectre or Meltdown. Some BS2000 Mainframes do use Intel processors. However, they are also unaffected by this security issue, since the BS2000 operating system has, by design, security features in place to protect against these types of vulnerabilities. BS2000 applications are run by special system software, provided by Fujitsu, which transforms user-created BS2000 applications into x86 programs that cannot exploit the flaws. Our BS2000 systems are therefore safe and secure even without additional security patches.

[Annator]

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf

Sandy- und Ivybridge werden doch gepatcht. (Pre-Beta)

[Dorn]

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf

Sandy- und Ivybridge werden doch gepatcht. (Pre-Beta)

Naja als ob die Notebookhersteller hier noch was machen würden, ich will retpoline.

Bei Desktop werde ich wohl nächstes Jahr auf Zen 2 wechseln.

[][immy]

https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf

Sandy- und Ivybridge werden doch gepatcht. (Pre-Beta)
Sandy steht drin, aber bei Ivy stehen nur die Mobilen-CPUs bei ... das soll doch wohl ein Witz sein.

[vanquish]

Hmm ... jetzt rudert Intel wohl zurück und "patcht" doch mehr CPUs. Die Frage ist allerdings was das bringen soll. Mein HP Notebook mit Haswell wird laut HP nicht mehr gepatcht. Selber patchen, so wie bei meinen anderen Rechnern (deren Bios auch nicht gepatcht werden), geht nicht. Das HP Bios muss ja mit einem RSA-Schlüssel signiert sein. Ich glaube kaum, dass die OEMs für Intel die Drecksarbeit finanzieren und jeden Kunden (mit "patchbaren" System identifizieren und anschreiben.

Und: Wenn ich mich abseits der Computer(nerd)welt umsehe patcht sowieso niemand aus eigenem Antrieb. Ich habe noch keinen 08/15-Anwender getroffen (weder früher noch seit dem Gau), der von alleine darauf gekommen ist sein Bios zu aktualisieren. Die denken alle, dass das Windows das alles automatisch macht. Zu allem Überfluss gibt es auch noch genug "Erfahrene Benutzer" die bereits davon abraten die Windows-Patches überhaupt zu installieren.

Ergo: Der größte Teil aller Systeme bleibt maximal "teil-gepatcht".

Das Chaos ist Intel durchaus gut gelungen. :ucrazy3:

[keats]

Edit: Folgendes funktioniert nicht. Der Microcode wird zu spät geladen und der Patch ist nicht aktiv. Siehe nachfolgende Postings.

Wenn kein Linux und wenn MS nicht doch noch die Microcodes per Update ausliefert, funktioniert zur Not der VMware Treiber:

https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver

Auf einem Lenovo-Laptop getestet. Funktioniert problemlos. (Wenn man solcher Drittsoftware traut.) Edit: Wird durch das inspectre-Tool falsch ausgelesen.

Kann jemand erklären, warum in der Tabelle von Intel teilweise unterschiedliche MC-Revisionen für Linux und Windows angegeben werden? Wenn die höchste Revision im BIOS vorhanden ist, wird das OS doch vermutlich kein Downgrade machen (können)?

[Sephiroth]

Wenn kein Linux und wenn MS nicht doch noch die Microcodes per Update ausliefert, funktioniert zur Not der VMware Treiber:

https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver

Nein der funktioniert nicht, weil der Treiber das Update "zu spät" lädt und Windows den fehlenden Microcode Support schon vorher erkennt und somit die Spectre-Schutzfunktion deaktiviert.

[keats]

Nein der funktioniert nicht, weil der Treiber das Update "zu spät" lädt und Windows den fehlenden Microcode Support schon vorher erkennt und somit die Spectre-Schutzfunktion deaktiviert.

Zumindest das inspectre-Tool zeigt den Spectre-Patch als aktiv an, wenn der Microcode über den VMware-Treiber geladen wird.

Ich schaue, dass ich den Laptop noch mal in die Hand bekomme. Vielleicht zeigt das Skript von Microsoft etwas anderes an.

Oder prüfen alle Tools nur nach der entsprechenden MC-Revision sowie ob der Patch nicht per Registry deaktiviert ist und werfen dann falsch aus, dass er aktiv ist?

[keats]

Nein der funktioniert nicht, weil der Treiber das Update "zu spät" lädt und Windows den fehlenden Microcode Support schon vorher erkennt und somit die Spectre-Schutzfunktion deaktiviert.

Du hast Recht, der Spectre-Patch ist beim mit dem VMware-Treiber geladenen Microcode nicht aktiv.

Ich habe es gerade noch mal mit dem Powershell-Skript verglichen. Ohne Microcode-Update sagt das Skript erwartungsgemäß kein Hardware-Support vorhanden, Patch wegen fehlender Hardware-Unterstützung deaktiviert. Mit Microcode-Update ist der Hardware-Support vorhanden und der Patch auch nicht wegen fehlender Hardware-Unterstützung deaktiviert. Er ist aber dennoch nicht aktiv.

Das inSpectre-Tool scheint diesen Sonderfall jedoch nicht zu verstehen und gibt falsch an, das System sei gegen Meltdown und Spectre geschützt.

Bei den Desktop-Rechnern, bei denen ich den Microcode ins BIOS gepatched habe, gibt auch das Skript erwartungsgemäß aus, dass alle Maßnahmen aktiv sind.

Ich habe das inSpectre-Tool verwendet, weil es schnell ohne Powershell gestartet ist. Aber es ist offensichtlich nicht in allen Fällen zuverlässig.

[Razor]

Hardware- und Nachrichten-Links des 10./11. Februar 2018 (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-1011-februar-2018)

Jetzt wird in den heutige News schon wieder behauptet, dass es unter Windows nicht möglich ist, den Microcode der CPU's zu patchen.
Liest denn wirklich niemand hier diesen Thread, obwohl darauf verlinkt wird?

Mann, mann, mann...
Hier noch mal mein Post zu dem Thema und ein kleiner Auszuga daraus:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11607643#post11607643

NICHT von ASUS gepatcht, sondern von mir mit einem Bios aus 2014 und ein wenig... OK, ein wenig mehr... Recherche im iNet bzw. einschlägigen Foren.
Ergo: ein Bios, welches mit dem originalen Microcode von Intel (CPUID: 306C3) gepatcht wurde und ja, es enthält den PTI Flaw Fix:
INTEL Download Linux- Processor Microcode Data File

Nette Erkenntnisse zur Seite:
- Bios uCode-Stand = 19
- Win7 uCode-Stand = 1C
- Win10 uCode-Stand = 1E
- "mein" uCode-Stand = 23
(der nun auch unter Win7/10 ausgewiesen wird)

Fazit:
- Microsoft könnte das uCode-Update auch selber integrieren, tut es aber nicht (habe sie schon getan)
- ASUS könnte auch ältere Plattformen Patchen, tun es aber nicht (ist kein großer Aufwand)
- DELL hat am 2.1.2018 (!) "sein" Update für die paar T1700 in der Firma gebracht (Ebenfalls Haswell)... vorbildlich!
(vor allem, weil die "News" erst am 3.1. begannen ;-)

Ergo: Microsoft kann Microcodes laden und haben es auch schon getan.
Aber... wollen Sie es auch?

Razor

P.S.: mein Haswell ist noch immer brutal stabil mit dem genannten Microcode-Stand, der mittlerer Weile von Intel zurück gezogen wurde.
Habe ich wohl "Glück" gehabt, oder?

[Monsta]

Ich habe nun den 4.16 rc1 Kernel drauf und mit GCC 7.3 übersetzt.

Ich habe kein Microcodeupdate geladen.

Mein System ist jetzt gegen alle Varianten gesichert.

https://i.imgur.com/Y3vTw1c.png

[Ganon]

Nur zur Verdeutlichung: Dein Kernel ist gegen alle 3 Varianten gesichert. Das heißt aber nicht, dass jetzt auch Spectre Angriffe im Userspace unmöglich sind. Dazu muss auch die Userspace-Software entsprechend neu kompiliert und ggf. in Teilen angepasst werden.

[Monsta]

Den Chromium habe ich neu übersetzt. Das ist in meinen Augen auch die wichtigste Anwendung.
Das ganze System neu zu übersetzen ist dauert mir zu lange, aber durch updates werde ich früher oder später alles mit dem neuen Compiler übersetzt haben :)

[Ganon]

Entsprechende CFLAGS müssen natürlich auch gesetzt sein. Einfach "nur" den neuen Compiler nutzen bringt dazu erst mal gar nichts. Aber jetzt einfach global für alles setzen bringt auch nicht so viel.

Das wird allgemein noch länger dauern bis alle Projekte die Standard-Flags alle korrekt gesetzt haben.

[Hübie]

Kurze Frage: Ivy Bridge ist nicht betroffen oder wie? Habe eben mal power shell skript laufen lassen und da steht:

Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True

BTIHardwarePresent : False
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False

Endlich mal ein Vorteil alter Gammelhardware. ;D;D

[iuno]

Natuerlich ist Ivy Bridge betroffen. Eine Mitigation ist sowas wie ein workaround oder das Abschwaechen das Problems und dafuer liegt bei dir entsprechend logischerweise kein Hardwaresupport vor.

[Hübie]

Ach so. Kann man das auch wieder abschalten und gegen die Performance eintauschen? :D

[unl34shed]

Aktuell ist der Patch bei dir nicht aktiv, da das µCode Update, das über ein neues BIOS eingespielt wird bei dir fehlt und du daher noch kein Hardware Support für den Workaround hast.

Ja, Deaktivieren kann man die Patches, wenn sie dann aktiv sind, aber ob das sinnvoll ist?

[Hübie]

Ach so läuft das. Ok. Ich habe mich zugegebenermaßen gar nicht viel mit dem Thema beschäftigt, da ich meine Zockermaschine nicht als potenzielles Ziel solcher Attacken betrachte. Da will ich maximale Performance. :naughty:

Sind mittlerweile derartige Angriffe bestätigt? Mein letzter Stand war offiziell ein Nein (was ja nicht die Wirklichkeit spiegeln muss, wenn wir an Geheimdienste denken).

[Birdman]

Sind mittlerweile derartige Angriffe bestätigt? Mein letzter Stand war offiziell ein Nein.
Spectre gibts afaik (noch) nicht "in the wild", Meltdown jedoch schon. Letzteres ist aber halt auch viel einfacher und vor allem generischer auszunutzen.

[aufkrawall]

Na super, die Microcode-Lösungen haben ja lange gehalten:
https://www.heise.de/security/meldung/MeltdownPrime-SpectrePrime-Neue-Software-automatisiert-CPU-Angriffe-3970686.html

Closed Source ist ja so sicher...

[iuno]

Ach so. Kann man das auch wieder abschalten und gegen die Performance eintauschen? :D
Du kannst alles machen, was du mit deinem Gewissen vereinbaren kannst. Hast du denn ueberhaupt Nachteile bemerkt seither?

[TGKlaus]

Hast du denn ueberhaupt Nachteile bemerkt seither?

Wie bitte soll er denn was bemerken, wenn auf Grund des fehlenden Micro-Code der Patch gar nicht aktiv ist? :confused:

[Gorkon]

Na super, die Microcode-Lösungen haben ja lange gehalten:
https://www.heise.de/security/meldung/MeltdownPrime-SpectrePrime-Neue-Software-automatisiert-CPU-Angriffe-3970686.html

Closed Source ist ja so sicher...
Spricht eigentlich nur noch weiter für Retpoline bzw. auf lange Sicht neue µArch.

[vanquish]

Edit: Folgendes funktioniert nicht. Der Microcode wird zu spät geladen und der Patch ist nicht aktiv. Siehe nachfolgende Postings.

Wenn kein Linux und wenn MS nicht doch noch die Microcodes per Update ausliefert, funktioniert zur Not der VMware Treiber:

Man kann aber GRUB bzw. eine darauf basierende Version aka "Intel BIOS Implementation Test Suite" (BITS) dazu missbrauchen. Allerdings muss man diesen "Bootloader" auf einem USB-Stick bei jedem Boot im PC stecken haben und manuell (über zwei Menüeinträge) den aktuellen Microcode laden um anschließend Windows mit aktualisiertem Microcode starten zu können. Ich könnte mir durchaus vorstellen, dass man das über GRUB irgendwie automatisieren kann und das bei jedem Boot automatisch gemacht wird. Ist zwar etwas umständlich aber besser als nichts.

Quelle: Heise.de (https://www.heise.de/forum/heise-online/News-Kommentare/FAQ-zu-Meltdown-und-Spectre-Was-ist-passiert-bin-ich-betroffen-wie-kann-ich-mich-schuetzen/Loesung-fuer-Microcode-Updates-auf-aelteren-Windows-PCs-ohne-BIOS/posting-31667941/show/)

[Hübie]

Du kannst alles machen, was du mit deinem Gewissen vereinbaren kannst. Hast du denn ueberhaupt Nachteile bemerkt seither?

Wie TGKlaus schon anmerkt ist der Patch bei mir nicht aktiv, aber mit UEFI und Windows Aktualisierung wird es früher oder (eher) später eintreffen. Will jedoch keine Performance verlieren. Das UEFI würde ich freilich auch nur aktualisieren, wenn es wirklich mehr zu bieten hat, als Md+S Patch.
Und was meinst du mit "deinem Gewissen vereinbaren"? Ich will niemanden verprügeln oder so. :| So ein Schadcode kommt nicht durch Magie auf ein System und selbst wenn: Es ist ein Zocker-PC. Was soll da passieren? Einen roten Knopf für Atomwaffenstarts habe ich hier jedenfalls nicht und auch sonst würde ich bemerken wenn hier was faul ist.

[aufkrawall]

Will jedoch keine Performance verlieren.
Wenn man den ganzen Tag SSD-Benchmarks laufen lässt, ist das natürlich problematisch...

[Hübie]

Mir geht's ums Zocken. ;) Hat da jemand mal einen probaten Praxistest? Am besten mit Frameverläufen. Finde so etwas nicht.

[aufkrawall]

Manche Spiele-Engines mögen die Spectre-Mitigations von OS + Microcode wohl nicht, wenn es um Streaming geht. DF haben einen Drop von ~10% bei W3 in Novigrad festgestellt.
Trotzdem wär es dämlich, keine Schutzmaßnahmen gegen Lücken zu ergreifen, die gerade bis zum Erbrechen auf Ausnutzbarkeit hin erforscht werden.

Man sollte nicht vergessen, dass es (auf der PC-Plattform) nur Intel dermaßen verkackt hat. Meltdown gibts bei AMD nicht und Spectre ist dort hinsichtlich der Ausnutzbarkeit wohl immer noch so schwierig, dass es für den Endnutzer nach derzeitigem Wissensstand wohl keine Rolle spielen wird. Also vielleicht das nächste Mal weniger unsichere Hardware kaufen...

[keats]

Man kann aber GRUB bzw. eine darauf basierende Version aka "Intel BIOS Implementation Test Suite" (BITS) dazu missbrauchen. Allerdings muss man diesen "Bootloader" auf einem USB-Stick bei jedem Boot im PC stecken haben und manuell (über zwei Menüeinträge) den aktuellen Microcode laden um anschließend Windows mit aktualisiertem Microcode starten zu können. Ich könnte mir durchaus vorstellen, dass man das über GRUB irgendwie automatisieren kann und das bei jedem Boot automatisch gemacht wird. Ist zwar etwas umständlich aber besser als nichts.

Quelle: Heise.de (https://www.heise.de/forum/heise-online/News-Kommentare/FAQ-zu-Meltdown-und-Spectre-Was-ist-passiert-bin-ich-betroffen-wie-kann-ich-mich-schuetzen/Loesung-fuer-Microcode-Updates-auf-aelteren-Windows-PCs-ohne-BIOS/posting-31667941/show/)

In dem Thread bei Heise hatte jemand schon einen Vorschlag, um es zumindest teilweise zu automatisieren.

https://www.heise.de/forum/heise-online/News-Kommentare/FAQ-zu-Meltdown-und-Spectre-Was-ist-passiert-bin-ich-betroffen-wie-kann-ich-mich-schuetzen/Re-Loesung-fuer-Microcode-Updates-auf-aelteren-Windows-PCs-ohne-BIOS/posting-31722531/show/

Ich kannte das bisher nicht und finde es ganz interessant. Für mich selbst würde ich es im Zweifelsfall nutzen.

[Hübie]

Manche Spiele-Engines mögen die Spectre-Mitigations von OS + Microcode wohl nicht, wenn es um Streaming geht. DF haben einen Drop von ~10% bei W3 in Novigrad festgestellt.
Trotzdem wär es dämlich, keine Schutzmaßnahmen gegen Lücken zu ergreifen, die gerade bis zum Erbrechen auf Ausnutzbarkeit hin erforscht werden.

Man sollte nicht vergessen, dass es (auf der PC-Plattform) nur Intel dermaßen verkackt hat. Meltdown gibts bei AMD nicht und Spectre ist dort hinsichtlich der Ausnutzbarkeit wohl immer noch so schwierig, dass es für den Endnutzer nach derzeitigem Wissensstand wohl keine Rolle spielen wird. Also vielleicht das nächste Mal weniger unsichere Hardware kaufen...

Witzbold. Als Ivy heraus kam wusste die Welt hier draußen nix von Meltdown und Spectre. Was dämlich ist und was nicht entscheidest zum Glück auch nicht du. Somit ist alles nach dem Satz von Novigrad geflame / getr0lle.

Ps: Wer weiß was in 5-6 Jahren bei AMD für Sicherheitslücken heraus kommen. Ich maße mir da jedenfalls kein Urteil an.