News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)

[Iscaran]

Hmm...das stimmt schon dass das eine sehr schlechte Idee ist diese Dinge per default "deaktiviert" zu lassen.

ABER das habe ich ehrlich gesagt erst gar nicht so aus den Worten von Linus rausgelesen - vielleicht hätte er DIESEN Punkt einfach stärker betonen sollen und den ganzen Technoschnickschnack dann weglassen sollen in seinem Rant ?

Ich stimme ihm zu dass es schlecht ist wenn diese Patches erstmal per DEFAULT OFF sind....es muss genau anders rum sein.

 

[Complicated]

Das hat er - nur die Journalie meint das immer weg lassen zu müssen O-Ton:
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html

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

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

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

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

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

Honestly, that's completely unacceptable too.

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

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

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

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

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

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

BULLSHIT.

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

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

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

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

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

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

WHAT THE F*CK IS GOING ON?

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

It's mis-designed for two major reasons:

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

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

Do you really think that is acceptable?

- the "there is no performance indicator".

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

But since we already know that the IBRS overhead is <i>huge</i> on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high. So you end up having to look at "which CPU stepping
is this" anyway.

I think we need something better than this garbage.

Linus

 

[RedBaron]

Intel ist gerade dabei die "Customer Satisfaction" zu "reduzieren"

Ein Kommentar aus dem Phoronix Forum:

I swear that I am turning off all that shit in my kernel today unless Intel pays my electricity bill. If one day my server becomes zombie in some botnet due to that bug it is your fault Intel! Difference on the cpu use is huge running same server with same apps between kernel 3.14.79 & 4.14.11

https://www.phoronix.com/forums/for...pport-added-to-llvm-for-spectre-v2-mitigation

in I/O-lastigen Umgebungen ist der Performance Drop sehr groß.

Hält Intel sich deshalb PR-mäßig so zurück?

Ich warte ab, ob der Skylake-Pentium im einem meiner Arbeits-PC auch so absackt...

 

[eratte]

Meltdown: Apple liefert (endlich) Fix für ältere macOS-Versionen (heise)

--- Update ---

ROFL

Sard Verbinnen & Co: Intel heuert Krisenmanager für Spectre/Meltdown an (Computerbase)

 

[eratte]

IBRS und Retpoline: Linux-Entwickler diskutieren weiter über Spectre-Paches (golem)

 

[RedBaron]

Haben die Hersteller, nicht nur Intel, noch den Überblick über die ganze Sache mit Meltdown und Spectre?

 

[Complicated]

Das einzige das in dieser Thematik für Unübersichtlichkeit sorgt ist die Kommunikation und Handlungsweise von Intel. Alle anderen Beteiligten scheinen ebenso zu handeln wie bei tausenden von Exploits zuvor.

 

[eratte]

Software Techniques for Managing Speculation on AMD Processors Whitepaper 1/24/2018 (AMD PDF)

--- Update ---

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

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

--- Update ---

AMD: Leitfaden zur spekulativen Ausführung (au-ja)

 

[Stefan Payne]

Die machen sich doch langsam lächerlich. Seit Mitte letzten Jahres wissen die Bescheid und bis heute haben die nichts auf die Reihe gebracht.

~2014 kann man davon ausgehen, weil Intel ja erst die schlafenden Hunde geweckt hat...

 

[ICEMAN]

Ich beziehe mich auf das Ergebnis von Google letztes Jahr, aber egal wie lange sie es wissen. Es wird nur noch schlimmer statt besser.

 

[eratte]

Intel liefert Rekordzahlen – Warten auf Lösung für Meltdown und Spectre (heise)

"Wir arbeiten daran", sagte Krzanich in einer Telefonkonferenz mit Analysten und Investoren und kündigte an, die Sicherheitsmängel "später in diesem Jahr" durch neue Hardware beheben zu wollen.

--- Update ---

AMD gibt Programmierleitfaden gegen Spectre heraus (Planet 3D Now)

 

[RedBaron]

GCC 7.3 mit Retpoline-Patches erschienen

Der jetzt veröffentlichten Version 7.3 der freien Compiler-Suite GCC kommt eine besondere Bedeutung zu. Sie beinhaltet die sogenannten Retpoline-Patches, die Retpoline in mit GCC 7.3 gebauten Kerneln für x86 und PowerPC wirksam werden lassen.

gcc-73 mit retpoline-patches erschienen

--Update--
Google wappnet Chrome gegen Spectre und 52 weitere Sicherheitslücken

Spectre und Werbeblocker
Chrome 64 setzt nun auf JavaScript V8, die gegen das Ausnutzen der CPU-Lücke Spectre gerüstet ist.

https://www.heise.de/security/meldung/Google-wappnet-Chrome-gegen-Spectre-und-52-weitere-Sicherheitsluecken-3950969.html

 

[Oi!Olli]

Dann dröseln wir die nächsten Lücken doch schon mal auf

Ich kann nicht mehr.

 

[eratte]

Wie geht es weiter im CPU-Geschäft nach Meltdown & Spectre? (3D Center)

Hier wird in Bezug auf Spectre 2 Intel = AMD gesetzt.

--- Update ---

Reboot-Probleme: Optionales Windows-Update deaktiviert Spectre-Schutz (Computerbase)
Außerordentliches Update: Microsoft deaktiviert Spectre-2-Patches für Windows (golem)

 

[RedBaron]

Es ist für Benutzer von CPUs älter als Haswell die selbe Situation wie für viele Benutzer von älteren Android-Geräten:
Keine Updates mehr vom jeweiligen Hersteller, wegen EOL.

--Update--

Meltdown & Spectre: Windows-Update deaktiviert Schutz gegen Spectre V2
https://www.heise.de/security/meldu...ktiviert-Schutz-gegen-Spectre-V2-3952923.html

Microsoft hat außer der Reihe ein Update (KB4078130) für verschiedene Windows-Versionen veröffentlicht, welches die Schutzvorkehrungen gegen die CPU-Lücke Spectre Variant 2 (CVE-2017-5715) deaktiviert. Das geschieht auf Anraten von Intel, da bisherige CPU-Microcode-Updates Systeme instabil laufen lassen können.

Was für ein Durcheinander, funktioniert der Patch JA/Nein/Vielleicht?

 

[Complicated]

Unter Linux werden diese Hersteller Updates nicht benötigt für AMD Hardware.

 

[eratte]

Spectre-Lücken: auch MIPS P5600 und IBM POWER6 betroffen, Intel erklärt IBC (Update) (heise)

 

[eratte]

Betriebssysteme: Patches für Meltdown und Spectre in Linux 4.15 (golem)

 

[eratte]

Diverse NAS-Geräte von Qnap und Synology anfällig für Meltdown & Spectre (heise)

 

[eratte]

Hundreds Of Meltdown, Spectre Malware Samples Found In The Wild (tom's Hardware)

--- Update ---

Meltdown & Spectre: Immer mehr Malware, echte Angriffe unklar (heise)

--- Update ---

Microsoft stuft das PoC-Programm zu Spectre als bösartig ein (heise)

 

[eratte]

Meltdown & Spectre: Intel bringt wieder Microcode-Updates (heise)

Das läuft alles andere als gut.

 

[RedBaron]

Meltdown & Spectre: Intel bringt wieder Microcode-Updates (heise)

Das läuft alles andere als gut.

Mich würde interessieren, ob in den Rechenzentren und Serverfarmen von Amazon, Google, Akamai, Microsoft und anderen
eine "umfangreiche" Beschäftigung mit dem fixen der Lücken und dem begrenzen der Kollateralschäden durch Performanceeinbrüche vorherrscht.
Da werden viele Ressourcen gebunden werden...

Von Qualcom, Mediatek und anderen ARM-CPU Herstellern hört und liest man auch nicht viel, obwohl diese je nach CPU-Serie auch betroffen sind.

 

[eratte]

Was ich bei uns im Unternehmen von den mir bekannten Serverfuzzis so höhren müssen die jeden Patch vorher ausgiebig testen auf impact der daraus resultieren könnte. Die haben im Moment wenig Spaß.

 

[Iscaran]

Hmmm - Jon Masters Vorlesung über Meltdown/Spectre - für das Fachpublikum sicherlich interessanter als für mich:
https://www.phoronix.com/scan.php?page=news_item&px=Jon-Masters-Spectre-Meltdown
Video: https://video.fosdem.org/2018/Janson/closing_keynote.webm
PDFs: https://fosdem.org/2018/schedule/ev...e/slides/2597/FOSDEM_2018_Closing_Keynote.pdf

Interessant finde ich hier Slide 78


"Relies upon the branch prediction hardware not fully disambiguating branch addresses"

Das ist denk ich ein ziemlicher Beleg (?) dafür wie schwierig es sein müsste eine Ryzen/Bulldozer CPU mit Spectre V2-BTI angreifen zu können, SOFERN es denn stimmt dass AMD hier immer vollständige Adressgenauigkeit in den Buffers verwendet.

Oder anders übersetzt "wenn dein Branch Predictor sich eben austricksen lässt weil er anstatt exakter Adressen nur grobe Adressbereiche speichert bzw. als Sprungadressen zulässt dann bist du über Spectre V2 angreifbar".

EDIT: Auch interessant Folie 79:
Folie 79:

Mitigating Spectre-v2: Big hammer approach
• Existing branch prediction hardware lacks capability to disambiguate different contexts
• Relatively easy to add this in future cores (e.g. using ASID/PCID tagging in branches)"

=> Evtl. die Erklärung warum Zen2 ggf. schon Spectre Mitigations in Hardware kann ? PCID im Hauptprozess kann Zen AFAIK eh schon - muss also nur noch auf die Branch Prozesse ausgeweitet werden (?)

 

[Iscaran]

Oh - das ist endlich mal eine schöne Übersicht:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/TechFAQ