Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren

[Sven77]

Dann erklär mal den 6er im Lotto wie er technisch ablaufen sollte ohne das man dies merkt.. da sind alle INTEL ME und AMD PSP Bug/Lücken viel schlimmer.. die gehen dann am OS Stack wirklich vorbei. Da hast du keine Chance. Letzer Post von mir zu dem Thema, ausser ne Technisch schlüssige und sinnvolle Erklärung inkl. Timeline kommt.

Die ganze Geschichte ist zu hoch für ihn, das sollte man ihm nachsehen.

[joe kongo]

Ich warte ab, ob Asus fürs Z87-A ein Bios Update herausgibt.
Erwarten tu ichs mir nicht, Asus hat dort schon einen (bekannt) defekten
ASIC (PCIe-PCI Bridge) verbaut bei dem als Workaround Interrupts gepollt werden (:ucrazy2:), scheint deren Firmenpolitik zu sein.

[Pirx]

Die ganze Geschichte ist zu hoch für ihn, das sollte man ihm nachsehen.
na dann erkläre du doch mal die "ganze Geschichte" und dann werden wir mal beurteilen, auf welchem Niveau du dich einordnest

[Timbaloo]

Wer glaubt, dass intel dieses Verhalten in ihre µArch eingepflanzt hat nur damit die NSA einfacheren Zugriff hat, der sollte schleunigst zum Psychiater.

[Lord Wotan]

Wie ja schon gesagt wurde: Rein technisch könnte Microsoft, genauso wie Linux es ja tut, das nötige Microcode Update von Intel und AMD (auch wenn hier möglicherweise nicht wirklich nötig) alleine ausliefern. Warum sie es nicht tun, keine Ahnung.

Hast du mal einen Link das Linux die Intel Firmwarecodes einspielt und das damit ein Bios Update überflüssig wird?

[Sven77]

na dann erkläre du doch mal die "ganze Geschichte" und dann werden wir mal beurteilen, auf welchem Niveau du dich einordnest
Wer glaubt, dass intel dieses Verhalten in ihre µArch eingepflanzt hat nur damit die NSA einfacheren Zugriff hat, der sollte schleunigst zum Psychiater.

Exakt das, er schwadroniert ja nicht nur hier auf Chemtrail-Niveau

[Gipsel]

Können wir bitte beim Thema und sachlich bleiben?

Danke.

[Ganon]

Hast du mal einen Link das Linux die Intel Firmwarecodes einspielt und das damit ein Bios Update überflüssig wird?

http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/intel-microcode_3.20171215.1_changelog


intel-microcode (3.20171215.1) unstable; urgency=high

* Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
New upstream microcodes to partially address CVE-2017-5715
+ Updated Microcodes:
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
* Implements IBRS and IBPB support via new MSR (Spectre variant 2
mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
* LFENCE terminates all previous instructions (Spectre variant 2
mitigation, conditional branches).


Ob ein BIOS Update damit 100%ig unnötig wird, steht aber auch bei mir noch im Raum. Zumindest das fett markierte ist wohl das, was das "BIOS-Update" bringt und nach dem Microcode-Update funktioniert das wohl auch. Ob ein BIOS Update noch mehr macht, weiß ich nicht, aber zumindest sind mir nicht mehr Änderungen bekannt, die nötig sind.

Alles im konjunktiv, weil das Microcode Update aktuell wohl nur über "geheime" Kanäle verteilt wird und es auf den normalen Download-Quellen von Intel nicht zu finden ist. Somit muss auch ich noch warten bis Intel es komplett öffentlich macht und meine Distribution auf dem Notebook (ArchLinux) und mein Server-OS (FreeBSD) es aufnehmen kann. Somit habe ich aktuell keine persönlichen Erfahrungen damit.

[nonharderware]

Zu den Verschwörungstheorien:

Hinken wie die einbeinige Spinne.

Die hinken in meinen Augen sogar immer mehr, je länger man darüber nachdenkt...
Auch in den acht Augen der einbeinigen Spinne welche, noch immer hinkend, gerade noch eben mit zig anderen einbeinigen Freunden ein Netz webend, sich genüsslich an einer gefangenen Fliege labt.

[Fusion_Power]

Also zu meinem Asus Z170i scheints noch kein Bios Update zu geben, das letzte gelistete auf dr Homepage ist vom 21.7.2017, mein installiertes noch älter. Ja, ich installier nicht gerne BIOSe weil die bei meinem Mainboard immer prinzipiell alle Einstellungen zurück setzen. ^^
Ansosnten gibts wohl nur noch einen ME Patch von Asus, keine Ahnung ob ich den bauch, hab die ME vllt. nicht mal installiert (?).

[nonharderware]

Also zu meinem Asus Z170i scheints noch kein Bios Update zu geben, das letzte gelistete auf dr Homepage ist vom 21.7.2017, mein installiertes noch älter. Ja, ich installier nicht gerne BIOSe weil die bei meinem Mainboard immer prinzipiell alle Einstellungen zurück setzen. ^^
Ansosnten gibts wohl nur noch einen ME Patch von Asus, keine Ahnung ob ich den bauch, hab die ME vllt. nicht mal installiert (?).

Schau mal hier:

Das nächste Problem kommt ja erst noch, wenn unsere Boards nicht alle ein Bios-Update bekommen.

Das ist der Stand von Asus jetzt: https://www.asus.com/News/V5urzYAT6myCC1o2

Mein Board (X99E-WS) ist bis jetzt nicht dabei und alle noch älteren Sockets taucht da noch gar nicht erst auf. Das wird noch lustig ... :(

Meines (Z170 Premium) ist mit einer neuen Version aufgelistet, diese finde ich aber noch nicht zum Download.

[Sephiroth]

http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/intel-microcode_3.20171215.1_changelog



Ob ein BIOS Update damit 100%ig unnötig wird, steht aber auch bei mir noch im Raum. Zumindest das fett markierte ist wohl das, was das "BIOS-Update" bringt und nach dem Microcode-Update funktioniert das wohl auch. Ob ein BIOS Update noch mehr macht, weiß ich nicht, aber zumindest sind mir nicht mehr Änderungen bekannt, die nötig sind.

Alles im konjunktiv, weil das Microcode Update aktuell wohl nur über "geheime" Kanäle verteilt wird und es auf den normalen Download-Quellen von Intel nicht zu finden ist. Somit muss auch ich noch warten bis Intel es komplett öffentlich macht und meine Distribution auf dem Notebook (ArchLinux) und mein Server-OS (FreeBSD) es aufnehmen kann. Somit habe ich aktuell keine persönlichen Erfahrungen damit.
Gentoo hat es auch schon -> https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-firmware/intel-microcode?id=e6ea9dcb23142a268cef722793a408071677d6b1
The CPU microcode for Intel Haswell-X, Skylake-X and Broadwell-X
chipsets was updated to report both branch prediction control via CPUID
flag and ability to control branch prediction via an MSR register.
und hier der DL-Link zu den microcode-quellen ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo/distfiles/microcode-20171117_p20171215.tgz
Intel Processor Microcode Package for Linux
20171117_p20171215 Release
-- Updates --
HSX C0 (06-3f-02:6f): 3a -> 3b
BDX-ML B0/M0/R0 (06-4f-01:ef): b000021 -> b000025
SKX H0 (06-55-04:97): 2000035 -> 200003a

ggü. release 20171117 sind auch drei neue files mit stand 15.12.2017 13:59 enthalten

edit:
Nur Haswell-X, Skylake-X and Broadwell-X? Das klingt etwas wenig, da fehlen doch die ganzen normalen Modelle. ???

[eratte]

Da steht nicht umsonst oben drüber:

We recommend customers update their systems by downloading and applying the latest BIOS, as soon as the relevant revision becomes available.

[Ganon]

Gentoo hat es auch schon

Danke für die Links. Das Paket sieht mir etwas seltsam aus. Er bezieht die ucodes nicht mehr von Intels Servern, sondern von Gentoo-Mirrors. Die verlinkten (auskommentierten) Quellen zeigen alle auf das alte Update 20171117 mit gleicher Prüfsumme, als wenn ich das ursprüngliche Paket nehme.

Ich lass davon erst mal noch die Finger und warte bis es da ist, wo es sonst auch immer war. Eigentlich sollte der Kram ja auch erst später rauskommen.

[kunibätt]

Kann mir jemand bitte kurz und knapp erklären was man als Besitzer eines 2600K jetzt dagegen tun kann?

[Annator]

Kann mir jemand bitte kurz und knapp erklären was man als Besitzer eines 2600K jetzt dagegen tun kann?

Windows updaten und hoffen, dass irgendwann ein Bios Update oder Microcode Update über Windows kommt.

[maguumo]

OS aktuell halten damit KPTI genutzt wird, Software aktuell halten damit Spectre möglichst wenig Angriffsfläche geboten wird. Das wars wenn ich das richtig verstanden habe. Ich weiß nicht ob der Kram vor Skylake auch BIOS/UEFI Updates bräuchte, aber das ist ja eigentlich eher eine akademische Frage, selbst bei Haswell wird es da wohl größtenteils nichts mehr geben.

[TGKlaus]

Zu den Verschwörungstheorien:

Die hinken in meinen Augen sogar immer mehr, je länger man darüber nachdenkt...

Ganz im Gegenteil.
Sollte auch nur ein Funke Wahrheit in den Aussagen zu 2014 und TU Graz sein.
Gepaart mit der Tatsache das Meltdown keine verfolgbaren Spuren hinterläßt.
Muss man fast schon zwingend von einem Tatverdacht ausgehen!

[Complicated]

AMD PSP Bug/Lücken viel schlimmer.. die gehen dann am OS Stack wirklich vorbei.
Ebenso wie dieser Bug wenn man z.B. TSX dafür ausnutzt. Dies haben Forscher im August 2016 auf der Blackhat demonstriert. Der Link dazu ist hier im Thread zu finden.

Dennoch hast du natürlich recht, dass Lücken in der ME oder PSP (die im Gegensatz zur ME abschaltbar ist wer es sicher haben will (https://www.heise.de/newsticker/meldung/AMD-Secure-Processor-PSP-wohl-bei-einigen-Ryzen-Mainboards-abschaltbar-3913635.html)) für die NSA interessanter sind. Allerdings ist die Aussage der NSA nichts davon gewusst zu haben, während Dutzende von Forschern das schon publiziert haben, kaum glaubwürdig. Selbst Microsoft hat schon darauf verlinkt in 2016.

[nonharderware]

Ganz im Gegenteil.
Sollte auch nur ein Funke Wahrheit in den Aussagen zu 2014 und TU Graz sein.
Gepaart mit der Tatsache das Meltdown keine verfolgbaren Spuren hinterläßt.
Muss man fast schon zwingend von einem Tatverdacht ausgehen!

Welche Aussagen? Bitte um Quellen.

Ich halte diese Verschwörungstheorien zwecks Hardware-Hintertür(en) dennoch für Blödsinn, da sie ja nicht nur der NSA (oder welchem Urheber auch immer) offen steht/stehen, sondern so ziemlich jedem anderen (feindlichen) Nachrichtendienst.
Und Überläufer/Doppelagenten gibt es immer.

[Ex3cut3r]

Ich glaube auch wenn ein Bios Update kommt fürs Z87 G45 Gaming, (was ich aber nicht glaube) werde ich es vermutlich nicht installieren, mein 4770k ist schon langsam genug, aber nochmal -20% nöööööö! Soll die Hacker meine Penis Bilder klauen, ist mir egal....:biggrin:

[Dicker Igel]

Pass lieber auf den Penisseiten auf, dann ist das alles halb so wild :D

[lumines]

Pass lieber auf den Penisseiten auf, dann ist das alles halb so wild :D

Wäre schön, wenn es so einfach wäre. Brain 2.0 ist hier leider wirkungslos.

[Ex3cut3r]

Pass lieber auf den Penisseiten auf, dann ist das alles halb so wild :D

Was? Was soll ich da? Die Quali ist viel zu schlecht, da erkenn ich nix, -> 1080p Download. Manchmal auch schon 4K. :biggrin:

[Dicker Igel]

:D

lumines,
dann erläutere mir doch mal bitte die Gefahren, denen ich jetzt ausgesetzt bin und warum das die ganze Zeit gut gelaufen ist? Imo weiß es jetzt durch die ganze Aufregung auch der letzte Hinterhofhacker, aber ansonsten?

[Lord Wotan]

Dann erklär mal den 6er im Lotto wie er technisch ablaufen sollte ohne das man dies merkt..
https://motherboard.vice.com/de/article/59wykx/meltdown-und-spectre-was-ihr-jetzt-uber-die-gefahrlichen-sicherheitslucken-wissen-musst

Auszug


Im Gegensatz zu anderen Hacks, bei denen Daten gestohlen werden, bleibt ein Angriff über "Meltdown" und "Spectre" unbemerkt – die Angreifer hinterlassen keine Spuren.


Hier wird das besser beschrieben
https://www.golem.de/news/memory-leak-bug-in-intel-cpus-ermoeglicht-zugriff-auf-kernelspeicher-1801-131938.html

[lumines]

lumines,
dann erläutere mir doch mal bitte die Gefahren, denen ich jetzt ausgesetzt bin

Konkrete Gefahr für Privatanwender: Ohne Patches können JS-Skripte den Speicher deines Rechners auslesen. Ansonsten ein paar Seiten zurückblättern.

Vielleicht auditierst du auch jedes JS-Skript, das du ausführst. Ich kenne ja nicht deine Herangehensweise ans Web oder generell deine Computernutzung. Bisher ist man aber generell davon ausgegangen, dass man bestimmten Code isolieren konnte. Darauf basiert irgendwie alles, was wir so am Rechner machen. Meltdown & Spectre zeigen aber, dass das nicht unbedingt der Fall ist.

und warum das die ganze Zeit gut gelaufen ist?

Weil es keine bekannte Lücke war.

Es läuft nie gut, weil unsere Software / Hardware keine Lücken hat, sondern weil in der Vergangenheit die jeweiligen Lücken einfach nicht bekannt waren. Software (und scheinbar auch unsere Hardware) ist immer fundamental fehlerbehaftet.

Stichworte für Interessierte an der Theorie: Gödelscher Unvollständigkeitssatz, Halteproblem, Entscheidungsprobleme

Imo weiß es jetzt durch die ganze Aufregung auch der letzte Hinterhofhacker, aber ansonsten?

Was heißt "ansonsten"? Nur so aus Interesse, aber hast du da einen konkreten Fall im Sinn, der dir noch schlimmer erscheinen würde?

[TGKlaus]

Welche Aussagen?


Ich rede hiervon:

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11596839&postcount=844


Außerdem rede ich nicht davon, das das absichtlich als Lücke eingebaut wurde, sondern das diese Lücke offensichtlich seit zig Jahren bekannt ist und nicht beseitigt wurde. Nicht hardwaremäßig. Noch nicht mal softwaremäßig / Bios.

Und selbst wenn man daran glauben möchte, das INTEL erst seit Juni 2017 davon weis, besteht bei der Einführung von Kaby Lake Vorsatz!!!

[Complicated]

Im Gegensatz zu anderen Hacks, bei denen Daten gestohlen werden, bleibt ein Angriff über "Meltdown" und "Spectre" unbemerkt – die Angreifer hinterlassen keine Spuren.
Keine Spuren ist falsch. Und das steht auch nicht in dem verlinkten Golem Artikel drin.

Es wird lediglich in den traditionellen Logfiles kein Eintrag hinterlassen, wie die Researcher schreiben. Das muss man wirklich unterscheiden.
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

Additionally, at least on the Intel machine on which this was tested, bouncing modified cache lines between cores is slow, apparently because the MESI protocol is used for cache coherence [8]. Changing the reference counter of an eBPF array on one physical CPU core causes the cache line containing the reference counter to be bounced over to that CPU core, making reads of the reference counter on all other CPU cores slow until the changed reference counter has been written back to memory. Because the length and the reference counter of an eBPF array are stored in the same cache line, this also means that changing the reference counter on one physical CPU core causes reads of the eBPF array's length to be slow on other physical CPU cores (intentional false sharing).

Avoiding and Identifying False Sharing Among Threads
https://software.intel.com/en-us/articles/avoiding-and-identifying-false-sharing-among-threads

Intel PTU comes with predefined profile configurations to collect events that will help to locate false sharing. These configurations are "Intel® Core™ 2 processor family – Contested Usage" and "Intel® Core™ i7 processor family – False-True Sharing." Intel PTU Data Access analysis identifies false sharing candidates by monitoring different offsets of the same cacheline accessed by different threads. When you open the profiling results in Data Access View, the Memory Hotspot pane will have hints about false sharing at the cacheline granularity, as illustrated in Figure 2.
Es ist nur extrem Aufwendig die Spuren zu verfolgen.

[Dicker Igel]

Konkrete Gefahr für Privatanwender: Ohne Patches können JS-Skripte den Speicher deines Rechners auslesen.
Ok.

Weil es keine bekannte Lücke war.
Warum macht man das dann so dermaßen bekannt? Nur weil man großen Herstellern vorm Bug scheißen kann? Das Prinzip(A hat Mist gemacht, A muss es ausbügeln) ist mir klar, die Handhabung aber nicht. Aber das ist wohl Teil unserer kranken Gesellschaft.

"Ansonsten" war ironisch gemeint.

[Lord Wotan]

Hier eine News das Microsoft bei AMD den Rechner lahmlegt.
https://www.heise.de/security/meldung/Meltdown-und-Spectre-Update-fuer-Windows-10-legt-einige-PCs-lahm-3935460.html

[StefanV]

Warum macht man das dann so dermaßen bekannt? Nur weil man großen Herstellern vorm Bug scheißen kann?
Weil der große Hersteller das ganze grotten schlecht gehändelt hat und es Anzeichen gibt, dass dieses schon seit langer Zeit bekannt war.

Und wen 'nur die anderen' betroffen wären, was glaubst du, was es dann für einen Trara gegeben hätte?!
Das traurige ist, dass das immer noch von vielen Leuten runtergespielt und kleingeredet wird, obwohl das schon ein richtig übler Bock war, der hier geschossen wurde...

Und eben auch, damit jeder sein System fixt, so gut es geht. Aber das werden viele wie immer nicht machen, weil sie ganz doll und fest glauben, dass ihnen nix passieren kann...

[lumines]

Warum macht man das dann so dermaßen bekannt? Nur weil man großen Herstellern vorm Bug scheißen kann? Das Prinzip(A hat Mist gemacht, A muss es ausbügeln) ist mir klar, die Handhabung aber nicht. Aber das ist wohl Teil unserer kranken Gesellschaft.

"Ansonsten" war ironisch gemeint.

Aus Nutzersicht ist es sehr viel besser Bugs und Sicherheitslücken einfach ohne Vorankündigung zu veröffentlichen, wenn die Unternehmen es nicht schaffen das in einem normalen Zeitrahmen zu fixen. Dieses koordinierte Veröffentlichen von Sicherheitslücken ist ja keine Verpflichtung, auch wenn einige Unternehmen das als "moralisch korrekte" Veröffentlichung versuchen zu etablieren.

Stell dir vor, was passieren würde, wenn die meisten Unternehmen bestimmen könnten, wann welche Sicherheitslücke veröffentlicht werden dürfte. Einige Lücken wären so Jahre offen (oder für immer) und es ist nicht unwahrscheinlich, dass die dann auch von anderen Parteien unabhängig davon gefunden und vielleicht auch ausgenutzt werden.

[Lord Wotan]

Hier mal ein Radiointerview mit Dr. Daniel Gruss der den Bug gefunden hat.
http://podcast-mp3.dradio.de/podcast/2018/01/06/flickarbeit_wie_die_industrie_auf_die_dlf_20180106_1644_4fd28131.mp3

[Dicker Igel]

Stell dir vor, was passieren würde, [...]
Das meinte ich ja. Normalerweise könnte man als Anwender ja erwarten, dass die Hersteller sowas zeitnah beheben und dass das nicht erst durch die gesamte Medienwelt wandern muss, damit überhaupt was passiert. Und seien wir mal ehrlich, dadurch, dass sich das über CPU-Generationen zieht, wird man gar nicht alles patchen können und nicht jeder wird sich jetzt dadurch hinsetzen und das "igendwie manuell fixen" - oder sich 'ne AMD-Kiste zusammenbauen.


Stefan,

welcher Hersteller ist mir egal, mir gehts da nur ums Prinzip.

[Lord Wotan]

So jetzt wird die Geschichte richtig LUSTIG.
http://nvidia.custhelp.com/app/answers/detail/a_id/4611

[Complicated]

Wieso?
Weil Nvidia zu den ersten nach den Browser Herstellern gehört die Fixes für ihre Software anbieten?
NVIDIA is providing an initial security update to mitigate aspects of Google Project Zero’s January 3, 2018 publication of novel information disclosure attacks that combine CPU speculative execution with known side channels.Da müssen alle anderen erst mal nach ziehen. Irgendwie ist diese Panikmache von dir schon sehr seltsam. Hier ist zumindest mal was für Spectre -1. Das geht keines der OS-Patches bisher an.

[Lord Wotan]

Wieso?
Weil Nvidia zu den ersten nach den Browser Herstellern gehört die Fixes für ihre Software anbieten?
Da müssen alle anderen erst mal nach ziehen. Irgendwie ist diese Panikmache von dir schon sehr seltsam. Hier ist zumindest mal was für Spectre -1. Das geht keines der OS-Patches bisher an.Ganz einfach.
Fall das auch Leistung kosten nach Patch für die NVidia Grafikkarten, geht die Kombination Intel CPU und NVidia Grafikkarte nicht mehr.

[Complicated]

Und wenn der Patch in einem Spiel Leistung kostet für alle ist das besser?
Und AMD Software muss nicht gepatcht werden?
Und vor allem wo bei Spielen überhaupt keine Performance Einbußen zu erwarten sind bei den Workloads.

[LadyWhirlwind]

Wir wissen ja gar nicht, was der Patch tut?

Vielleicht verhindert er nur, dass jemand über den Grafiktreiber angriffe startet.
Es werden viele noch mit Patches kommen, die verhindern sollen, dass man ihre Produkte für einen Angriff missbraucht.

[Bucklew]

So jetzt wird die Geschichte richtig LUSTIG.
http://nvidia.custhelp.com/app/answers/detail/a_id/4611
Super Support von NVIDIA.

Wann kommt das identische Update für den AMD-Grafiktreiber?

[Boris]

Super Support von NVIDIA.

Wann kommt das identische Update für den AMD-Grafiktreiber?
Sind die überhaupt betroffen?

[Bucklew]

Sind die überhaupt betroffen?
Jede Software auf x86 ist betroffen.

[Screemer]

Jede Software auf x86 ist betroffen.

Bullshit.

[unl34shed]

Für Spectre schon, bloß was soll aus dem Treiber ausgelesen werden?

[Screemer]

Es gibt durchaus x86 Software die das was sie in den Speicher schreibt verschlüsselt. Dafür können keys aus dedizierter Securityhardware genutzt werden, die nie im Speicher landen. Die pauschalisierend ist einfach Quatsch.

[nonharderware]

Zwei Fragen zum Verständnis:

"Spectre" und "Meltdown" sind seit 1995 möglich?
Wenn ja, liegt dies an der P6-Mikroarchitektur (Pentium Pro/II/III/M/Core/Core 2/Core i)?

[Screemer]

Pentium pro war der erste x86 Kern mit spekulative Exekution, wenn ich mich recht erinnere. Grundlegend hat sich an der Herangehensweise seit dem nichts geändert.

[Gipsel]

Bullshit.So Bullshit ist das nicht. Die Frage ist halt nur, wie groß sind die potentiellen Auswirkungen. Und ein Hardwaretreiber, der mit Kernelprivilegien läuft, ist schon ein etwas lohnenderes Ziel. Da sollte man sich also durchaus mal ansehen, ob da bezüglich Spectre wirklich Alles dicht ist. Auch wenn bei einem Switch in den Kernelmode die BTBs geflusht werden, schützt das nicht davor, daß bei einem länger laufendem Aufruf einer Treiberfunktion praktisch online vom zweiten Thread auf dem Kern die BTBs wieder falsch trainiert werden. Hier hilft im Zweifelfall wohl nur IBRS für den kompletten Kernel zu aktivieren, was auf den aktuellen CPUs nur mit µCode-Update geht (und Performanceverlust). Wenn es keines gibt (oder es nicht eingespielt wurde), muß man im Prinzip auch überall im Treiber IBPBs (indirect branch prediction barriers) setzen (was auf den meisten CPUs aber auch nur mit µCode-Update geht, da lfence dort nicht als solches wirkt).
Daß der Angriff praktisch wohl nur schwierig funktioniert, ändert nichts Fundamentales.

[nonharderware]

Pentium pro war der erste x86 Kern mit spekulative Exekution, wenn ich mich recht erinnere. Grundlegend hat sich an der Herangehensweise seit dem nichts geändert.

Ist NetBurst auch betroffen oder nicht?

[Ganon]

Jede Software auf x86 ist betroffen.

Jede Software die Code aus unbekannter Quelle ausführt. Und da man durch den BPF-JIT Code in den Kernel einschleusen konnte, erlaubte das hier eben auch Kernel-Zugriff, wenn Meltdown nicht möglich war.

Da eine Grafikkarte aber auch Code annimmt und ausführt (Shader, Compute-Code, ...) ist hier vermutlich ähnliches möglich, wie mit dem BPF-JIT, wenn auch nur noch nicht so komplett und öffentlich erforscht.

Für andere Software brauchst du dann erst mal wieder eine Code Execution Lücke, damit diese Code in ihrem Prozesskontext ausführt.

[Gipsel]

Jede Software die Code aus unbekannter Quelle ausführt. Und da man durch den BPF-JIT Code in den Kernel einschleusen konnte, erlaubte das hier eben auch Kernel-Zugriff, wenn Meltdown nicht möglich war.

Da eine Grafikkarte aber auch Code annimmt und ausführt (Shader, Compute-Code, ...) ist hier vermutlich ähnliches möglich, wie mit dem BPF-JIT, wenn auch nur noch nicht so komplett und öffentlich erforscht.

Für andere Software brauchst du dann erst mal wieder eine Code Execution Lücke, damit diese Code in ihrem Prozesskontext ausführt.Für Spectre v2 mußt Du nur im Userland Code ausführen können, der z.B. an den Grafikkartentreiber gerichtete Syscalls provoziert und gleichzeitg die Branch prediction entsprechend trainiert. Der Syscall bringt Dich in den Kernelkontext ohne selbst dort Code einschleusen zu müssen. Der PoC-Code für Spectre v2 hat das über einen Aufruf von Sleep() gemacht, wobei die branch prediction so trainiert war, daß Sleep dann spekulativ die Gadgets angesprungen hat, die dann Kernelspeicher geleakt haben. Sieht umständlich aus, funktionierte aber offenbar (mit einiger vorbereitung).

[Ganon]

Für Spectre v2 mußt Du nur im Userland Code ausführen können

Ja, das stimmt. NVidia redet aber in ihrem Support-Dokument davon, dass sie Fixes für Variant 1 haben. Fixes für Variant 2 stehen noch aus?


NVIDIA’s initial analysis indicates that the NVIDIA GPU Display Driver is potentially affected by this variant. NVIDIA expects to work together with its ecosystem partners on future updates for this variant.

[Gipsel]

Ja, das stimmt. NVidia redet aber in ihrem Support-Dokument davon, dass sie Fixes für Variant 1 haben. Fixes für Variant 2 stehen noch aus?
Da hast Du recht. Bei Spectre v2 schauen sie offenbar noch, was zu tun ist. Das sollte auch besser mit dem OS abgestimmt sein, sonst macht man da vielleicht auch Sachen doppelt oder bremst es unnötig ein.

[Ganon]

Ist NetBurst auch betroffen oder nicht?

Prinzipiell ist jede CPU betroffen mit Out-of-Order Architektur und/oder spekulative Ausführung. Ist beides nicht vorhanden, ist man immun gegen alles. Ist eines davon vorhanden, dann ist man in der Regel von mindestens einem Problem (Variant 1) auch betroffen. Ausnahmen muss man dann auf "per-CPU Basis" suchen.

[Lord Wotan]

Da ja immer mehr Chiphersteller betroffen sind von Hardware Bug. Ist das nicht ein Beweis das die alle bei Intel die Technik geklaut haben. Und könnte Intel jetzt nicht für die überführten Geld verlangen? Denn offensichtlich arbeiten alle CPUs nach der selben art. Sonst müsste ja nicht alle Fixen.

[gravitationsfeld]

Jede Software die Code aus unbekannter Quelle ausführt. Und da man durch den BPF-JIT Code in den Kernel einschleusen konnte, erlaubte das hier eben auch Kernel-Zugriff, wenn Meltdown nicht möglich war.

Da eine Grafikkarte aber auch Code annimmt und ausführt (Shader, Compute-Code, ...) ist hier vermutlich ähnliches möglich, wie mit dem BPF-JIT, wenn auch nur noch nicht so komplett und öffentlich erforscht.

Für andere Software brauchst du dann erst mal wieder eine Code Execution Lücke, damit diese Code in ihrem Prozesskontext ausführt.
GPUs haben keine spekulative Ausfuehrung und keine Branch-Prediction. Sehr unwahrscheinlich, dass sie betroffen sind.

[anddill]

Es geht ja auch nicht um die GPU, aber der GPU-Treiber führt auch Software auf der CPU aus. Zumindest erst mal sich selbst.

[gravitationsfeld]

Darum ging es nicht. Er meinte, dass der Shadercode auf der GPU selber betroffen ist.

[anddill]

Das gilt nur wenn der ausgeführte Code wirklich nur auf der GPU läuft. Keine Ahnung ob das in der Praxis wirklich so ist. Wohl eher nicht. Und wie gesagt, dann bleibt ja auch noch der Treiber selber, der evtl eine Angriffsfläche bietet. (edit: Also böse Software linst von außen in den Treiber)
Und wenn es nur darum geht DRM-Kram innerhalb der nVidia Software vor Zugriff von außen zu schützen.

[gravitationsfeld]

Der von der Applikation bereitgestellte Code (Shader, OpenCL-Kernel etc.) laeuft nur auf der GPU.

Beim BPF-JIT wird tatsaechlich Code vom User-Space im Kernel ausgefuehrt.

[deekey777]

...Und wenn es nur darum geht DRM-Kram innerhalb der nVidia Software vor Zugriff von außen zu schützen.

Wenn wir schon beim DRM sind:

Könnte man nicht durch solche Eingriffe zB aacs 2.0 angreifen und die geschützten Schlüssel klauen, die eigentlich für die Wiedergabe erforderlich sind?

[lumines]

Da ja immer mehr Chiphersteller betroffen sind von Hardware Bug. Ist das nicht ein Beweis das die alle bei Intel die Technik geklaut haben. Und könnte Intel jetzt nicht für die überführten Geld verlangen? Denn offensichtlich arbeiten alle CPUs nach der selben art. Sonst müsste ja nicht alle Fixen.

Welche "Technik"? Es geht hier um ein ganz allgemeines Konzept, das in den CPUs teilweise sehr unterschiedlich umgesetzt sein kann.

Alle Autos fahren von A nach B, aber das sagt nichts über den verbauten Motor aus.

[Thoro]

Also für mich hat das Ganze jetzt insofern den positiven Nebeneffekt, als dass es mir endlich den letzten Anreiz gegeben hat, auf Linux (Manjaro in meinem Fall) zu wechseln mit dem Heimrechner. Mein Win7 war schon länger Update-mäßig broken und statt neu aufsetzen kann es jetzt genauso gut was ganz Neues sein. Insofern: wo Bugs und Exploits ein FENSTER schließen,... :)

[Poook]

Da ja immer mehr Chiphersteller betroffen sind von Hardware Bug. Ist das nicht ein Beweis das die alle bei Intel die Technik geklaut haben. Und könnte Intel jetzt nicht für die überführten Geld verlangen? Denn offensichtlich arbeiten alle CPUs nach der selben art. Sonst müsste ja nicht alle Fixen.

Da out of order eine Basistechnologie ist gab es da sicherlich Lizenzaustauschabkommen. Ausserdem wird der Patentschutz inzwischen ausgelaufen sein. Erste Prozessoren waren 95 mit dieser Technologie auf dem Markt und die Patente werden wohl nochmal 5 Jahre älter sein. Maximale Schutzdauer ist 20 Jahre, mit Tricks 22 Jahre in Fremdmärkten.

[nonharderware]

Da out of order eine Basistechnologie ist gab es da sicherlich Lizenzaustauschabkommen. Ausserdem wird der Patentschutz inzwischen ausgelaufen sein. Erste Prozessoren waren 95 mit dieser Technologie auf dem Markt und die Patente werden wohl nochmal 5 Jahre älter sein. Maximale Schutzdauer ist 20 Jahre, mit Tricks 22 Jahre in Fremdmärkten.

Und gab/gibt es nicht gewisse staatliche Aufträge (Rüstung?), welche eine zweite Quelle für den Fall des Wegfalls einer Primärquelle als Bedingung haben?
Also Konzern X baut Flieger, dort sind x86 CPUs von Hersteller A verbaut. Konzern X bekommt aber nur den Zuschlag für einen staatlichen Auftrag wenn er auch auf x86 CPUs von Hersteller B notfalls zugreifen kann?

Oder hab ich da jetzt etwas falsch im Kopf?

[Poook]

Und gab/gibt es nicht gewisse staatliche Aufträge (Rüstung?), welche eine zweite Quelle für den Fall des Wegfalls einer Primärquelle als Bedingung haben?
Also Konzern X baut Flieger, dort sind x86 CPUs von Hersteller A verbaut. Konzern X bekommt aber nur den Zuschlag für einen staatlichen Auftrag wenn er auch auf x86 CPUs von Hersteller B notfalls zugreifen kann?

Oder hab ich da jetzt etwas falsch im Kopf?

Sowas hab ich auch im Kopf. Allerdings kenn ich ähnliche Verträge aus der Industrie die dem Kunden erlauben alle Ersatz- und Verbrauchsteile für schon bestehende(!) Anlagen in Lizenz fertigen zu dürfen falls der Hersteller in Insolvenz gehen sollte. Dies bedingt nicht, dass ein anderer Hersteller dies schon im Sortiment haben muss. Kenne mich aber nicht mit militärischen Verträgen aus.

[Lurtz]

Wie ja schon gesagt wurde: Rein technisch könnte Microsoft, genauso wie Linux es ja tut, das nötige Microcode Update von Intel und AMD (auch wenn hier möglicherweise nicht wirklich nötig) alleine ausliefern. Warum sie es nicht tun, keine Ahnung.

Ist natürlich keine Entschuldigung für Hersteller die Updates nicht an ihre Kunden ausliefern, aber das Problem kennt man ja nicht erst seit vorgestern. Viele Consumer-Boards sitzen noch auf ganz anderen Lücken, mangels BIOS Update.

Weil sie dann den Hate und Supportaufwand abbekommen wenn was nicht mehr funktioniert?

Gerade in Verbindung mit den Zwangsupdates... Microsoft hat meine CPU 5% langsamer gemacht, wäh!

[LadyWhirlwind]

Und gab/gibt es nicht gewisse staatliche Aufträge (Rüstung?), welche eine zweite Quelle für den Fall des Wegfalls einer Primärquelle als Bedingung haben?
Also Konzern X baut Flieger, dort sind x86 CPUs von Hersteller A verbaut. Konzern X bekommt aber nur den Zuschlag für einen staatlichen Auftrag wenn er auch auf x86 CPUs von Hersteller B notfalls zugreifen kann?

Oder hab ich da jetzt etwas falsch im Kopf?

Ausserdem muss das Grundlegende Konzept dahinter auch gar nicht von Intel stammen. Das kann auch an einer Univer

[Gipsel]

Da out of order eine Basistechnologie ist gab es da sicherlich Lizenzaustauschabkommen. Ausserdem wird der Patentschutz inzwischen ausgelaufen sein. Erste Prozessoren waren 95 mit dieser Technologie auf dem Markt und die Patente werden wohl nochmal 5 Jahre älter sein. Maximale Schutzdauer ist 20 Jahre, mit Tricks 22 Jahre in Fremdmärkten.IBM hat schon ab 1967 OoO-Prozessoren gebaut (System 360/91), als es intel noch nicht mal gab. Die Grundlagen dafür stehen seit Jahrzehnten in Lehrbüchern. Einfach mal nach dem Herren Tomasulo googlen. ;)

[gravitationsfeld]

Da out of order eine Basistechnologie ist gab es da sicherlich Lizenzaustauschabkommen. Ausserdem wird der Patentschutz inzwischen ausgelaufen sein. Erste Prozessoren waren 95 mit dieser Technologie auf dem Markt und die Patente werden wohl nochmal 5 Jahre älter sein. Maximale Schutzdauer ist 20 Jahre, mit Tricks 22 Jahre in Fremdmärkten.
Out-of-Order- und Speculative-Execution gehen in die 70er und 80er zurueck bei den Mainframes.

[Fusion_Power]

So oder so, wenn Intel & Co. in Zukunft noch irgend welche CPUs verkaufen wollen, müssen sie endlich das problematische Hardwaredesign verändern, vllt. sind sie ja nun motiviert genug. Gerade Großkunden können sich potentiell so unsichere Chips wohl nicht leisten. nach jahren der "schneller, schneller" Philosophie kommt hoffentlich die "sicherer, sicherer" Philosophie. Es muss erst immer schlimm werden, bevor es besser wird.

[Dorn]

Epic Services & Stability Update
The following chart shows the significant impact on CPU usage of one of our back-end services after a host was patched to address the Meltdown vulnerability.
https://lh6.googleusercontent.com/MwzsHRXQLVbmJ3pusNuGwn0ZQVjo9h8nRJHJhIo4d3XFqbvUYCj8EPq5jV7zeVEEcHAkraNBesbbNDW_ UAlIjvw-hZBd80rKt7ZYl35nBIcfCCVyRvW5V7M7KVejv9tvVBHfgSKr

https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update#post132642

Aua kommen wohl schlechter Zeiten auf die Hoster zu hier Fortnite.

[Gipsel]

So oder so, wenn Intel & Co. in Zukunft noch irgend welche CPUs verkaufen wollen, müssen sie endlich das problematische Hardwaredesign verändern, vllt. sind sie ja nun motiviert genug. Gerade Großkunden können sich potentiell so unsichere Chips wohl nicht leisten. nach jahren der "schneller, schneller" Philosophie kommt hoffentlich die "sicherer, sicherer" Philosophie. Es muss erst immer schlimm werden, bevor es besser wird.Meltdown läßt sich in Hardware vermeiden, ebenso Spectre v2 (bzw. praktisch unmöglich machen, dies erfordert etwas mehr Hardwareaufwand bei der Sprungvorhersage). Spectre v1 ist aber ein immanentes Problem der spekulativen Ausführung. Damit muß man wohl leben bzw. müssen die CPUs zukünftig Funktionen anbieten, wie man in sicherheitsrelevanten Bereichen die Spekulation gezielt (softwaregesteuert) eindämmen kann.
Epic Services & Stability Update
The following chart shows the significant impact on CPU usage of one of our back-end services after a host was patched to address the Meltdown vulnerability.
https://lh6.googleusercontent.com/MwzsHRXQLVbmJ3pusNuGwn0ZQVjo9h8nRJHJhIo4d3XFqbvUYCj8EPq5jV7zeVEEcHAkraNBesbbNDW_ UAlIjvw-hZBd80rKt7ZYl35nBIcfCCVyRvW5V7M7KVejv9tvVBHfgSKr

https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update#post132642

Aua kommen wohl schlechter Zeiten auf die Hoster zu hier Fortnite.Die Grafik sehe ich jetzt glaube ich zum vierten Mal hier im Thread.

[LadyWhirlwind]

So oder so, wenn Intel & Co. in Zukunft noch irgend welche CPUs verkaufen wollen, müssen sie endlich das problematische Hardwaredesign verändern, vllt. sind sie ja nun motiviert genug. Gerade Großkunden können sich potentiell so unsichere Chips wohl nicht leisten. nach jahren der "schneller, schneller" Philosophie kommt hoffentlich die "sicherer, sicherer" Philosophie. Es muss erst immer schlimm werden, bevor es besser wird.

Naja, ich wäre da vorsichtig mit solchen Aussagen. Man hat das ja nicht ohne Grund so gemacht, sondern hauptsächlich weil es Leistung bringt. Man muss hier auch zwischen Meltdown und Spectre unterscheiden. Meltdown lässt sich mit entsprechender Anpassung am OS und sicher auch am Chip lösen, was auch geschehen wird. Intel wird das sicher tun, weil AMD hat ja das ganze Problem erst gar nicht.

Bei Spectre sieht das anders aus, solange da aber die Prozessisolation nicht gebrochen wird, werden viele damit leben können, wenn es viel Leistung kosten würde das zu fixen.

Einzig bei Cloud-Angeboten dürften die Preise steigen und es dürften vermehrt eigene physikalische Server nachgefragt werden.

Edit: Zukünftige CPU Generationen werden natürlich sicher dafür sorgen, dass Spectre nicht mehr so einfach wird. Aber ich denke am grundsätzlichen Konzept der Spekulation und an den Caches wird man festhalten.

Edit2:Kennt ihr ne gute Lektüre, um zu lernen wie Mikroprozessoren funktionieren?

[PrivateCeralion]

https://twitter.com/randal_olson/status/950118735964073984

"How much are #sklearn and other #MachineLearning, #DeepLearning, and #DataScience libraries slowed down by the #Meltdown bug and patch?"

[Gipsel]

Edit2:Kennt ihr ne gute Lektüre, um zu lernen wie Mikroprozessoren funktionieren?
Hennessy & Patterson: Computer Architecture
Gibt inzwischen die 6. Ausgabe oder so. Etwas älter (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.115.1881&rep=rep1&type=pdf).

[Armaq]

Zwei Fragen zum Verständnis:

"Spectre" und "Meltdown" sind seit 1995 möglich?
Wenn ja, liegt dies an der P6-Mikroarchitektur (Pentium Pro/II/III/M/Core/Core 2/Core i)?
Nein sind sie nicht.

Auch in der genutzten Software muss das machbar sein. Heutige Browser sind auch extrem mächtig und soweit ich das Thema Spectre&Meltdown Timing greifen konnte, reden wir von abartig kleinen Zeitfenstern und einem Programmierer, der in der Lage ist innerhalb von diesen Zeitfenstern Blödsinn zu machen. Dafür eignen sich javascript und seine Derivate eben auch besonders gut.

Wie gesagt haben da viele sehr schlaue Menschen viele Jahre in Stunden investiert, um es so gut hinzubekommen. Es ist so bahnbrechend, weil der Angreifer aller sonstigen Mechanismen zum Trotz einfach durch alles hindurch läuft.

Wenn ihr euch einen Server mietet beispielsweise einen Counterstrike Gaming Server, dann könnt ihr alles auslesen was auf der physikalischen Maschine passiert (notwendige Skills sind Voraussetzung) und jetzt ist halt die Scheiße, dass auf einer Public Cloud (AWS, Azure, Google, Openstack) ggf. eure virtuelle Maschine mit einer virtuellen Maschine einer Bank zusammen läuft (auf einem physikalischen Server). Das führt zum vollständigen Bruch aller Sicherheitsmechanismen, egal wie klug. Alles was sich brillante Software Ingenieure haben einfallen lassen, um Isolation zwischen virtuellen Instanzen herzustellen (virtuelle Netze, Firewalls, Berechtigungskonzepte) ist komplett hinfällig und egal.

Auch alle die glauben mit Linux ist das besser irren sich. Die beste Performance und 100% Hitrate erreichen die Forscher auf Linux basierten Systemen. :)

[Ganon]

GPUs haben keine spekulative Ausfuehrung und keine Branch-Prediction. Sehr unwahrscheinlich, dass sie betroffen sind.

Ich meine gar nicht so sehr die GPU selbst. Leider sagt ja NVidia nicht genau was sie gefixt haben, oder wo sie im Detail die Probleme mit Variant 2 sehen (gut, wären auch schön blöd ohne einen Fix dafür). Ist auch die Frage ob sie mit "GPU Driver" wirklich den "GPU Driver" meinen, oder den ganzen Kram oben drauf noch (NodeJS Server, Geforce Experience, usw.)

Aber irgendwo sehen sie ja Gefahren. Daher kam meine Vermutung, dass es irgendwo auf dem Weg Shader-Code -> Frontend -> Backend -> PTX -> Kernel-Treiber passieren könnte. Und wenn es eben nur NVidia-Internas selbst sind und nicht "Meltdown-Like" Komplettzugriff auf alles.

Entsprechende Details könnten da nämlich auch den offenen Treibern helfen.

[nonharderware]

Sowas hab ich auch im Kopf. Allerdings kenn ich ähnliche Verträge aus der Industrie die dem Kunden erlauben alle Ersatz- und Verbrauchsteile für schon bestehende(!) Anlagen in Lizenz fertigen zu dürfen falls der Hersteller in Insolvenz gehen sollte. Dies bedingt nicht, dass ein anderer Hersteller dies schon im Sortiment haben muss. Kenne mich aber nicht mit militärischen Verträgen aus.

Ich kenne mich da auch nicht aus, aber ich habe sowas irgendwann mal vor längerer Zeit gelesen - meine ich zumindest.

Nein sind sie nicht.

Auch in der genutzten Software muss das machbar sein. Heutige Browser sind auch extrem mächtig und soweit ich das Thema Spectre&Meltdown Timing greifen konnte, reden wir von abartig kleinen Zeitfenstern und einem Programmierer, der in der Lage ist innerhalb von diesen Zeitfenstern Blödsinn zu machen. Dafür eignen sich javascript und seine Derivate eben auch besonders gut.

Wie gesagt haben da viele sehr schlaue Menschen viele Jahre in Stunden investiert, um es so gut hinzubekommen. Es ist so bahnbrechend, weil der Angreifer aller sonstigen Mechanismen zum Trotz einfach durch alles hindurch läuft.

Wenn ich euch einen Server mietet beispielsweise einen Counterstrike Gaming Server, dann könnt ihr alles auslesen was auf der physikalischen Maschine passiert (notwendige Skills sind Voraussetzung) und jetzt ist halt die Scheiße, dass auf einer Public Cloud (AWS, Azure, Google, Openstack) ggf. eure virtuelle Maschine mit einer virtuellen Maschine einer Bank zusammen läuft (auf einem physikalischen Server). Das führt zum vollständigen Bruch aller Sicherheitsmechanismen, egal wie klug. Alles was sich brillante Software Ingenieure haben einfallen lassen, um Isolation zwischen virtuellen Instanzen herzustellen (virtuelle Netze, Firewalls, Berechtigungskonzepte) ist komplett hinfällig und egal.

Auch alle die glauben mit Linux ist das besser irren sich. Die beste Performance und 100% Hitrate erreichen die Forscher auf Linux basierten Systemen. :)

Herzlichen Dank für die Erklärung! :up:

[LadyWhirlwind]

Nein sind sie nicht.

Auch in der genutzten Software muss das machbar sein. Heutige Browser sind auch extrem mächtig und soweit ich das Thema Spectre&Meltdown Timing greifen konnte, reden wir von abartig kleinen Zeitfenstern und einem Programmierer, der in der Lage ist innerhalb von diesen Zeitfenstern Blödsinn zu machen. Dafür eignen sich javascript und seine Derivate eben auch besonders gut.

Wie gesagt haben da viele sehr schlaue Menschen viele Jahre in Stunden investiert, um es so gut hinzubekommen. Es ist so bahnbrechend, weil der Angreifer aller sonstigen Mechanismen zum Trotz einfach durch alles hindurch läuft.

Wenn ich euch einen Server mietet beispielsweise einen Counterstrike Gaming Server, dann könnt ihr alles auslesen was auf der physikalischen Maschine passiert (notwendige Skills sind Voraussetzung) und jetzt ist halt die Scheiße, dass auf einer Public Cloud (AWS, Azure, Google, Openstack) ggf. eure virtuelle Maschine mit einer virtuellen Maschine einer Bank zusammen läuft (auf einem physikalischen Server). Das führt zum vollständigen Bruch aller Sicherheitsmechanismen, egal wie klug. Alles was sich brillante Software Ingenieure haben einfallen lassen, um Isolation zwischen virtuellen Instanzen herzustellen (virtuelle Netze, Firewalls, Berechtigungskonzepte) ist komplett hinfällig und egal.

Auch alle die glauben mit Linux ist das besser irren sich. Die beste Performance und 100% Hitrate erreichen die Forscher auf Linux basierten Systemen. :)

Das bezieht sich auf welche Variante?
Bei Spectre sollte das ja nicht möglich sein, oder?

@Gipsel: danke für die leichte Bettlektüre.

[Brillus]

Und gab/gibt es nicht gewisse staatliche Aufträge (Rüstung?), welche eine zweite Quelle für den Fall des Wegfalls einer Primärquelle als Bedingung haben?
Also Konzern X baut Flieger, dort sind x86 CPUs von Hersteller A verbaut. Konzern X bekommt aber nur den Zuschlag für einen staatlichen Auftrag wenn er auch auf x86 CPUs von Hersteller B notfalls zugreifen kann?

Oder hab ich da jetzt etwas falsch im Kopf?
Das war eher IBM und der Grund warum AMD(und via?) x86er bauen darf.

[PrivateCeralion]

Ich hab jetzt eine Beschwerde an den Verbraucherschutz geschickt. Denn für meinen Laptop werde ich kein Fix mehr für Spectre bekommen, da er 4 Jahre alt ist und er ist aktuell 9 Prozent langsamer. In Scykit learn wahrscheinlich noch mehr, welches ich täglich nutze. (Neben Tensor Flow und Android Studio).

Manche werden sagen, dass ich mich nicht beschweren soll, aber mir gehts ums Prinzip. Wenn Spectre nicht gefixt wird, will ich damit nicht ins Internet gehen und ich kann ehrlich gesagt ohne Internet nicht programmieren, wegen der Dokumentation, Github und Stack Overflow.

[PrivateCeralion]

Na wunderbar, mein Handy ist mit 4 Cortex-A72 Kernen auch betroffen. Sogar von allen 3 Bugs. Es gab noch kein Patch. Ich werde es morgen zurück geben, da es für die Firma und Privat genutzt wird.
Es ist zwar 1,5 Jahre alt und normal hat man keine Chance nachzuweisen, das der Mangel seit dem Kauf vorlag. Diesmal ist es anders. ;)

[gravitationsfeld]

Lustigerweise war das billige Moto G5 Plus gar kein so schlechter Kauf (ausser dass es sonst keine Patches gibt). Die A53 sind wohl nicht betroffen.

[Semmel]

Na wunderbar, mein Handy ist mit 4 Cortex-A72 Kernen auch betroffen. Sogar von allen 3 Bugs. Es gab noch kein Patch. Ich werde es morgen zurück geben, da es für die Firma und Privat genutzt wird.
Es ist zwar 1,5 Jahre alt und normal hat man keine Chance nachzuweisen, das der Mangel seit dem Kauf vorlag. Diesmal ist es anders. ;)


Das ist echt interessant für das Thema Gewährleistung.
So kann man für jedes Gerät, das eine betroffene CPU verbaut hat, Gewährleistung in Anspruch nehmen.

[Ganon]

Lustigerweise war das billige Moto G5 Plus gar kein so schlechter Kauf (ausser dass es sonst keine Patches gibt). Die A53 sind wohl nicht betroffen.

Updates kommen schon... nur rollt Lenovo diese sehr eigenartig verteilt und langsam aus. Einige haben "schon" das November Update, andere sind auf August, andere auf Juli. Hab da bisher noch kein "Muster" gefunden, suche aber eigentlich auch gar nicht.

Das ist echt interessant für das Thema Gewährleistung.
So kann man für jedes Gerät, das eine betroffene CPU verbaut hat, Gewährleistung in Anspruch nehmen.

Ist die Frage ob das Ganze als defekt anerkannt/zugegeben wird. Wäre natürlich schön, denn dann gilt es eigentlich für so ziemlich jede Sicherheitslücke bei Smartphones, die der Hersteller nicht patcht. Darum sehe ich auch die Chancen auf Erfolg als eher gering an. Und da gibt es ganz andere, viel bösartigere Lücken.

edit: Und bei all dem Bedenken: Oft gibt es noch gar keine umfangreichen Patches gegen Spectre.

[Lord Wotan]

Ich hab jetzt eine Beschwerde an den Verbraucherschutz geschickt. Denn für meinen Laptop werde ich kein Fix mehr für Spectre bekommen, da er 4 Jahre alt ist und er ist aktuell 9 Prozent langsamer. In Scykit learn wahrscheinlich noch mehr, welches ich täglich nutze. (Neben Tensor Flow und Android Studio).

Manche werden sagen, dass ich mich nicht beschweren soll, aber mir gehts ums Prinzip. Wenn Spectre nicht gefixt wird, will ich damit nicht ins Internet gehen und ich kann ehrlich gesagt ohne Internet nicht programmieren, wegen der Dokumentation, Github und Stack Overflow.
Bitte halte uns auf den Laufenden . Wäre schon wenn du erfolg hast. Dann kann ich auch was gegen Asus und Microsoft bzw.Intel machen.

[Armaq]

Das bezieht sich auf welche Variante?
Bei Spectre sollte das ja nicht möglich sein, oder?

@Gipsel: danke für die leichte Bettlektüre.
Doch, ist auch bei Spectre möglich. Du kommunizierst ja mit der HW schlussendlich und die Versiegelung/Isolierung ist eben angreifbar.

[Lurtz]

Na wunderbar, mein Handy ist mit 4 Cortex-A72 Kernen auch betroffen. Sogar von allen 3 Bugs. Es gab noch kein Patch. Ich werde es morgen zurück geben, da es für die Firma und Privat genutzt wird.
Es ist zwar 1,5 Jahre alt und normal hat man keine Chance nachzuweisen, das der Mangel seit dem Kauf vorlag. Diesmal ist es anders. ;)
Meines hat auch zwei A72-Kerne. Berichte mal wie lange es dauert bis du denen klargemacht hast worum es überhaupt geht ;D

[Thoro]

@Armaq

Danke für den Post auf der vorigen Seite; kannst du - einigermaßen simpel - erklären, warum Linux konsistenter angreifbar ist als z.B. Windows? Liegt da eventuell die Crux darin, dass Linux idR "sauberer" arbeitet und besser dokumentiert ist?

[Ganon]

@Armaq

Danke für den Post auf der vorigen Seite; kannst du - einigermaßen simpel - erklären, warum Linux konsistenter angreifbar ist als z.B. Windows? Liegt da eventuell die Crux darin, dass Linux idR "sauberer" arbeitet und besser dokumentiert ist?

https://meltdownattack.com/meltdown.pdf
6.1.3 Microsoft Windows

In contrast to Linux, Windows does not have the concept
of an identity mapping, which linearly maps the
physical memory into the virtual address space. Instead,
a large fraction of the physical memory is mapped in
the paged pools, non-paged pools, and the system cache.
Furthermore, Windows maps the kernel into the address
space of every application too. Thus, Meltdown can read
kernel memory which is mapped in the kernel address
space, i.e., any part of the kernel which is not swapped
out, and any page mapped in the paged and non-paged
pool, and the system cache.

Note that there likely are physical pages which are
mapped in one process but not in the (kernel) address
space of another process, i.e., physical pages which cannot
be attacked using Meltdown. However, most of the
physical memory will still be accessible through Meltdown.


grobes tl;dr: Linux arbeitet in einer Weise die bei der Attacke hilft.

[Monsta]

Ich habe mal Samba 4.5.10-r1 mit und ohne Kernelpatch Compiliert.

Thinkpad X1 Carbon ohne Bios Fix und ohne Microcodeupdate

Kernel 4.15rc7 Cpu: i7 4600u 70mV undervoltet.


Mit Patch: 14m47sec

ohne Patch: 14m22sec

Das sind ca. 3% längere Compilezeit

[Complicated]

Na wunderbar, mein Handy ist mit 4 Cortex-A72 Kernen auch betroffen. Sogar von allen 3 Bugs. Es gab noch kein Patch. Ich werde es morgen zurück geben, da es für die Firma und Privat genutzt wird.
Es ist zwar 1,5 Jahre alt und normal hat man keine Chance nachzuweisen, das der Mangel seit dem Kauf vorlag. Diesmal ist es anders. ;)
Du solltest in jedem Fall an das Recht zur Nachbesserung denken. Hier könnten Patches als solches gelten. Daher darauf achten eine Frist zur Nachbesserung zu setzen um die Grundlage zum Tausch/Rückgabe nach der Frist zu haben. Es ist kaum davon auszugehen, dass für Android Patches in einer annehmbaren Frist kommen.

[scully1234]

Mit welcher CPU Generation fing das alles an ?

War es die erst Core Architektur

Die Intel-Core-Mikroarchitektur wurde am 7. März 2006 auf dem Intel Developer Forum offiziell vorgestellt (https://de.wikipedia.org/wiki/Intel-Core-Mikroarchitektur)

wie die Vereinigten Staaten und das Vereinigte Königreich seit spätestens 2007 in großem Umfang die Telekommunikation und insbesondere das Internet global und verdachtsunabhängig überwachen. (https://de.wikipedia.org/wiki/Globale_%C3%9Cberwachungs-_und_Spionageaff%C3%A4re)

Zufall oder hat man mit Absicht ein Scheunentor aufgemacht???...

[lumines]

Mit welcher CPU Generation fing das alles an ?

War es die erst Core Architektur

Pentium Pro von 1995.

[scully1234]

Ok weil ich Netburst nicht gefunden hatte auf deren Liste

[Exxtreme]

Ich habe mal Samba 4.5.10-r1 mit und ohne Kernelpatch Compiliert.

Thinkpad X1 Carbon ohne Bios Fix und ohne Microcodeupdate

Kernel 4.15rc7 Cpu: i7 4600u 70mV undervoltet.


Mit Patch: 14m47sec

ohne Patch: 14m22sec

Das sind ca. 3% längere Compilezeit
Da müsstest du mehrere Versuche starten und dann Mittelwerte nehmen. Ein einziger Messwert ist bissl wenig. :)

[Ganon]

Da müsstest du mehrere Versuche starten und dann Mittelwerte nehmen. Ein einziger Messwert ist bissl wenig. :)

Wobei das eine Haswell CPU ist. Solange er nicht in einer VM arbeitet dürften die Performance-Verluste sich in diesem Rahmen halten. Skylake und höher sind die, die mit dem BIOS Update "zu kämpfen" haben.

Böse wird's dann in VM-Umgebunden mit vielen VMs, da sich dort der Performance-Verlust recht fix aufaddiert.

[Armaq]

@Armaq

Danke für den Post auf der vorigen Seite; kannst du - einigermaßen simpel - erklären, warum Linux konsistenter angreifbar ist als z.B. Windows? Liegt da eventuell die Crux darin, dass Linux idR "sauberer" arbeitet und besser dokumentiert ist?
Hat Ganon ja schon getan und es steht in den jeweiligen Papers auch einfach drin.

Außerdem ist natürlich klar, dass Windows nicht in dem Umfang dokumentiert ist wie Linux. Auch Intel Prozessoren sind einfach verbreiteter als ein VIA Prozi. Das ist die Krux mit der Marktmacht, wenn was schiefgeht, sind alle voll getroffen.

[lumines]

Außerdem ist natürlich klar, dass Windows nicht in dem Umfang dokumentiert ist wie Linux.

Also mit solchen Aussagen wäre ich eher vorsichtig. Wüsste jetzt nicht, seit wann das so klar ist. Jeder benutzt Linux, aber das bedeutet ja nicht, dass automatisch alles besser dokumentiert ist.

Man findet sehr viele Kommentare und Meinungen im Web, aber das ist ja keine Doku im eigentlichen Sinne.

[Eisenoxid]

Mal eine ganz simple (blöde) Fage:

Ich habe den letzten Win-Patch gegen Meltdown installiert (KB4056892), und mein ASUS Z370-A auf Bios 0606 gepatcht (laut notes --> "Update CPU Microcode") --> gegen Spectre (?).
Langt das jetzt erstmal, und ist das System jetzt wieder "sicher" (soweit es eben geht)?

Oder hab ich noch was vergessen?

[Armaq]

Also mit solchen Aussagen wäre ich eher vorsichtig. Wüsste jetzt nicht, seit wann das so klar ist. Jeder benutzt Linux, aber das bedeutet ja nicht, dass automatisch alles besser dokumentiert ist.

Man findet sehr viele Kommentare und Meinung im Web, aber das ist ja keine Doku im eigentlichen Sinne.
Du kannst dir den Source Code reinziehen. Wie viel mehr braucht es noch? Wenn man das Skill Level hat, kann man sich alles en Detail anschauen und das ist bei Windows nicht möglich (außer für MS-Mitarbeiter). Hier gibt es übrigens auch heilige Hallen die die normalen SW-Engineers von den Kernthemen fern halten. Um bei MS alles zu kennen musst du verdammt gut und verdammt lange dabei sein.

Proprietäre Systeme haben sicherlich viele Nachteile, aber ein unbestreitbarer Vorteil ist die kleinere Liste derer die jede Schweinerei kennen können. Wie ich bereits sagte, bei Intel gibt es garantiert ein paar Leute die diese Art von Angriff bereits kannten.

[Poook]

Proprietäre Systeme haben sicherlich viele Nachteile, aber ein unbestreitbarer Vorteil ist die kleinere Liste derer die jede Schweinerei kennen können. Wie ich bereits sagte, bei Intel gibt es garantiert ein paar Leute die diese Art von Angriff bereits kannten.

Security through obscurity ist wohl der größte Trugschluss der IT Welt.

[PrivateCeralion]

Das Handy wurde angenommen und sie überprüfe es intern. Das kann bis zu 2 Wochen dauern. Es hat eine halbe Stunde gedauert, bis der Service bei Media Markt das Problem verstanden hat xD

[Ganon]

Phoronix hat ein paar Benchmarks mit dem vorläufigen Retpoline v5 (Schutz vor Spectre) gemacht. KPTI ist bei Intel immer an, unabhängig von "noretpoline". Phoronix-Typisch natürlich mit Vorsicht zu genießen.

https://www.phoronix.com/scan.php?page=article&item=linux-retpoline-benchmarks&num=1

[Schnoesel]

Ich habe den letzten Win-Patch gegen Meltdown installiert (KB4056892), und mein ASUS Z370-A auf Bios 0606 gepatcht (laut notes --> "Update CPU Microcode") --> gegen Spectre (?).
Langt das jetzt erstmal, und ist das System jetzt wieder "sicher" (soweit es eben geht)?

Fehlt nur noch ein Browserupdate, dann hast du alles getan was bis jetzt machbar ist.

Andere Frage mein Handy hat den Snapdragon 820 verbaut, der mit Kryokernen läuft:

https://www.qualcomm.com/products/snapdragon-820-processor-embedded

Betroffen oder nicht?! Scheint ja ein customSOC zu sein?!

[Bucklew]

Noch ein spannender Hinweis in fefes blog:

https://blog.fefe.de/?ts=a4ad9f54

Klingt nachvollziehbar. Alle Attacken und Beispiele haben immer gemein, dass die gewünschten Daten aktuell im CPU-Cache vorliegen. Als Angreifer auf einem VM Host, kann man davon aber gar nicht ausgehen. Gezielt antriggern, welche Daten gerade im CPU Cache liegen, kann man auch nicht.

[Ganon]

Betroffen oder nicht?! Scheint ja ein customSOC zu sein?!

Hat Qualcomm noch nicht gesagt. Sie sagen nur, dass sie betroffen sind, aber noch ohne CPU-Liste.

[Schnoesel]

Danke wunder mich schon dass ich nichts dazu gefunden habe.

[Gipsel]

Noch ein spannender Hinweis in fefes blog:

https://blog.fefe.de/?ts=a4ad9f54

Klingt nachvollziehbar. Alle Attacken und Beispiele haben immer gemein, dass die gewünschten Daten aktuell im CPU-Cache vorliegen. Als Angreifer auf einem VM Host, kann man davon aber gar nicht ausgehen. Gezielt antriggern, welche Daten gerade im CPU Cache liegen, kann man auch nicht.Na ja. Da es ja bei einem spekulativen Fetch automatisch auch im L1 abgelegt wird (sogar der davon abhängige zweite Fetch [der eigentliche Sidechannel] hat ja meßbare Auswirkungen auf den Cache), macht man einfach pro Cacheline (64Byte) einen extra-Aufruf vorher, damit es im L1 steht. Ist nicht der große Umstand. Der Overhead dafür beträgt 1,6% bei geleaktem 1 Byte pro Versuch. Also das sehe ich jetzt nicht als das große Problem oder gar Showstopper für einen Exploit. Falls man die Daten wirklich fehlerfrei lesen will (also besser als mit den 0,02% Fehlerrate bei ~500kB/s oder so, von dem die im Paper sprechen), macht man das sowieso mehrfach pro Speicherstelle, wodurch das Problem mit dem Caching ebenfalls völlig erschlagen wird.

[Lord Wotan]

Auf meine Mail an ASRock:
Good evening,


I just wanted to ask when AsRock offers the BIOS fix for the Bug Meltdown & Specter for my Asrock ION 330HT-BD?

MfG


Habe ich heute folgende Antwort bekommen:

Hello

we are allready working with Intel/AMD/Microsoft together to have a solution/fix as soon as possible.
Of course, once we have it we will publish it.

best regards

ASRock Support

ASRock Europe B.V.
Bijsterhuizen 1111
6546 AR Nijmegen
The Netherlands
www.asrock.com



Also wenn ASock das Intel Fix für mein altes HTCP mit Intel Atom 330 liefert, dann kann sich Microsoft mal eine Scheibe abschneiden.

[unl34shed]

Der 330 ist doch In-Order und nicht betroffen, oder?

[Lord Wotan]

Der 330 ist doch In-Order und nicht betroffen, oder?
Das weiß ich nicht. Atom´s sind zum teil auch betroffen, ob der jetzt nicht betroffen ist weiß ich nicht.

[MadCat]

Hi,

bei Heise gibts ne schöne Zusammenfassung der bisherigen Meldungen (sicher unvollständig) von diversen Herstellern:

https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Die-Sicherheitshinweise-und-Updates-von-Hardware-und-Software-Herstellern-3936141.html

So wie es aussieht, wirds für meine beiden Intel-Geräte unterschiedlich ausgehen:

Mein Notebook (Lenovo 420p) wird leer ausgehen, mein Server (Supermicro) wird noch ein Biosupdate bekommen...
Der Server ist mir hier dann noch lieber ^^

Ob ich was für mein aktuelles AMD-System von Biostar bekomme, weiß ich noch nicht. Sollte eigentlich, da dass ja die Agesa-Updates noch ein paar Monate bekommen sollte...

[Armaq]

Security through obscurity ist wohl der größte Trugschluss der IT Welt.
Lässt sich drüber streiten, denn Sicherheit heißt ja nicht immer perfekt sicher. Am Ende ist quell offen sicherlich die bessere Lösung, aber das braucht halt auch ewig viel Zeit.

[deekey777]

Apple dichtet jetzt High Sierra und iOS 11 gegen Spectre ab.

[CompuJoe]

Das weiß ich nicht. Atom´s sind zum teil auch betroffen, ob der jetzt nicht betroffen ist weiß ich nicht.

Ist der Diamondville, ist In-order-execution ohne Speculative execution und damit nicht betroffen.

Die Atoms aus der Bonnel, Saltwell und Pine-Trail Reihe sind nicht betroffen.
Das sind folgente Kerne:

Diamondville
Silverthorne
Pineview

[Armaq]

Noch ein spannender Hinweis in fefes blog:

https://blog.fefe.de/?ts=a4ad9f54

Klingt nachvollziehbar. Alle Attacken und Beispiele haben immer gemein, dass die gewünschten Daten aktuell im CPU-Cache vorliegen. Als Angreifer auf einem VM Host, kann man davon aber gar nicht ausgehen. Gezielt antriggern, welche Daten gerade im CPU Cache liegen, kann man auch nicht.
Das ist nichts für einen normalen "Hacker". AMD fand ich relativ aufschlussreich, denn sie meinten ja, dass man tiefgreifende Kenntnisse der Architektur benötigt, um das zu schaffen. Das glaube ich gerne, denn die Forscher geben keinen Anlass, dass dies nicht so wäre.

Es geht ja nur darum, dass es per Default geht/möglich ist. Cloud Anbieter haben trotzdem die Brille auf, denn da kann mein Gast ja 24/7 mitprotokollieren.

[Fusion_Power]

Meh, irgend eins der ganzen wilden Spectre Updates scheint meinem Grafiktreiber (Nvidia 388.71) nicht gut zu tun, jedenfalls hab ich neulich im Browser einen TDR gehabt, beim Youtube guggen. Das hab ich sonst nie. Spiele laufen stabil bisher, nie Probleme gehabt. Hab ihn mal neu installiert, diesmal vorher mit DDU geplättet statt immer drüberbügeln, falls das was bringt.
Muss nix mit den Spectre/Meltdown updates zu tun haben aber komsich ist das schon.

[labecula]

28.July 2017:
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

Wired Artikel:
https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-discovery/

Auch IBMs alter Xbox360 PPC reiht sich ein:
https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/

—> https://cdn.arstechnica.net/articles/paedia/cpu/xbox360-2.media/ppe-pipeline.png

[deekey777]

Das ist nichts für einen normalen "Hacker". AMD fand ich relativ aufschlussreich, denn sie meinten ja, dass man tiefgreifende Kenntnisse der Architektur benötigt, um das zu schaffen. Das glaube ich gerne, denn die Forscher geben keinen Anlass, dass dies nicht so wäre.

Es geht ja nur darum, dass es per Default geht/möglich ist. Cloud Anbieter haben trotzdem die Brille auf, denn da kann mein Gast ja 24/7 mitprotokollieren.
Ich frage mich, ob diese Offenheit und insbesondere die Eile auch dann gegeben hätte, wenn nur ganz gewöhnliche Homeuser betroffen wären.

[Ganon]

Kommt drauf an. Eigentlich läuft die NDA für die Lücke heute erst aus. Geplant war also, dass wir von dem ganzen Kram bis heute gar nichts mitbekommen.

[Armaq]

Ich frage mich, ob diese Offenheit und insbesondere die Eile auch dann gegeben hätte, wenn nur ganz gewöhnliche Homeuser betroffen wären.
Glaube ich tatsächlich nicht.

[LadyWhirlwind]

Das ist nichts für einen normalen "Hacker". AMD fand ich relativ aufschlussreich, denn sie meinten ja, dass man tiefgreifende Kenntnisse der Architektur benötigt, um das zu schaffen. Das glaube ich gerne, denn die Forscher geben keinen Anlass, dass dies nicht so wäre.

Es geht ja nur darum, dass es per Default geht/möglich ist. Cloud Anbieter haben trotzdem die Brille auf, denn da kann mein Gast ja 24/7 mitprotokollieren.

Für die Cloud-Anbieter ist es vor allem ein Vertrauensproblem. Die Kunden sollen ja dem Anbieter vertrauen und sicher sein, dass Ihre Daten sicher sind. Ausserdem eröffnet das je nach dem durchaus auch das Tor zur (staatlich unterstützen) Industriespionage.

[Pirx]

... Die Kunden sollen ja dem Anbieter vertrauen und sicher sein, dass Ihre Daten sicher sind. ....
Stimmt, ist aber eigentlich sowieso schon ein Witz.

[BUG]

bei Heise gibts ne schöne Zusammenfassung der bisherigen Meldungen (sicher unvollständig) von diversen Herstellern:

https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Die-Sicherheitshinweise-und-Updates-von-Hardware-und-Software-Herstellern-3936141.htmlLaut dem HP Dokument, wird sogar der HP Microserver GEN8 (Sockel 1155 --> Sandy- und Ivy-Bridge-Generation) gepatcht (soon). Der ML10 & ML310e Gen8 hat auch noch den alten Sockel 1155.

https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=null&docLocale=en_US&docId=emr_na-a00039267en_us

Note: System ROM updates for the following ProLiant Gen8 and Gen9, Moonshot server cartridges, and Synergy servers will be available in the future. This Bulletin will be updated accordingly.

ProLiant ML10 Gen8 server
ProLiant ML310e Gen8 server
ProLiant Microserver Gen8
ProLiant XL260a Gen9 server
HPE Synergy 620 Gen9 Compute Modules
HPE Synergy 680 Gen9 Compute Modules
ProLiant Thin Micro TM200
ProLiant m510 Server Cartridge
ProLiant m300 Server Cartridge
ProLiant m350 Server Cartridge

Gruß
BUG

[Ganon]

Es geistert auch gerade so ein bisschen die Behauptung durch's Netz, dass einige (kommerzielle) VM-Anbieter das PCID Feature gar nicht an die VM durchreichen. VirtualBox als Beispiel. Kann vielleicht man jemand nachschauen, der hier VMWare und Co. im Einsatz hat bzw. einen V-Server benutzt?

edit: Wobei ich aber immer noch unsicher bin wie das Zusammenspiel Host-Kernel, VM-Kernel mit unterschiedlichen Settings so ist.

[Birdman]

Kann vielleicht man jemand nachschauen, der hier VMWare und Co. im Einsatz hat bzw. einen V-Server benutzt?

Hier ein Auszug von einer Debian9 VM auf einem ESXi 6.5 Host (wo PCID durchgereicht wird):


Kernel: 4.9.65-3+deb9u1 (ohne Meltdown/Spectre fix)

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
stepping : 1
microcode : 0xb000021
cpu MHz : 3198.764
cache size : 25600 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
bugs :
bogomips : 6399.99
clflush size : 64
cache_alignment : 64
address sizes : 43 bits physical, 48 bits virtual
power management:


Kernel: 4.9.65-3+deb9u2 (mit Meltdown/Spectre fix)

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
stepping : 1
microcode : 0xb000021
cpu MHz : 3198.697
cache size : 25600 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single kaiser fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat
bugs :
bogomips : 6399.99
clflush size : 64
cache_alignment : 64
address sizes : 43 bits physical, 48 bits virtual
power management:

[][immy]

Es geistert auch gerade so ein bisschen die Behauptung durch's Netz, dass einige (kommerzielle) VM-Anbieter das PCID Feature gar nicht an die VM durchreichen. VirtualBox als Beispiel. Kann vielleicht man jemand nachschauen, der hier VMWare und Co. im Einsatz hat bzw. einen V-Server benutzt?

edit: Wobei ich aber immer noch unsicher bin wie das Zusammenspiel Host-Kernel, VM-Kernel mit unterschiedlichen Settings so ist.
Ist es nicht unerheblich ob es durchgereicht wird oder nicht? Wenn das Host-System das "Feature" nutzt, "profitiert" davon indirekt auch die VM. Auch wenn es sich dann wohl nicht so einfach ausnutzen lässt.

[Ganon]

[immy;11599671']Ist es nicht unerheblich ob es durchgereicht wird oder nicht? Wenn das Host-System das "Feature" nutzt, "profitiert" davon indirekt auch die VM. Auch wenn es sich dann wohl nicht so einfach ausnutzen lässt.

Wie gesagt, ich hab mich da noch nicht ausreichend informiert. Aber der Artikel hier: http://archive.is/ma8Iw spricht auch davon.


- Most of the KVM guests I personally looked in did NOT have pcid
- All the VMWare guests I personally looked in DID have pcid
- About half the AWS instances I l personally looked in did NOT have pcid, and the other half did.

[I encourage others to add their experiences, and e.g. enrich this with a table of PCID-capability on known instance types on cloud platforms]

I believe that all hypervisors are capable of exposing PCID to guests, and that it is a matter of choice. I.e. of how your specific hypervisor host and guest instance is configured.


edit: Wenn der Gast-Kernel nicht mit PCIDs arbeitet, dann hilft da soweit ich das sehe der Host-Kernel auch nicht allzu viel. Es geht hier dann letztendlich um die Performance.

@Birdman

Danke

[Tarkin]

Haswell microcode 22h vs. 23h security (Spectre), performance and stability differences

http://www.overclock.net/t/1645289/haswell-microcode-22h-vs-23h-security-spectre-performance-and-stability-differences

OC Potential plötzlich auch im A...? Wow, bravo... also ich würde jetzt meine Intel CPU entsorgen wenn ich eine hätte :mad:

[Annator]

Haswell microcode 22h vs. 23h security (Spectre), performance and stability differences

http://www.overclock.net/t/1645289/haswell-microcode-22h-vs-23h-security-spectre-performance-and-stability-differences

OC Potential plötzlich auch im A...? Wow, bravo... also ich würde jetzt meine Intel CPU entsorgen wenn ich eine hätte :mad:

Warum? :confused:

[Ganon]

Haswell microcode 22h vs. 23h security (Spectre), performance and stability differences

Wie ich schon mal hier geschrieben habe: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11597798

Ich würde prinzipiell keine Microcode-Updates verwenden, die nicht offiziell vom Anbieter auf deren Servern angeboten werden.

[Birdman]

mein Server (Supermicro) wird noch ein Biosupdate bekommen...
SuperMicro scheint ja zurück bis zu ihrer "X8" Generation von Mainboards, ein BIOS-Upgrade anbieten zu wollen - damit reden wir von Systemen welche 2008/2009 rausgekommen sind. :up:


@Ganon
PCID ist ja erst ab Haswell dabei (aka Xeon E3/E5/E7 v3) und ich bin mir sicher dass es viele Cloudumgebungen gibt, bei welchen noch ältere CPUs zum Einsatz kommen.
Daher kann es gut sein, dass halt PCID physisch schon gar nicht vorhanden ist und dies nicht direkt mit dem Virtualisierungs-Layer zu tun hat.

In Clusterumgebungen wo VMs im laufenden Betrieb verschoben werden wollen, kann es auch sein dass PCID auf neueren CPUs explizit deaktiviert (bzw. nicht durchgereicht) wird, damit die Hardware-Kompatibilität zu den älteren Servern gewart wird. (Stichwort "EVC" bei VMware)

[Bucklew]

NVIDIA hat übrigens die Treiber für GeForce und Quadro unter Win und Linux mit Spectre Fix:
http://nvidia.custhelp.com/app/answers/detail/a_id/4611

Daneben wird es im Januar noch Updates für die Androidgeräte Shield Tablet und ShieldTV geben.

[Ganon]

@Ganon
PCID ist ja erst ab Haswell dabei (aka Xeon E3/E5/E7 v3)

Der Artikel spricht von Westmere. Ein Sandy-Bridge-Server hier im Büro listet auch "pcid".


In Clusterumgebungen wo VMs im laufenden Betrieb verschoben werden wollen, kann es auch sein dass PCID auf neueren CPUs explizit deaktiviert (bzw. nicht durchgereicht) wird, damit die Hardware-Kompatibilität zu den älteren Servern gewart wird. (Stichwort "EVC" bei VMware)

Muss man halt gucken, ob das in der jetzigen Situation noch sinnvoll ist.

[lumines]

Du kannst dir den Source Code reinziehen. Wie viel mehr braucht es noch?

Dokumentation ist für mich eigentlich immer eine andere Abstraktionsebene als die eigentliche Implementierung.

[Complicated]

P3DNow: Microsoft zieht Meltdown-Patch für AMD-Systeme zurück (http://www.planet3dnow.de/cms/36039-microsoft-zieht-meltdown-patch-fuer-amd-systeme-zurueck/)
Doch anscheinend war der Patch mit zu heißer Nadel gestrickt, denn nun berichten einige AMD-User, dass der PC nach Installation des Updates nicht mehr startet und sich stattdessen in einer Bluescreen-Schleife verheddert; BSOD stop: 0x000000c4. Daher hat Microsoft die betreffenden Updates für AMD vorübergehend zurückgezogen.

[kruemelmonster]

Der Artikel spricht von Westmere. Ein Sandy-Bridge-Server hier im Büro listet auch "pcid".

Mein Westmere zuhause (Xeon W3680) gibt in AIDA64 zwar Support für PCID an, jedoch nicht für INVPCID welches wohl das eigentlich benötigte Feature ist.

[Birdman]

Der Artikel spricht von Westmere. Ein Sandy-Bridge-Server hier im Büro listet auch "pcid".
Grad selber mal bei uns nachgeprüft, bei Westmere CPUs (z.B. Xeon X5660 oder E5645) gibts nirgends PCID, allerdings wie Du sagt ab Sandy Bridge (z.B. Xeon E5-2640) ist es dabei.

[Erbsenkönig]

P3DNow: Microsoft zieht Meltdown-Patch für AMD-Systeme zurück (http://www.planet3dnow.de/cms/36039-microsoft-zieht-meltdown-patch-fuer-amd-systeme-zurueck/)

Sollte man am Besten die automatischen Updates deaktivieren, bevor man sich das System zerschießt?:eek:

[lumines]

Sollte man am Besten die automatischen Updates deaktivieren, bevor man sich das System zerschießt?:eek:

Wenn die Updates noch nicht runtergeladen wurden, dann sollte nichts schlimmes passieren. Das Update wurde ja wieder zurückgezogen.

[konkretor]

https://www.drwindows.de/news/meltdown-und-spectre-intel-veroeffentlicht-cpu-liste-und-verspricht-immunisierende-updates

Liste was alles betroffen ist, die frage ist, was davon gepatcht wird



Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
Intel® Atom™ Processor C Series
Intel® Atom™ Processor E Series
Intel® Atom™ Processor A Series
Intel® Atom™ Processor x3 Series
Intel® Atom™ Processor Z Series
Intel® Celeron® Processor J Series
Intel® Celeron® Processor N Series
Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Series

[fp69]

Eine Frage an die Profis:
Wenn mein FF quasi geschützt ist und ich Online-Banking mache, bin ich dann bereits sicher
oder braucht es dennoch ein Bios-Update und Win-Patch?
Und muss sich letztendlich nicht am ehesten die Bank selbst schützen?

[Schnoesel]

Browser Update hilft nur gegen eine Spectre Variante. Das Windows Update brauchst du für Meltdown (falls Intel CPU).

[Complicated]

Firefox kann sich selber lediglich gegen Spectre Variante 1 schützen mit einem Software-Patch. Firefox bietet auch über Updates keinen Schutz gegen Meltdown (OS-Patch nötig für Intel CPUs) und gegen Spectre 2 (OS-Patch+BIOS Update nötig)

Zudem sollte niemand "Mitigation" mit "Geschützt" verwechseln. Das Problem ist nicht gefixt, sondern nur Abgeschwächt.
https://www.heise.de/security/meldung/Prozessor-Bug-Browser-Hersteller-reagieren-auf-Meltdown-und-Spectre-3933043.html
Die Entwickler von Chromium und von Mozilla betonen, dass es sich bei ihren Reaktionen um Schnellschüsse handelt, die das Risiko allenfalls ein wenig abmildern.

Edit:
Und muss sich letztendlich nicht am ehesten die Bank selbst schützen?
Das tut sie eigentlich schon durch das TAN Verfahren. Wenn jemand beim Onlinebanking deinen Benutzernamen und deinen Login ausspäht, so muss er auch TANs kennen um damit tatsächlich an dein Geld zu kommen. Er kann zwar deine Daten ausspähen aber erst einmal nichts darüber hinaus damit anstellen ohne TANs.

[fp69]

Danke euch beiden.
Schutz im IT-Bereich ist natürlich nur sehr relativ.

[Blutmaul]

Mein AMD FX8350 auf GA990XA-UD3 läuft problemlos mit dem Sicherheits-Update.
Avast! ist mein Virenscanner, OS Win10.

[][immy]

Eine Frage an die Profis:
Wenn mein FF quasi geschützt ist und ich Online-Banking mache, bin ich dann bereits sicher
oder braucht es dennoch ein Bios-Update und Win-Patch?
Und muss sich letztendlich nicht am ehesten die Bank selbst schützen?
da frage ich mich wie sich der firefox davor schützen möchte wenn es die Aufgabe des OS ist?
Also soweit ich weiß kann dich nur etwas innerhalb des OS/bios davor schützen.

Mein AMD FX8350 auf GA990XA-UD3 läuft problemlos mit dem Sicherheits-Update.
Avast! ist mein Virenscanner, OS Win10.
Hab ebenfalls keine Probleme, allerdings eine Intel Ivy CPU ... wo bleibt das Firmware-Update dafür? :(

[fp69]

Ich meinte, dass ich den aktuellen FF 57.04 nutze, der nun angeblich besser gescützt sein soll.
Ich kann dir jedenfalls keine fundierten Aussagen geben. Ich bin überfordert.

@all

Ich lese bei heise von einem Nutzer u.a. den Satz "Solange Dinge wie die Intel ME closed source und unabschaltbar im Hintergrund lauern".

Ich dachte, wenn ich die Sw, die ich für IME brauche, nicht installiere, dass dann IME kein Problem darstelle? Was stimmt denn nun?

[Birdman]

Ich meinte, dass ich den aktuellen FF 57.04 nutze, der nun angeblich besser gescützt sein soll.
Ich kann dir jedenfalls keine fundierten Aussagen geben. Ich bin überfordert
FF 57.04 schützt dich vor Meltdown/Spectre Schadcode der von Firefox selbst ausgeführt wird, also z.B. ein böses JavaScript. Dieser Schadcode hat dann keine Möglichkeit mehr, auf Memoryinhalte vom OS oder anderen laufenden Programmen von deinem Computer zugreifen zu können.
Afaik kann der Schadcode via der Meltdown/Spectre Methode nicht mal mehr auf Daten zugreifen, welche aus den andern offenen Tabs des Browsers stammen, also z.B. aus der Session von deinem OnlineBanking. (zumindest das "Strict Site Isolation" vom Chrome verhindert das)

Wenn Du dir aber Meltdown/Spectre ausnutzenden Schadcode aus einer andern Quelle (Email, PDF, Office-Dokument, etc.) eingefängst, dann nützt dir der FF Patch gar nichts - dieser Schadcode kann dann weiterhin deinen ganzen Computer ausspähen, auch inkl. den Daten aus der Onlinebanking Session welche Du im Firefox am laufen hast.

[fp69]

Danke dir.
Ich nutze eine Version des FF ausschließlich fürs Banking. Dazu noch Nocript und ublock.
Der andere FF läuft zu diesem Zeitpunkt nicht. Evtl. war das keine schlechte Idee von mir
in der Vergangenheit?
Mittlerweile freue ich mich noch etwas mehr auf Ryzen+. Der scheint ja bei diesem Thema
eher die bessere Wahl zu sein?

Beim Schadcode wird doch wohl mein Avira artig anspringen?!
Jedenfalls ermüdet dieses Thema zusehends.

[Birdman]

Beim Schadcode wird doch wohl mein Avira artig anspringen?!
Davon ist nicht auszugehen.
Code welcher die Meltdown/Specte Sicherheitslücke von Prozessoren im Visier hat, es quasi kaum als "Schadcode" zu identifizieren.

[fp69]

Na super. Ich freue mich riesig.

Ich habe nun in wenigen Beiträgen von euch mehr erfahren, weil begriffen, als durch das
Lesen der ellenlangen Berichte bei CB und Co.
Danke!

Achja, habe ich bereits erwähnt, dass ich mich ganz doll freue?

[Sven77]

Beim Schadcode wird doch wohl mein Avira artig anspringen?!

Bei den letzten Angriffen brachten Avira und co. gerade mal gar nix, im Gegenteil, bei Wannacry verhinderten sie sogar teilweise den Killswitch. Antivirenprogramme haben ihre Daseinsbererchtigung aber eben genauso wie Mückenspray im Sumpf nur gegen Mücken und nicht gegen Alligatoren hilft

[Ganon]

Davon ist nicht auszugehen.
Code welcher die Meltdown/Specte Sicherheitslücke von Prozessoren im Visier hat, es quasi kaum als "Schadcode" zu identifizieren.

Hält aber die Schlangenöl-Hersteller nicht davon ab, was anderes zu behaupten: https://www.avira.com/de/intel-security-flaw ;D

[lumines]

Danke dir.
Ich nutze eine Version des FF ausschließlich fürs Banking. Dazu noch Nocript und ublock.
Der andere FF läuft zu diesem Zeitpunkt nicht. Evtl. war das keine schlechte Idee von mir
in der Vergangenheit?

Macht praktisch keinen Unterschied. Wenn nur einer der beiden Browser oder dein OS kompromittiert ist, ist sowieso schon alles verloren. Aus Privatsphäregründen kann das Sinn machen, aber an der allgemeinen Sicherheit ändert das nichts.

Wenn man heute maximale Sicherheit beim Surfen will, muss man Chrome mit aktiver Strict Site Isolation benutzen. Alles andere kann da aktuell nicht mithalten. Natürlich kannst du einfach pauschal JS blocken, aber wenn du nicht gerade jedes manuell zugelassene JS-Skript bei jedem neuen Aufruf neu auditierst, bringt dir das relativ wenig. Es ist nicht pauschal schlecht, nur nicht wirklich praktikabel zum normalen Surfen.

Beim Schadcode wird doch wohl mein Avira artig anspringen?!

Virenscanner schützen nur gegen ganz bestimmte Klassen von Schadcode (und selbst da nicht zuverlässig). Bei Sicherheitslücken in Software oder Hardware können Virenscanner praktisch gar nicht helfen. Sollen sie auch nicht. Virenscanner sind kein magischer Rundumschutz.

Hält aber die Schlangenöl-Hersteller nicht davon ab, was anderes zu behaupten: https://www.avira.com/de/intel-security-flaw ;D

Das ist absolut armselig und komplett irreführend für normale Nutzer.

[fp69]

Meine Freude kennt keine Grenzen mehr. Wenn ich noch 10-15 Min. länger eure Beiträge lese,
renne ich nackig auf die Straße und umarme jeden.

Als Hersteller eines AV-Progs. würde ich ebnfalls das Blaue vom Himmel lügen.
Aber meine Hoffnung als Nutzer stirbt zuletzt oder ich sterbe an Unterkühlung.

[Eisenoxid]

Wenn Du dir aber Meltdown/Spectre ausnutzenden Schadcode aus einer andern Quelle (Email, PDF, Office-Dokument, etc.) eingefängst, dann nützt dir der FF Patch gar nichts - dieser Schadcode kann dann weiterhin deinen ganzen Computer ausspähen, auch inkl. den Daten aus der Onlinebanking Session welche Du im Firefox am laufen hast.
So wie ich den Bug verstanden habe, würde es ja nichtmal was bringen die den Schadcode-enthaltende Datei in einer Sandbox auszuführen.

Hier ist das Ganze imo ganz gut für Leien erklärt: https://www.youtube.com/watch?v=ZkLjMm7Nu7s

[lumines]

Meine Freude kennt keine Grenzen mehr. Wenn ich noch 10-15 Min. länger eure Beiträge lese,
renne ich nackig auf die Straße und umarme jeden.

Panik sollte man nicht haben. Ich will hier jetzt auch nicht Chrome über den Klee loben, aber aktuell scheint es momentan der einzige Browser zu sein, der mit der Strict Site Isolation wirklich einen signifikanten Schutz gegen Spectre beim Surfen liefert.

Mildert natürlich alles nur ab, aber alle anderen Browser wurden davon ein bisschen überrannt, während Chrome das Problem mit einer einfachen Option stark abmildern kann. Das ist schon ein enormer Vorteil, der für die meisten Leute wahrscheinlich auch den meisten Nutzen hat.

Hier kann man übrigens mehr darüber lesen: https://www.chromium.org/Home/chromium-security/site-isolation

[Ganon]

Das ist absolut armselig und komplett irreführend für normale Nutzer.

Klar. Andere empfehlen sogar die Nutzung vom Internet Explorer, weil sie "andere Browser nicht schützen können". Kontext hier, dass die Browser die Plugins von AV-Herstellern blocken.

Ansonsten würde es mich nicht wundern, wenn man über die AV-Software auch Spectre-Angriffe führen kann. Die verbuddeln sich doch auch extrem ins System.

[Complicated]

Strict Site Isolation ist ja auch nichts anderes als ein erweiterter XSS-Schutz. Den selben Effekt hat man unter FF mit aktiviertem NoScript. Besonders ABE nützt hier sehr viel: https://noscript.net/abe/


The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections already provided by NoScript, by delivering a firewall-like component running inside the browser. This "firewall" is specialized in defining and guarding the boundaries of each sensitive web application relevant to the user (e.g. webmail, online banking and so on), according to policies defined either by the user himself, or by the web developer/administrator, or by a trusted 3rd party.

[Dicker Igel]

[immy;11599861']allerdings eine Intel Ivy CPU ... wo bleibt das Firmware-Update dafür? :(
Das wird nie kommen.

[even.de]

Die oft angesprochene, schlechte SSD Performance kann ich nicht bestätigen.

Nach dem Meltdown Windows Patch mit Bios 0802 von ASUS (MX Hero)
https://abload.de/thumb2/960evo500gb1tbnachmeln4rt8.png (http://abload.de/image.php?img=960evo500gb1tbnachmeln4rt8.png)

März 2017
https://abload.de/thumb2/as_ssd_960evo_superpiy5ufs.png (http://abload.de/image.php?img=as_ssd_960evo_superpiy5ufs.png)

SSDs sind auch im Laufe des Jahres nochmal deutlich voller geworden, weshalb die Leistung so absolut im Rahmen ist und ich eig. keinen Leistungsverlust sehe.

[Ganon]

Das wird nie kommen.

Laut Intel erst mal nur zurück bis Haswell, alles andere ist noch "schauen wir mal".

[Lord Wotan]

Laut Intel erst mal nur zurück bis Haswell, alles andere ist noch "schauen wir mal".
Und denn muss ja auch der Bordhersteller mitspielen, solange Microsoft das Firmware patch nicht über Windows verbreitet wie das Linux macht.

[Lord Wotan]

Intel® Atom™ Processor C Series
Intel® Atom™ Processor E Series
Intel® Atom™ Processor A Series
Intel® Atom™ Processor x3 Series
Intel® Atom™ Processor Z Series

Zu welcher Buchstabenserie gehört der Atom 330?

[lumines]

Strict Site Isolation ist ja auch nichts anderes als ein erweiterter XSS-Schutz. Den selben Effekt hat man unter FF mit aktiviertem NoScript. Besonders ABE nützt hier sehr viel: https://noscript.net/abe/

Der Unterschied ist, dass Strict Site Isolation direkt vom Browser erzwungen wird und man von der Chromium-Sandbox profitiert. Man muss auch keine Regeln selbst schreiben, die wieder Fehler enthalten können.

[lumines]

Zu welcher Buchstabenserie gehört der Atom 330?

Zu keiner von denen, weil er älter als die gelisteten Serien ist.

[Complicated]

Der Unterschied ist, dass Strict Site Isolation direkt vom Browser erzwungen wird Genau wie ABE - das Zitat sagt das doch eindeutig. Kein Unterschied.
The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections already provided by NoScript, by delivering a firewall-like component running inside the browser.

[Lord Wotan]

@ lumines
Danke für die Info. Dann ist ja wenigstens mein HTCP nicht betroffen.

@all
Eine News zu Klagen gegen Intel

https://www.pcwelt.de/a/meltdown-und-spectre-intel-kunden-verklagen-chip-giganten,3449312

[lumines]

Genau wie ABE - das Zitat sagt das doch eindeutig. Kein Unterschied.

Was ist an "firewall-like" bitte eindeutig? Noch vager geht es doch gar nicht. Wo kann ich sehen, dass es Webseiten komplett in eigenen Prozessen mit eigenen Sandboxen voneinander isoliert? Auf so tiefe Modifikationen am Browser haben Firefox-Extensions doch gar keinen Zugriff.

Läuft das überhaupt mit der neuen Webextension?

[Complicated]

Der Link ist doch dabei - das müssen wir doch hier nicht diskutieren.
Zumal "Strict Site Isolation" und "Application Boundaries Enforcer" das selbe in grün bedeuten.

Living inside the browser, the ABE component can take advantage of its privileged placement for enforcing web application boundaries, because it always knows the real origin of each HTTP request, rather than a possibly missing or forged (even for privacy reasons) HTTP Referer header, and can learn from user’s feedback.
Mit der neuen Web Extension ist es in die about:config gewandert

[][immy]

Ich frage mich grad ob die Horizon box die ich hab (mit Intel Atom Prozessor) jemals abgedichtet wird. Ein Router wäre ja schon ziemlich .. naja unschön wenn er offen wäre.

[lumines]

Was sollen mir die Zitate sagen? NoScript ist eine Firefox- / WebExtension und hat keinen Einfluss darauf, wie der Browser seine eigenen Prozesse behandelt. Es kann HTTP-Requests sehen und verwalten, aber das ist eine komplett andere Ebene.

Zumal "Strict Site Isolation" und "Application Boundaries Enforcer" das selbe in grün bedeuten.t

Es ist vollkommen anders implementiert. Das ist so, als ob ich sagen würde, dass eine CPU und ein Abakus exakt das gleiche Geräte wären, weil man mit beiden addieren kann.

[immy;11600062']Ich frage mich grad ob die Horizon box die ich hab (mit Intel Atom Prozessor) jemals abgedichtet wird. Ein Router wäre ja schon ziemlich .. naja unschön wenn er offen wäre.

Auf jeden Fall muss Intel oder die Hersteller bei den Puma-6-Plattformen ordentlich Patches backporten. Die Fritzbox 6490 hängt z.B. noch auf Kernel 2.6.39. Wenn AVM da tatsächlich nicht selbst hinterherhinkt, dann sind für Puma 6 schon sehr lange massive Backports nötig.

[Lord Wotan]

Eine Theorie warum Intel durch den Bug jahrelang AMD betrogen hat um die Leistungskrone
https://blog.fefe.de/?ts=a4ac7405

[kruemelmonster]

Laut Intel erst mal nur zurück bis Haswell, alles andere ist noch "schauen wir mal".

Schon eher "when it's done" als "schauen wir mal" da Supermicro bis zurück zur X8 Serie (Nehalem/Westmere) Microcode Updates rausbringen wird:
We are awaiting microcode updates for our X9 and X8 Generation Systems from the vendor.
Once these updates are made available we will post those updates here.
Quelle (https://www.supermicro.com/support/security_Intel-SA-00088.cfm)

Insofern kann man auch von Microcode Updates für Sandy und Ivy ausgehen, nur würde ich für entsprechende Boards keine offiziellen Bios Updates vom Hersteller mehr erwarten, das wird man sich bei Asus & Co wohl selber patchen dürfen.

[Complicated]

Es ist vollkommen anders implementiert. Das ist so, als ob ich sagen würde, dass eine CPU und ein Abakus exakt das gleiche Geräten wären, weil man mit beiden addieren kann.
Du schreibst einen Unsinn ohne zu wissen wie es implementiert ist. Lies mal beide Dokumente richtig. Nur weil das eine als ADDon hinzu gefügt wird heisst es nicht, dass nicht die selbe Funktion erfüllen kann. Der selbe Schutzmechanismus. Wenn man genau schaut ist es bei NoScript sogar besser implementiert. Und schon deutlich länger. Deine Chrome-Werbung ist kaum hilfreich zu dem Thema.

[Gipsel]

https://www.drwindows.de/news/meltdown-und-spectre-intel-veroeffentlicht-cpu-liste-und-verspricht-immunisierende-updates

Liste was alles betroffen ist, die frage ist, was davon gepatcht wird
[..]Die Liste gilt nur für Spectre v2 und ist wahrscheinlich noch nicht mal vollständig. Überdies betreffen Meltdown und vor allem Spectre v1 sicher auch noch deutlich ältere CPUs.

====================

Der Link ist doch dabei - das müssen wir doch hier nicht diskutieren.
Zumal "Strict Site Isolation" und "Application Boundaries Enforcer" das selbe in grün bedeuten.
Wie lumines schon sagte: Nein.
Strict Site Isolation in Chrome packt jeden Tab in seinen eigenen Prozeß (da Spectre aus diesem erst mal nicht rauskommt). Das kann NoScript gar nicht leisten. Das ist also klar etwas Anderes. NoScript (egal ob mit oder ohne ABE) attackiert das Problem von einer anderen Warte: Nämlich eben keine Scripte zuzulassen, die die Ausnutzung von Spectre (oder Meltdown) erlauben würden.

[scully1234]

[immy;11600062']Ein Router wäre ja schon ziemlich .. naja unschön wenn er offen wäre.

Gibts von der Seite eigentlich schon Infos, wie weit ist AVM mit der Untersuchung auf Lecks?

Edit:

alles was bisher zu lesen war ist das


Meltdown und Spectre – keine Angriffsmöglichkeit bei AVM-Produkten

AVM untersucht die aktuell unter den Namen Spectre und Meltdown bekannt gewordenen Sicherheitslücken bei Prozessoren und steht dazu im Austausch mit den Herstellern der von AVM verwendeten Chips. Derzeit sehen wir darin keine neuen Angriffsmöglichkeiten auf das Sicherheitskonzept von AVM-Produkten.

Um die Schwachstellen auszunutzen, müsste ein Angreifer in der Lage sein, seine Anwendung auf dem AVM-Produkt zur Ausführung zu bringen. Anders als bei Systemen mit offener Architektur und Zugang zum Betriebssystem ist es für unsere Produkte prinzipiell nicht vorgesehen, Anwendungen Dritter auszuführen.

[lumines]

Du schreibst einen Unsinn ohne zu wissen wie es implementiert ist. Lies mal beide Dokumente richtig. Nur weil das eine als ADDon hinzu gefügt wird heisst es nicht, dass nicht die selbe Funktion erfüllen kann. Der selbe Schutzmechanismus.

Mindestens seit Firefox Quantum fehlen die entsprechenden APIs: https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Add-on_SDK/Low-Level_APIs/loader_sandbox

Ich habe auch keine Ahnung, warum du andauernd auf die Webseite verweist. Da steht nichts zur konkreten Implementierung.

ABE wird gegen Spectre nicht helfen. Vielleicht hätte es mit der alten API dagegen geholfen, wenn man selbst Regeln für alle relevanten Webseiten geschrieben hätte, aber das spielt ja keine Rolle mehr. Man kann natürlich mit NoScript einfach in einem JavaScript-freien Web leben, aber das ist für normale Nutzer vollkommen irrelevant.

Gibts von der Seite eigentlich schon Infos, wie weit ist AVM mit der Untersuchung auf Lecks?

Edit:

alles was bisher zu lesen war ist das

Würde auch Sinn ergeben. Router führen sehr selten Code von Dritten aus. Es gibt so einige seltsame NAS- / Router-Hybride mit nachinstallierbaren Apps(?), aber das dürfte die absolute Minderheit sein.

[Complicated]

Also gut dann diskutieren wir es hier.
https://www.chromium.org/Home/chromium-security/site-isolation

Websites typically cannot access each other's data inside the browser, thanks to code that enforces the Same Origin Policy. Occasionally, security bugs are found in this code and malicious websites may try to bypass these rules to attack other websites. The Chrome team aims to fix such bugs as quickly as possible.
Das hat absolut GAR nichts mit anderen Tabs zu tun. Und wenn dem so wäre, dann wäre ABE deutlich weiter und besser implementiert, da es auch Schutz im selben Tab bietet (Ebenso wie Strict Site Isolation)

Wie eindeutig sollte das denn noch formuliert werden?
In Chrome 63 and later, turning on Site Isolation offers additional protection against a certain type of web browser security bug, called universal cross-site scripting (UXSS). Security bugs of this form would normally let an attacker bypass the Same Origin Policy, though they don't give the attacker complete control over the process. Site Isolation can help protect sites even when these UXSS bugs occur.
Hier wird nach Script-Herkunft getrennt und nicht nach Tabs.
Cross-site pages are always put into a different process, whether the navigation is in the current tab, a new tab, or an iframe (i.e., one web page embedded inside another).

[Complicated]

Ich habe auch keine Ahnung, warum du andauernd auf die Webseite verweist. Da steht nichts zur konkreten Implementierung.

ABE wird gegen Spectre nicht helfen. Vielleicht hätte es mit der alten API dagegen geholfen, wenn man selbst Regeln für alle relevanten Webseiten geschrieben hätte, aber das spielt ja keine Rolle mehr. Man kann natürlich mit NoScript einfach in einem JavaScript-freien Web leben, aber das ist für normale Nutzer vollkommen irrelevant.
ABE hat überhaupt nichts mit Javascript zu tun:
ABE rules, whose syntax is defined in this specification (pdf) (https://noscript.net/abe/abe_rules.pdf), are quite simple and intuitive, especially if you are familiar with firewall policies:
# This one defines normal application behavior, allowing hyperlinking # but not cross-site POST requests altering app status # Additionally, pages can be embedded as subdocuments only by documents from # the same domain (this prevents ClickJacking/UI redressing attacks) Site *.somesite.com Accept POST SUB from SELF https://secure.somesite.com Accept GET Deny
Man kann natürlich mit NoScript einfach in einem JavaScript-freien Web leben, aber das ist für normale Nutzer vollkommen irrelevant.
Genauso ein Unsinn. Whitelisting hat nichts mit Scriptfreiem Web zu tun. Du redest über Dinge die du nicht kennst.

[fp69]

@ lumines und Complicated

Danke für die Infos. Leider kann ich nicht beurteilen, wer nun Recht hat. Chrom scheint zumindest für Unerfahrene die bessere Wahl zu sein, wenn der Browser an sich egal ist.

[scully1234]

Würde auch Sinn ergeben. Router führen sehr selten Code von Dritten aus. Es gibt so einige seltsame NAS- / Router-Hybride mit nachinstallierbaren Apps(?), aber das dürfte die absolut Minderheit sein.

Danke:up:

Jetzt mus ich nur noch sehen wie es mit der Hausautomations Hardware bei JBMedia aussieht, werde vorerst mal alle Ports dicht machen nach außen

[Gipsel]

Also gut dann diskutieren wir es hier.
https://www.chromium.org/Home/chromium-security/site-isolation

Das hat absolut GAR nichts mit anderen Tabs zu tun.Warum zitierst Du nicht auch die folgenden Sätze, die beschreiben, was strict Site isolation tut?
Websites typically cannot access each other's data inside the browser, thanks to code that enforces the Same Origin Policy. Occasionally, security bugs are found in this code and malicious websites may try to bypass these rules to attack other websites. The Chrome team aims to fix such bugs as quickly as possible.

Site Isolation offers a second line of defense to make such attacks less likely to succeed. It ensures that pages from different websites are always put into different processes, each running in a sandbox that limits what the process is allowed to do. It also blocks the process from receiving certain types of sensitive documents from other sites. As a result, a malicious website will find it more difficult to steal data from other sites, even if it can break some of the rules in its own process.
Oder die Beschreibung direct aus dem Browser unter chrome://flags:
Strict site isolation
Highly experimental security mode that ensures each renderer process contains pages from at most one site. In this mode, out-of-process iframes will be used whenever an iframe is cross-siteCase closed.
Ich bin jetzt einfach mal davon ausgegangen, daß man verschiednen Webseiten in verschiedenen Tabs hat, was ja wohl der Normalfall sein sollte. Hat man zwei Tabs mit der gleichen Website auf, sind die nicht so isoliert, da die nicht in zwei getrennten Prozessen laufen (was ja auch irgendwie unsinnig wäre). Im Prinzip packt Chrome sogar verschiedene Frames einer Webseite in verschiedenen Prozesse, wenn die von unterschiedlichen Adressen kommen. Wie schon mehrfach festgestellt ist das etwas Anderes, als NoScript macht. Und verschiedene Prozesse helfen gegen Spectre (weil die dort nicht ohne Weiteres ausbrechen können).

[lumines]

ABE hat überhaupt nichts mit Javascript zu tun:

Ich habe JavaScript genannt, weil eben nur das im Kontext von Spectre wirklich relevant ist. Wenn du ein bisschen durch die Doku surfst, wird dir auch auffallen, dass da alles rund um Sandboxen mit dem neuen Extensions-Modell nicht mehr unterstützt wird. Die JS-Sandbox war nur ein Beispiel. Surf ein bisschen weiter, da ist alles in dem Bereich deprecated. NoScript / ABE müssen das also irgendwie anders umsetzen und sich signifikant von der Implementierung in Chrome / Chromium unterscheiden.

Mehr Zeit will ich da auch nicht investieren.

Genauso ein Unsinn. Whitelisting hat nichts mit Scriptfreiem Web zu tun. Du redest über Dinge die du nicht kennst.

:confused:

Das Whitelisting zeigt dir erst einmal ein skriptfreies Web, bis du eben Sachen selbst freigibst. Keine Ahnung, wie man das an meinem Post falsch verstehen kann.

[Complicated]

Site Isolation offers a second line of defense to make such attacks less likely to succeed. It ensures that pages from different websites are always put into different processes, each running in a sandbox that limits what the process is allowed to do. It also blocks the process from receiving certain types of sensitive documents from other sites. As a result, a malicious website will find it more difficult to steal data from other sites, even if it can break some of the rules in its own process. Weil das Resultat ein Schutz vor Crosssitescripting ist - es schützt aber nicht davor, dass jeder einzelne Prozess aus dem Cache gelesen wird durch eine entsprechend - auch im eigenen isolierten Prozess - ausgeführte Attacke. Denn auch isolierte Prozesse greifen auf ungeschützte branch prediction zu, wenn sie es denn wollen. Von daher ist das isolieren einzelner Webseiten in eigene Prozesse im OS irrelevant für Spectre. Auf CPU-Ebene kann dennoch jeder dieser Prozesse die branch prediction nutzen und den TLB/Cache unberechtigt lesen, falls das die Absicht ist.

Die zusätzliche Sicherheit entsteht lediglich durch verhindern von Crossite-Scripting. Klar ist das besser, aber nicht weil jede Webseite einen eigenen Prozess erhält. Spectre 1 (bounds check bypass) verändert keinen Code (der hier geschützt wäre) und die branch injection bei Spectre 2 erfolgt sowieso von einem eigenen Prozess aus. Meltdown wird ebenfalls über einen eigenen Prozess ausgeführt.

Also wo ist der Nutzen darin jede Webseite in ihrem eigenen Prozess auszuführen bei diesen Exploits? Sie lesen sowieso Daten von anderen Prozessen.

Das was schützt, ist wenn eine andere Webseite gar keinen Code ausführen darf, wenn das nicht gewollt ist. XSS-Schutz wird verbessert durch das aktivieren des Features.

Das Whitelisting zeigt dir erst einmal ein skriptfreies Web, bis du eben Sachen selbst freigibst. Keine Ahnung, wie man das an meinem Post falsch verstehen kann.Das war nicht falsch verstanden. Du hast lediglich die Behauptung aufgestellt NoScript=Javascriptfreies Web. Das ist nicht das selbe wie Whitelisting und selber bestimmen welche Scripts ausgeführt werden dürfen. Wenn man den Ausgangszustand als Dauerzustand gleichsetzt stimmt es einfach nicht.

[Gipsel]

@Complicated:
Du hast offenbar die Funktionsweise der drei Angriffsmethoden nicht komplett durchdrungen. Spectre v1 und v2 greifen nur auf Speicher zu, der dem Prozeß zugeordnet ist, der gerade Code ausführt (damit alleine kann man also nicht aus dem Prozeß ausbrechen). Per Meltdown kann dagegen direkt beliebiger physischer Speicher gelesen werden (solange er nur gemappt ist), über alle Grenzen hinweg.
Deswegen hilft eine Isolation per getrennten Prozessen sehr wohl gegen Spectre und zwar auf völlig andere Art, als es per NoScript geht.

[Sephiroth]

Haswell microcode 22h vs. 23h security (Spectre), performance and stability differences

http://www.overclock.net/t/1645289/haswell-microcode-22h-vs-23h-security-spectre-performance-and-stability-differences

OC Potential plötzlich auch im A...? Wow, bravo... also ich würde jetzt meine Intel CPU entsorgen wenn ich eine hätte :mad:
Ein paar Beiträge weiter heißt es auch, dass die Fehler seit dem Microcode Update auch ohne OC auftreten.

Wie ich schon mal hier geschrieben habe: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11597798

Ich würde prinzipiell keine Microcode-Updates verwenden, die nicht offiziell vom Anbieter auf deren Servern angeboten werden.
Die Updates sind inzwischen Offiziell -> https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?v=t

[Theo_Retisch]

Ich hab folgendes Tool benutzt, um mir anzeigen zu lassen, wie und ob ich betroffen bin - https://github.com/ionescu007/SpecuCheck

Nutze Win7 x64 mit dem aktuellsten Patches vom 08.01.2018
CPU is Sandybridge, also bisher ohne Microcodepatch.

Wie kann ich nun folgendes Ergebnis interpretieren:

https://img3.picload.org/image/ddldigwi/specu.jpg

[deekey777]

Hatten wir bestimmt schon, oder?
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/


With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds.
With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.
With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.
Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.

[kruemelmonster]

Ich hab folgendes Tool benutzt, um mir anzeigen zu lassen, wie und ob ich betroffen bin - https://github.com/ionescu007/SpecuCheck

Nutze Win7 x64 mit dem aktuellsten Patches vom 08.01.2018
CPU is Sandybridge, also bisher ohne Microcodepatch.

Wie kann ich nun folgendes Ergebnis interpretieren:

https://img3.picload.org/image/ddldigwi/specu.jpg

Gegen Meltdown bist du geschützt (rogue data cache load), allerdings mit gewissen (?) Performanceeinbußen da INVPCID fehlt. Gegen Spectre (branch target injection) durch ungepatchte Programme bist du mangels Microcode Update überhaupt nicht geschützt.

[joe kongo]

Hatten wir bestimmt schon, oder?
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/


With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds.
With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.
With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.
Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.


geile Sätze

"...because these percentages are reflected in milliseconds."
;D Benchmarks laufen ja nur wenige Millisekunden lang

"Windows 10 on older silicon ..."
"With Windows 8 and Windows 7 on older silicon ..."
:devil:

[Pirx]

Hatten wir bestimmt schon, oder?
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/


With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds.
With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.
With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance...

Da kann der Hersteller der weltweit sichersten Produkte ja viele neue CPUs verkaufen.

[mboeller]

Ein paar Beiträge weiter heißt es auch, dass die Fehler seit dem Microcode Update auch ohne OC auftreten.


Die Updates sind inzwischen Offiziell -> https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?v=t


sehe ich das richtig, dass Intel die Microcode-Updates bis zurück zum Pentium4 (oder älter) zur Verfügung stellt?

[Noebbie]

Da kann der Hersteller der weltweit sichersten Produkte ja viel neue CPUs verkaufen.

Mein Haswell wird dieses Jahr sehr wahrscheinlich durch einen Ryzen getauscht.

Ab jetzt bin ich mir sehr sehr sicher! :freak:

[Birdman]

With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.
With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance
Kann mir jemand erklären, wieso hier Microsoft einen Unterschied macht/sieht?
Bekommt Windows10 irgendwelche angepassten und optimierten Patches, welche den Performance-Malus minimieren?

[Rolsch]

Kann mir jemand erklären, wieso hier Microsoft einen Unterschied macht/sieht?
Bekommt Windows10 irgendwelche angepassten und optimierten Patches, welche den Performance-Malus minimieren?

Myerson erklärt auch, weshalb sich die Patches bei älteren Windows-Versionen stärker auswirken. Dort gebe es noch mehr Übergänge vom User- in den Kernel-Adressbereich, etwa weil das Rendering von Fonts noch im Kernel-Bereich erfolge.

https://www.heise.de/newsticker/meldung/Meltdown-Spectre-unter-Windows-Microsoft-detailliert-Patches-und-Leistungsschwund-3937462.html

[Pirx]

...und M$ kann besser seine neueste Spyware an den "Mann" bringen... Win-Win:ulol:

[StefanV]

Falls das noch nicht gepostet wurde:
http://openbsd-archive.7691.n7.nabble.com/Intel-Core-2-td43929.html

[Ganon]

sehe ich das richtig, dass Intel die Microcode-Updates bis zurück zum Pentium4 (oder älter) zur Verfügung stellt?

Nein. Nur weil das Paket von 2018 ist, heißt das nicht, dass auch alle Microcodes darin aus 2018 sind. Das ist so eine Sammelbox.

[Gipsel]

Falls das noch nicht gepostet wurde:
http://openbsd-archive.7691.n7.nabble.com/Intel-Core-2-td43929.htmlDa geht es zum einen um was Anderes und außerdem wurde das schon gepostet. Müllt den Thread doch nicht immer so zu!

[lumines]

Kann mir jemand erklären, wieso hier Microsoft einen Unterschied macht/sieht?
Bekommt Windows10 irgendwelche angepassten und optimierten Patches, welche den Performance-Malus minimieren?

Sie machen da wahrscheinlich gar keinen Unterschied. Die alten Versionen trifft es einfach nur schlimmer. 7 und 8 haben z.B. ihren Font-Renderer im Kernel. Nur ein einziges Beispiel, aber wahrscheinlich kosten die Patches bei solchen Sachen einfach mehr Leistung.

[Gipsel]

Zusammenfassung bezüglich der µCode-Patches von heise (https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Intel-patcht-ab-2013-produzierte-Prozessoren-bestaetigt-Performance-Auswirkung-3936956.html).

Nicht daß das meiste hier nicht schon im Thread stehen würde. Die µCode-Patches sind für Spectre v2 und sind nur in Verbindung mit entsprechenden Software-Updates wirksam, die die neuen Funktionen zielgerichtet nutzen.
Diese wäre IBRS (indirect branch reduced speculation), IBPB (indirect branch prediction barrier) und STIBP (single thread indirect branch prediction).

Auch von AMD gibt es offenbar µCode-Updates, die zumindest die ersten beiden Funktionen ebenfalls nachrüsten (auf K10 und Jaguar-basierten CPUs kann die IBRS-Funktionalität schon immer kontrolliert werden [allerdings offenbar nur global beim Boot], benötigen also kein µCode-Update dafür und eine normaler lfence wirkt wohl auch als Spekulations-Barriere). Wie das genau für Bulldozer- und Ryzen-CPUs im Detail funktioniert, ist mir aber nicht bekannt.

STIBP ist auf AMD eventuell redundant (auf denen ohne SMT bzw. geteilte Sprungvorhersage für zwei Threads ja sowieso), da zumindest Teile der Branch prediction schon immer nach Thread unterscheidet (für den Return Adress Stack ist es z.B. im Optimization Manual erwähnt), da fehlen mir aber Details, um das sicher sagen zu können. Allgemein soll dieses Feature verhindern, daß der zweite Thread auf einem Kern die (indirekte) Sprungvorhersage des ersten Threads beeinflussen kann (könnte für simultanes gezieltes Fehl-Training der Sprungvorhersage durch einen Thread [Angreifer], während der andere Thread den Target-Code ausführt, genutzt werden).

Und wir haben natürlich immer noch AMDs Aussage, daß es aufgrund der anderen Architektur der Sprungvorhersage sehr schwierig sein soll (also schwieriger als bei intel) Spectre v2 überhaupt auszunutzen ("near zero risk"). Worauf sich das genau gründet, ist mir aber auch noch nicht bekannt (ein paar Möglichkeiten wurden hier im Thread ja glaube ich schon genannt, z.B. das AMD indirect Target predictor auch die Adresse [des Codes] des Branches nutzt, um die möglichen Targets einzugrenzen; man muß also die Codeadresse des Branches, der zum Fehltraining genutzt wird mit der Adresse des angegriffenen Branches alignen [wie genau ist unklar, bei intel ist das offenbar nicht unbedingt nötig*]).

*: Aus dem Spectre-Paper zu den Beobachtungen des indirect branch target predictors bei intel-CPUs:
For both history matching and predictions, the branch predictor only appears to pay attention to branch destination virtual addresses. The source address of the instruction performing the jump, physical addresses, timing, and process ID do not appear to matter.

[uweskw]

Zusammenfassung bezüglich der µCode-Patches von heise (https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Intel-patcht-ab-2013-produzierte-Prozessoren-bestaetigt-Performance-Auswirkung-3936956.html).

Nicht daß das meiste hier nicht schon im Thread stehen würde. Die µCode-Patches sind für Spectre v2 und sind nur in Verbindung mit entsprechenden Software-Updates wirksam, die die neuen Funktionen zielgerichtet nutzen.
Diese wäre IBRS (indirect branch reduced speculation), IBPB (indirect branch prediction barrier) und STIBP (single thread indirect branch prediction).

Auch von AMD gibt es offenbar µCode-Updates, die zumindest die ersten beiden Funktionen ebenfalls nachrüsten (auf K10 und Jaguar-basierten CPUs kann die IBRS-Funktionalität schon immer kontrolliert werden [allerdings offenbar nur global beim Boot], benötigen also kein µCode-Update dafür und eine normaler lfence wirkt wohl auch als Spekulations-Barriere). Wie das genau für Bulldozer- und Ryzen-CPUs im Detail funktioniert, ist mir aber nicht bekannt.

STIBP ist auf AMD eventuell redundant (auf denen ohne SMT bzw. geteilte Sprungvorhersage für zwei Threads ja sowieso), da zumindest Teile der Branch prediction schon immer nach Thread unterscheidet (für den Return Adress Stack ist es z.B. im Optimization Manual erwähnt), da fehlen mir aber Details, um das sicher sagen zu können. Allgemein soll dieses Feature verhindern, daß der zweite Thread auf einem Kern die (indirekte) Sprungvorhersage des ersten Threads beeinflussen kann (könnte für simultanes gezieltes Fehl-Training der Sprungvorhersage durch einen Thread [Angreifer], während der andere Thread den Target-Code ausführt, genutzt werden).

Und wir haben natürlich immer noch AMDs Aussage, daß es aufgrund der anderen Architektur der Sprungvorhersage sehr schwierig sein soll (also schwieriger als bei intel) Spectre v2 überhaupt auszunutzen ("near zero risk"). Worauf sich das genau gründet, ist mir aber auch noch nicht bekannt (ein paar Möglichkeiten wurden hier im Thread ja glaube ich schon genannt, z.B. das AMD indirect Target predictor auch die Adresse [des Codes] des Branches nutzt, um die möglichen Targets einzugrenzen; man muß also die Codeadresse des Branches, der zum Fehltraining genutzt wird mit der Adresse des angegriffenen Branches alignen [wie genau ist unklar, bei intel ist das offenbar nicht unbedingt nötig*]).

*: Aus dem Spectre-Paper zu den Beobachtungen des indirect branch target predictors bei intel-CPUs:

Also ist bei AMD nur eines von drei Einfallstoren offen, und auch das nur unter ganz bestimmten Umständen.
Das Windows 7 und 8 mit Intel-Prozessoren mehr an Performance verliert als Windows 10 leuchtet mir ja noch ein, aber warum ist das auch bei älteren Intel Prozessoren so?
Oder soll dadurch einfach nur der Absatz gepusht werden?
Greetz
US

[Birdman]

Windows 10 leuchtet mir ja noch ein, aber warum ist das auch bei älteren Intel Prozessoren so?
Wegen des PCID Features welches wohl einen Teil des Performanceverlustes abfangen kann.
Ab welcher CPU Generation dies aber der Fall ist, scheint noch etwas in der Schwebe zu sein - einige schreiben ab Haswell, andere schreiben was von Westmere und ich selber vermute aktuell aber eher ab Sandy Bridge.
(siehe dazu auch die PCID feature flag Diskusion auf den letzen paar Seiten dieses Threads)

[Ganon]

Statt weiter zu rätseln habe ich mal nachgesehen :D

https://patchwork.kernel.org/patch/10035481/



Support:

PCIDs are generally available on Sandybridge and newer CPUs. However,
the accompanying INVPCID instruction did not become available until
Haswell (the ones with "v4", or called fourth-generation Core). This
instruction allows non-current-PCID TLB entries to be flushed without
switching CR3 and global pages to be flushed without a double
MOV-to-CR4.

Without INVPCID, PCIDs are much harder to use.

[...]

So, for now, we fully disable PCIDs with KAISER when INVPCID is
not available. This is fixable, but it's an optimization that
we can do later.


Das gilt natürlich nur für Linux. Was MS macht, steht auf einem anderen Blatt.

edit: Weiter unten steht auch noch, dass PCID für andere Performance-Sachen auch noch benutzt wird, unabhängig von INVPCID

[Mr. Lolman]

Gibts schon irgendwo Benchmarks für Haswell CPUs?

Wegen des PCID Features welches wohl einen Teil des Performanceverlustes abfangen kann.
Ab welcher CPU Generation dies aber der Fall ist, scheint noch etwas in der Schwebe zu sein - einige schreiben ab Haswell, andere schreiben was von Westmere und ich selber vermute aktuell aber eher ab Sandy Bridge.
(siehe dazu auch die PCID feature flag Diskusion auf den letzen paar Seiten dieses Threads)


With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.

https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/

[Ganon]

Gibts schon irgendwo Benchmarks für Haswell CPUs?

Statt jeden Tag zu benchmarken, würde ich erst mal warten bis sämtliche Microcode- und Software-Updates auch ausgerollt sind.

[Birdman]

@Ganon

Hmpf, auch wenn dieser Post von der Kernel-Maintainer Liste etwas Licht ins Dunkel bringt - die Aussage von Microsoft dass es es bereits bei und mit Haswell CPUs mehr Performance kostet, lässt mich darauf schliessen, dass hier mehr als nur PCID, btw. INVPCID im Spiel sein muss, zumindest beim Patch für Windows.

[Corny]

Ich verliere aktuell ein bisschen die Übersicht.

Kann das Betriebssystem mit den entsprechenden Updates die Sicherheit von älteren CPUs z.B. Sandy Bridge, oder ein alter Core2Duo noch gewährleisten? Oder bleiben die Lücken mangels Microcode Updates ungefixt?

[Ganon]

Die Aussage oben betrifft ja nur Aussagen zur Performance von Meltdown. Dass Fixes für Spectre V1 und V2 auch Performance kosten, darf man nicht vergessen. Hier hängt es dann davon ab wie a) Intel die Microcode Updates umsetzt und b) die Software darauf reagiert. Weiterhin muss für Spectre Variant 1 fixes die Software auch noch selbst neu kompiliert werden.

Googles (noch unfertiges) Retpoline für Linux für Spectre Variant 1 und Variant 2 haut halt, je nach CPU auch noch mal rein. Aber mangels Microcode Updates für alle Intel CPUs (z.B. Haswell fehlt wohl noch), bringt halt hier benchmarken nichts.

Darum meine Aussagen oben -> erst mal darauf warten bis alles fertig ist. Und wie Microsoft das Ganze umgesetzt hat kann man halt so ohne weiteres nicht nachschauen. Das wird Rätselraten bleiben.

Kann das Betriebssystem mit den entsprechenden Updates die Sicherheit von älteren CPUs z.B. Sandy Bridge, oder ein alter Core2Duo noch gewährleisten? Oder bleiben die Lücken mangels Microcode Updates ungefixt?

Gegen Meltdown ja, gegen Spectre teils teils, Tendenz zu nein. Es hat auch niemand das Verhalten von allen alten CPUs gegen Spectre getestet. edit: Zur weiteren groben Erklärung: Die CPUs brauchen eine neue Anweisung, dass sie bitte an bestimmten Stellen das spekulieren einstellen und einfach das tun was ihnen gesagt wird. Tun sie das nicht, ist man softwareseitig stellenweise machtlos. Bei AMD reicht dafür eine bereits bestehende Anweisung.

[Gipsel]

Also ist bei AMD nur eines von drei Einfallstoren offen, und auch das nur unter ganz bestimmten Umständen.
Eins ist offen wie bei allen CPUs mit spekulativer Ausführung, das zweite könnte theoretisch genutzt werden, wenn bestimmte (noch unbekannte) Umstände zusammen kommen. Es soll schwieriger aber nicht theoretisch unmöglich sein, das auszunutzen.

[Corny]

Gegen Meltdown ja, gegen Spectre teils teils, Tendenz zu nein. Es hat auch niemand das Verhalten von allen alten CPUs gegen Spectre getestet. edit: Zur weiteren groben Erklärung: Die CPUs brauchen eine neue Anweisung, dass sie bitte an bestimmten Stellen das spekulieren einstellen und einfach das tun was ihnen gesagt wird. Tun sie das nicht, ist man softwareseitig stellenweise machtlos. Bei AMD reicht dafür eine bereits bestehende Anweisung.

Oder anders gesagt: mit etwas Pech ist jeder PC mit Intel CPU Baujahr 2013 und älter Elektroschrott :eek:

Aber mal abwarten wie es tatsächlich kommt, ich bin sicher, dass sich dahingehend in den nächsten Wochen noch einiges tut.

[stimulator]

Vor allem da SB-E wie z.B. ein i7-3930K noch vollständig brauchbar wäre ;(

[Complicated]

@Complicated:
Du hast offenbar die Funktionsweise der drei Angriffsmethoden nicht komplett durchdrungen. Spectre v1 und v2 greifen nur auf Speicher zu, der dem Prozeß zugeordnet ist, der gerade Code ausführt (damit alleine kann man also nicht aus dem Prozeß ausbrechen).
Ich denke du unterliegst hier einem Irrtum oder bist nicht in vollem Umfang informiert. Siehe:
https://github.com/marcan/speculation-bugs/blob/master/README.md#bti-branch-target-injection
Branch Target Injection

Google name: Variant 2: Branch target injection
Research name: Spectre
CVE: CVE-2017-5715
The CPU indirect branch predictor can be "trained" to mis-predict an indirect branch into an attacker-controlled destination. This can then leak data via the cache. Chaining multiple gadgets ending in indirect branches, ROP-style, is possible.
This attack requires intimate knowledge of the inner workings of the CPU branch prediction implementation. This does not mitigate the attack, but does make exploitation more difficult (and makes cross-platform attacks much harder).
Attack scenarios



JIT: Tricky, but probably possible with careful instruction massaging?
[B]Same-cpu cross-process: Possible. Includes attacks on the kernel/hypervisor.
Remote/server: Not possible.


Es gibt eben nicht nur ein Szenario für die jeweiligen Exploits. Deswegen spricht auch Googel von Mitigations und nicht von Fixes.

Das Thema ist einfach, dass nicht jeder Prozess eine eigene branch prediction erhält:
Ideally future CPUs would guarantee that hyperthreads have independent branch prediction resources to avoid sharing state, and/or would have efficient methods of isolating branch prediction state (e.g. tagging prediction entries with a process/protection key).

Ergänzend für V1 aus selber Quelle, der Vollständigkeit halber:
[MISPREDICT] Branch mis-prediction leaks subsequent data

Google name: Variant 1: Bounds check bypass
Research name: Spectre
CVE: CVE-2017-5753

The CPU mispredicts a branch and speculatively executes code which leaks sensitive data into a data cache load.

[...]

The attacker need not necessarily control arr2 directly. Cache loads can be detected indirectly, e.g. because they caused some other data to be evicted. This can potentially work from an entirely different process.
Attack scenarios


JITs/interpreters: Easy. Sandbox escape (same-context leak). Shared memory/threads make it easier.
Same-CPU cross-process: Medium. Attacker needs to trigger the vulnerable code in the vulnerable process, then get a signal from the cache directly (e.g. by timing accesses to memory which has colliding cache tags on the same CPU core or sharing a level of cache). This includes attacks on the kernel and on hypervisors.
Remote/service: Hard. Attacker needs some way of triggering the vulnerable code, then getting a timing signal back from the relevant cache lines. Probably not practical in most circumstances.



Edit:
Hier steht sogar der konkrete Nutzen für Site Isolation - wie ich sagte ein XSS-Patch. Es hilft lediglich gegen das Angriffszenario mit JIT.
Google Chrome

Actions Required to Mitigate Speculative Side-Channel Attack Techniques

Enable Site Isolation in chrome://flags to prevent cross-origin exploitation of same-process vulns (e.g. JIT).

Starting with Chrome 64, the V8 JS engine will have additional mitigations (which?). Also SharedArrayBuffer is being disabled. This makes the attacks harder (but is not a perfect fix).

[Ganon]

Oder anders gesagt: mit etwas Pech ist jeder PC mit Intel CPU Baujahr 2013 und älter Elektroschrott :eek:

Nicht unbedingt. Im Heimbereich ist die Gefahr, die von Spectre ausgeht, überschaubar. Chromes Site Isolation, Script- und Adblocker, Hirn einschalten bei der Installation von Software...

Damit man von Meltdown und Spectre betroffen werden kann, muss man sich bereits etwas einfangen und Meltdown ist bereits gefixt.

[Theo_Retisch]

Gegen Meltdown bist du geschützt (rogue data cache load), allerdings mit gewissen (?) Performanceeinbußen da INVPCID fehlt. Gegen Spectre (branch target injection) durch ungepatchte Programme bist du mangels Microcode Update überhaupt nicht geschützt.

Okidoki, danke dafür!

[Gipsel]

Ich denke du unterliegst hier einem Irrtum oder bist nicht in vollem Umfang informiert. Siehe:
https://github.com/marcan/speculation-bugs/blob/master/README.md#bti-branch-target-injection

Es gibt eben nicht nur ein Szenario für die jeweiligen Exploits. Deswegen spricht auch Googel von Mitigations und nicht von Fixes.Ich weiß wie das funktioniert (auch noch deutlich detaillierter als von Dir zitiert) ;). Deswegen könnte ich Dir hier auch erklären (ich habe das im Thread bereits an anderer Stelle erwähnt), wie man mit Spectre v2 an Kernel-Speicher herankommen kann (kurz: man benötigt Syscalls, die dann ja Code im Kernel-Kontext ausführen), allein es würde am Thema vorbei gehen. Von irgendeinem Skript im Browser kommt man damit aber trotzdem nicht aus dem Prozeß raus bzw. an Daten aus anderen Prozessen ran (und wenn das OS entsprechend gepatched ist, kommt man auch nicht mehr an Daten aus dem Kernel), schlicht weil man doch hoffentlich nicht die Ausführung von bestimmtem Code dort triggern kann. Denn prinzipiell gilt für Spectre, daß eben keine direkte (auch nur spekulative) Verletzung von Zugriffsprivilegien stattfindet. Um an andere Prozesse ranzukommen, muß man diese anderen Prozesse irgendwie kontrollieren.
Um also jetzt Daten in einem Tab des Browsers (z.B. mit Online-Banking) von einem anderen Tab mit dem Angreifer-Script abzuschotten, hilft es enorm, wenn der Browser die beiden Tabs in separaten Prozessen rendert.
Das Thema ist einfach, dass nicht jeder Prozess eine eigene branch prediction erhält::confused:
Prozeß ist nicht gleich Thread. STIBP (so nennt intel das Feature, was Du da erwähnst) macht es etwas schwieriger und schützt vor dem Szenario, welches ich bereits oben in dem Post zu den µCode-Updates oben erwähnte. Fehltraining und dann sequentielle Ausführung zweier Prozesse auf einem Kern funktioniert aber auch (wurde auch demonstriert).
Ergänzend für V1 aus selber Quelle, der Vollständigkeit halber:Da steht ja sogar das, was ich Dir versuche zu erklären ("Attacker needs to trigger the vulnerable code in the vulnerable process"). ;)

[IC3M@N FX]

Auf die Gefahr hin das es schon gefragt wurde und beantwortet wurde, entschuldige ich mich nochmal.
Wie sieht es mit Meltdown & Spectre bei den Konsolen aus PS4, Xbox One und Nintendo Switch?

Da alle Systeme eigene Betriebssysteme nutzen und abgeschottet sind ist da die Gefahr doch viel geringer und AMD/Nvidia Hardware soll ja kaum oder gar nicht betroffen sein oder?

[Complicated]

Was ist an cross-process denn unklar?
Und was ist unklar daran, dass Googles Site Isolation lediglich ein Schutz gegen Crosssite-Scripting ist? Du bist der erste der nun Threads hier erwähnt. Weder ich noch die Quelle hat Threads auch nur erwähnt. Soll das nun in eine Diskussion um Begrifflichkeiten ausgeweitet werden was Threads und Prozesse sind?
("Attacker needs to trigger the vulnerable code in the vulnerable process")Da steht das der anfällige Code getriggert werden muss. Dieser Trigger muss nicht aus dem selben Prozess stammen.

Da es um Chromes Site Isolation ging, können wir das nun auch sein lassen, da nun klar ist was das unterbindet: XSS.

[dargo]

Wurde das schon gepostet?
https://www.youtube.com/watch?time_continue=1&v=LC1WuKdPVCQ

In Witcher 3 gibt es bis zu -16% Leistung nach dem Windows-/ und Biospatch mit einem i5-8400. Das ist nicht gerade wenig.

[Pirx]

hmm andere sagen, es kostet quasi nichts
komisch

[Ganon]

hmm andere sagen, es kostet quasi nichts
komisch

Gucke einfach das ganze Video. ;) Es bleibt so wie es schon immer war: Man kann nicht "X % langsamer" auf das Thema drücken. Man muss von CPU zu CPU und von Software zu Software unterscheiden.

[dargo]

Die Frage müsste eher lauten was die anderen da überhaupt testen? :D Wenn die Szenen zum Teil im leichten GPU-Limit sind wird der Verlust sich natürlich in Grenzen halten bis gar nicht vorhanden sein. Mir kommt das aber auch so vor, dass Witcher 3 hier besonders stark darauf reagiert im Vergleich zu anderen Games. Und, dass Coffee Lake hier am meisten Federn lassen muss. Hassi verliert so wie es aussieht weniger. Wobei es beim Hassi nur den Windowspatch und keinen Biospatch im Test gibt.

PS: auch ist für mich noch unklar ob DF da im vollständigen CPU-Limit @1080p vergleicht.

[Pirx]

kann auf Arbeit nur ohne Ton gucken:D
ups


Die Frage müsste eher lauten was die anderen da überhaupt testen? :D Wenn die Szenen zum Teil im leichten GPU-Limit sind wird der Verlust sich natürlich in Grenzen halten bis gar nicht vorhanden sein...
Jupp
Ich sehe eine grooße Welle neuer 720p-Benches auf uns zukommen.:D

[Complicated]

FAQ bei heise:
https://www.heise.de/newsticker/meldung/FAQ-zu-Meltdown-und-Spectre-Was-ist-passiert-bin-ich-betroffen-wie-kann-ich-mich-schuetzen-3938146.html
15. Sind die Sicherheitslücken aus der Ferne (remote) nutzbar?

Nur indirekt: Ein Angreifer muss Schadcode auf dem betroffenen System ausführen. Deshalb ist die Lücke in vielen Embedded Systems und Routern unkritisch. Besonders gefährdet sind hingegen Web-Browser: Sie laden Code herunter und führen ihn aus (JavaScript, HTML 5). Schadcode könnte beispielsweise über unseriöse Webesiten eingeschleust werden. Dagegen helfen Browser-Updates und Script-Blocker wie NoScript.
Ach....

[Gipsel]

Was ist an cross-process denn unklar?Also mir gar nichts.
Und was ist unklar daran, dass Googles Site Isolation lediglich ein Schutz gegen Crosssite-Scripting ist?Nein. Es behindert auch die Ausnutzung von Spectre-Exploits aus dem Browser, weil man damit eben nicht auf Speicher eines anderen Prozesses (z.B. anderer Tab mit der Banking-Website) zugreifen kann (solange gewährleistet ist, daß man nicht die Ausführung von Code des anderen Prozesses gezielt triggern kann).
Du bist der erste der nun Threads hier erwähnt. Weder ich noch die Quelle hat Threads auch nur erwähnt.Da schaust Du besser noch mal genauer! Dein Zitat, auf was ich mich bezog, erwähnte die SMT-Threads auf einem Core, woraus Du gemacht hast, daß jeder Prozeß seine eigene Branch Prediction bekommen soll (was schlicht eine falsche Interpretation des dort von Dir Zitierten ist). ;)
Soll das nun in eine Diskussion um Begrifflichkeiten ausgeweitet werden was Threads und Prozesse sind?Ich mußte lediglich feststellen, daß Dir die Unterschiede offenbar nicht geläufig sind.
Da steht das der anfällige Code getriggert werden muss. Dieser Trigger muss nicht aus dem selben Prozess stammen.Der Angreifer-Code muß das im angegriffenen Prozeß triggern können. Sonst ist eine gezielte Attacke schwer möglich.
Da es um Chromes Site Isolation ging, können wir das nun auch sein lassen, da nun klar ist was das unterbindet: XSS.Du kannst auch einfach zugeben, daß Chromes "Strict Site Isolation" das Problem auf eine deutlich andere Weise angeht (verschiedene Sites in verschiedenen Prozessen rendern) als NoScript :rolleyes:. Das ist also bezüglich Spectre alles andere als äquivalent.
NoScript: Schadcode kann nicht ausgeführt werden (eventuell unbequem, da man erst mal überall Scripte manuell wieder freigeben muß)
Strict Site Isolation: Potentieller Schadcode wird zwar ausgeführt (bequem), kommt aber nicht an die gewünschten Daten ran (zumindest nicht ohne zusätzliche Ansätze/Lücken).
Und das wurde Dir auch von Anfang an so gesagt (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11600096#post11600096).

[Complicated]

Gipsel du solltest das überdenken denn du bist im Unrecht:
https://www.heise.de/newsticker/meldung/Analyse-zur-Prozessorluecke-Meltdown-und-Spectre-sind-ein-Security-Supergau-3935124.html?seite=2
Mit dem Szenario „Spectre“ haben die gleichen Autoren einen weiteren Angriff gestartet, bei dem das Kernel-Mapping nicht benötigt wird, und der infolgedessen weder mit KPTI noch mit Hardsplit begegnet werden kann. Er beschänkt sich vorerst zwar nur auf den User-Prozess selber – doch auch das kann äußerst kritisch sein, wenn man zum Beispiel mit Javascript auf beliebige Speicherbereiche des Browsers zugreifen kann – und das geht sowohl bei Intel, AMD und ARM (Liste der betroffenen Prozessoren). Die Autoren verwenden hier nicht den Exception-Trick, sondern auf „miss“ trainierte bedingte oder indirekte Sprünge, hinter denen die transienten Befehle kommen. Die greifen nicht direkt auf Speicher zu, sondern missbrauchen dafür passende Codefragmente in Shared Libaries oder Windows-DLLs, etwa aus ntdll.dll. Dahinter patchen sie einen Return-Befehl und über etwas verschlungene Pfade sorgen sie dafür, dass das Codefragment mit vorgegebenen Registerinhalten transient ausgeführt wird. So können sie den kompletten Speicher im Working-Set des angegriffenen Prozesses durchsuchen, bei Firefox 56 etwa nach zwischengespeicherten Passwörter, die im Klartext im Speicher liegen ...

[Gipsel]

Gipsel du solltest das überdenken denn du bist im Unrecht:
https://www.heise.de/newsticker/meldung/Analyse-zur-Prozessorluecke-Meltdown-und-Spectre-sind-ein-Security-Supergau-3935124.html?seite=2
Mit dem Szenario „Spectre“ haben die gleichen Autoren einen weiteren Angriff gestartet, bei dem das Kernel-Mapping nicht benötigt wird, und der infolgedessen weder mit KPTI noch mit Hardsplit begegnet werden kann. Er beschänkt sich vorerst zwar nur auf den User-Prozess selber – doch auch das kann äußerst kritisch sein, wenn man zum Beispiel mit Javascript auf beliebige Speicherbereiche des Browsers zugreifen kann – und das geht sowohl bei Intel, AMD und ARM (Liste der betroffenen Prozessoren).Und jetzt überlege mal, was passiert, wenn das eben nicht mehr Alles im selben Prozeß läuft sondern Alles jeweils in einem eigenen (wie mit Strict Site Isolation). Und was Du gefettet hast, geht mit JavaScript aus dem Browser eher nicht so ganz. ;)

Es macht eben doch was Anderes als NoScript. Und das war der Punkt. Es ist kein Allheilmittel (niemand hat es als das verkauft), aber es erschwert die Ausnutzung von Spectre doch schon deutlich (und das sehr bequem).

[Complicated]

Du kannst auch einfach zugeben, daß Chromes "Strict Site Isolation" das Problem auf eine deutlich andere Weise angeht (verschiedene Sites in verschiedenen Prozessen rendern) als NoScript :rolleyes:. Das ist also bezüglich Spectre alles andere als äquivalent.
Es ist äquivalent, denn beide verhindern XSS in diesem Kontext. Und nichts weiter darüber hinaus macht Strict Site Isolation hier besser für diese Exploits oder sicherer dagegen. Ich habe nichts anderes geschrieben.

[Ganon]

Wer Linux benutzt: hier erstellt gerade jemand ein Skript, welches ähnlich nach den Anfälligkeiten prüft, wie das Skript von Microsoft für Windows:

https://github.com/speed47/spectre-meltdown-checker

[Complicated]

Und jetzt überlege mal, was passiert, wenn das eben nicht mehr Alles im selben Prozeß läuft sondern Alles jeweils in einem eigenen (wie mit Strict Site Isolation). ;).Das spielt für Spectre keine Rolle - sobald das Javascript auf der CPU ausgeführt wird kann es den Exploit ausführen unabhängig davon ob es einen eigenen Prozess hat.

[Gipsel]

@Complicated:
Glaube doch, was Du willst. Ich meine aber einschätzen zu können, daß Du nicht ganz so viel Ahnung von der Materie hast, wie Andere hier im Thread (die auch schon aufgegeben haben, mit Dir zu diskutieren). Du gehst schlicht nicht auf fundierte Argumente ein und verstehst sie offenbar teilweise noch nicht mal (richtig). Geh mal ein wenig in Dich!

[Ex3cut3r]

Die Frage müsste eher lauten was die anderen da überhaupt testen? :D Wenn die Szenen zum Teil im leichten GPU-Limit sind wird der Verlust sich natürlich in Grenzen halten bis gar nicht vorhanden sein. Mir kommt das aber auch so vor, dass Witcher 3 hier besonders stark darauf reagiert im Vergleich zu anderen Games. Und, dass Coffee Lake hier am meisten Federn lassen muss. Hassi verliert so wie es aussieht weniger. Wobei es beim Hassi nur den Windowspatch und keinen Biospatch im Test gibt.

PS: auch ist für mich noch unklar ob DF da im vollständigen CPU-Limit @1080p vergleicht.

Ich rechne bei meinem Haswell mit BIOS (wenns überhaupt kommt) + Win Update mit -20%. Schon jetzt nur mit Win Patch komme ich in BF1 auf -8% natürlich @ 720p.

[Lurtz]

Das spielt für Spectre keine Rolle - sobald das Javascript auf der CPU ausgeführt wird kann es den Exploit ausführen unabhängig davon ob es einen eigenen Prozess hat.
Das klingt hier anders:
The underlying technical problem is that once you've achieved arbitrary read/write you can almost completely violate data-flow integrity within the process. As I recently wrote, DFI is extremely important and (unlike CFI) it's probably impossible to dynamically enforce with low overhead in the presence of arbitrary read/write, with any reasonable granularity.
http://robert.ocallahan.org/2017/10/microsofts-chrome-exploitation-and.html

Siehe auch den Wortwechsel mit Peter Kasting.

[Ludi]

Es ist kein Allheilmittel (niemand hat es als das verkauft), aber es erschwert die Ausnutzung von Spectre doch schon deutlich (und das sehr bequem).
Ich weiß zwar, was du meinst, aber das ist leider schlecht formuliert. Die Ausnutzung von Specture wird ja nicht erschwert, wenn JavaScript (oder der ganze Tab) in einem eigenen Prozess läuft. Es sind nur schlicht keine interessanten Daten in dem Prozess vorhanden, die es lohnt auszulesen, da diese vermutlich in einem isolierten Bereich des Hauptprozesses abgelegt sind (der vermutlich JavaScript-Verbot hat :)).

Von daher erschwert es das Auslesen von wichtigen Daten, aber nicht die Attacke an sich.

[Gipsel]

Ich weiß zwar, was du meinst, aber das ist leider schlecht formuliert. Die Ausnutzung von Specture wird ja nicht erschwert, wenn JavaScript (oder der ganze Tab) in einem eigenen Prozess läuft. Es sind nur schlicht keine interessanten Daten in dem Prozess vorhanden, die es lohnt auszulesen, da diese vermutlich in einem isolierten Bereich des Hauptprozesses abgelegt sind (der vermutlich JavaScript-Verbot hat :)).

Von daher erschwert es das Auslesen von wichtigen Daten, aber nicht die Attacke an sich.So war das selbstredend gemeint. Der Angreifer will ja wichtige Daten abgreifen, sonst ist es für ihn nutzlos ;). Daß das nicht verhindert, innerhalb des Prozesses weiterhin was zu lesen, habe ich wohl schon zum Ausdruck gebracht. Nur ist das eben im Zweifelsfall nur sein eigener kleiner Frame, in dem irgendein Adbanner versucht irgendein bösartiges Script laufen zu lassen, welches dann wie Du richtig sagst, keinen Zugriff auf den Hauptframe im Tab oder sonst irgendwas Wichtiges hat.

@Lurtz: Da geht es nicht unbedingt um die Eigenarten von Spectre. Allerdings wird auch da argumentiert, daß die getrennten Prozesse zusätzliche Sicherheit generieren (auch gegen andere Angriffe).

[Gecko_0815]

Frage an die Experten: Ist ein Pentium G3220 auf einem H81M-Plus auch betroffen? In der Intelliste habe ich ihn nicht gefunden. Nur Pentium J + N.

[unl34shed]

Ja, ist ein Haswell

[Nitrojedi]

Für alle Sysadmins unter euch: Habe heute die Patchzyklen für 1000 Clients über WSUS/SCCM-SUP definiert und dabei folgendes festgestellt:
Der Spectre&Meltdown Patch für Win 10 1607 ist 1,17 GB groß.
Der Spectre&Meltdown Patch für Win 10 1709 ist 600MB groß.
Der Spectre&Meltdown Patch für Win 7 SP1 ist 66MB groß.

Für Windows 10 muss der AppCompat Key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat\cadc a5fe-87d3-4b96-b7fb-a231484277cc) nicht gesetzt werden, Windows 7 benötigt jedoch diesen Key, um den Patch bei WSUS anzufordern.

[Gecko_0815]

Ja, ist ein Haswell

Danke! Hatte mich schon gewundert ihn nicht auf der Liste zu finden. Und Haswell soll ja noch gefixt werden ... Ein neues BIOS wird es wohl nicht mehr geben.

Und mein tapferer i5-750 ist betroffen und ganz raus aus den Updates.

[Setsul]

Das spielt für Spectre keine Rolle - sobald das Javascript auf der CPU ausgeführt wird kann es den Exploit ausführen unabhängig davon ob es einen eigenen Prozess hat.
Man muss unterscheiden zwischen:
Spectre BCP (v1)
Spectre BTI (v2) und
Meltdown (v3)

In welchem Prozess v2 oder v3 ausgeführt werden ist egal, weil man damit andere Prozesse und unter Umständen auch den Kernel angreifen kann.
Für v2 braucht man aber irgendeinen Weg um den Code, der dann umgeleitet wird über BTI, ins Rollen zu bringen. Wenn der Code gar nicht mehr ausgeführt wird bringt es nichts. Wenn der Code einfach irgendwann ausgeführt wird und Ewigkeiten später kommt dann der eigene Code wieder zum Zug dann ist die entsprechende Cache Line wahrscheinlich nicht mehr im Cache, weil sie nie benötigt wurde und evicted wurde.
V2 ist auch offensichtlich sinnlos wenn der Browser nur in einem Prozess läuft. Wenn ich beliebigen Code in dem Prozess ausführen kann um indirekte Sprünge umzuleiten, dann brauche ich keinen Sprung im eigenen Prozess umleiten.

Es geht hier nur um v1.
Mit v1 kann ich aber nur auf Daten zugreifen für die der Prozess auch Zugriffsrechte hat. Wenn ich auf andere Daten zugreifen kann, dann ist das Meltdown (v3), nicht Spectre.
Jeden Tab in einen eigenen Prozess zu stecken löst das Problem offensichtlich.
Wenn man mit NoScript alle Skripte blockiert dann können die natürlich keinen schädlichen Code ausführen. Das gleiche kann man auch erreichen in dem man nie auf die Websites geht oder den Browser gar nicht startet.
Wenn ein Skript erstmal läuft dann kann es v1 ausführen, ABE hin oder her. ABE blockiert basierend auf der Herkunft des Skripts auf welche Daten es zugreifen und was es versenden darf.
Spectre BCP (v1) umgeht aber gerade bounds checks, also ist das völlig nutzlos. Das Skript wird niemals eine Anfrage senden um ein Passwort zu lesen und dann kann ABE auch nichts blockieren. Das Skript sucht sich die Speicheradresse und liest dann alles direkt aus.

NoScript/ABE können nur verhindern dass ein Skript ausgeführt wird, wenn es nicht whitelistet ist. Wenn es ausgeführt wird funktioniert v1.
Bei Site Isolation ist das egal. Das Skript läuft in einem eigenen Prozess und dort sind nur die eigenen Daten. V1 kommt nicht in andere Prozesse rein, also sind die sicher.

[Lurtz]

Unser Thinkpad E570 hat gerade ein Bios-Update für CVE-2017-5754 reinbekommen. Denke das L560 wird auch noch was bekommen.

Bei MSI weiterhin Totenstille... :ugly:

[Ganon]

Mit dem aktuellen Microcode Update hat Intel übrigens einige Microcodes wieder zurückgezogen und entsprechend auch den Spectre "Fix". Vermutlich wegen der genannten Probleme in dem anderen Overclocker-Forum?

https://packages.qa.debian.org/i/intel-microcode/news/20180110T100610Z.html


+ Downgraded microcodes:
sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
sig 0x000506c9, pf_mask 0x03, 2017-03-25, rev 0x002c, size 16384
+ This removes IBRS/IBPB support for these two platforms when compared
with the previous (and unofficial) release, 20171215. We don't know
why Intel declined to include these microcode updates (as well as
several others) in the release.


Auch wenn ich nicht weiß welche CPUs das eigentlich betrifft: Darum sagte ich ja "damals" auch: Nicht einfach irgendwelche Microcodes von irgendwo nutzen :D

[MadPenguin]

Auch Nvidia patched die eigenen GPUs bezüglich Spectre
https://www.google.it/amp/s/www.engadget.com/amp/2018/01/10/nvidia-gpu-meltdown-and-spectre-patches/

Was ist mit AMD GPUs?

Edit: ich weiß, es ist ein CPU Unterforum, aber ein eigenes Thema aufzumachen wäre unangebracht

[TGKlaus]

Unsere Backup-Systeme wurden mittlerweile gepatched und getestet.

Bezogen auf die Commvault-Systeme Performanceeinbruch 25-55%.

Resultat von Alternativen wären sehr interessant!

[Darkman.X]

Auch Nvidia patched die eigenen GPUs bezüglich Spectre
https://www.google.it/amp/s/www.engadget.com/amp/2018/01/10/nvidia-gpu-meltdown-and-spectre-patches/

Was ist mit AMD GPUs?

Edit: ich weiß, es ist ein CPU Unterforum, aber ein eigenes Thema aufzumachen wäre unangebracht

Da werden nicht die GPUs gepatcht, sondern die Software/Treiber, damit man nicht/schwerer die CPUs angreifen kann.

Aus deinem eigenen Link:
Update: The original article suggested that the GPUs themselves were at risk, which isn't correct; NVIDIA is just patching its drivers to mitigate the impact of CPU issues. We apologize for the error.