A. K. schrieb:> Paul B. schrieb:>> Die Liste von A.K. hatte ich schon vorher gefunden -nur anfangen kann>> ich damit nichts.>> Kann ich nachvollziehen, die ist wirklich schwer zu interpretieren. Aber> dein Prozessor steht da tatsächlich nicht drauf.
Bist du sicher? Auf der INTEL Liste steht der Eintrag
"2nd generation Intel® Core™ processors" affected
und laut Wikipedia gilt:
a) "Die „2“ steht vielmehr für die zweite Generation"
b) "Die Variante für den Massenmarkt mit zwei Prozessorkernen
(Doppelkernprozessor) wird Core 2 Duo genannt"
Also scheint doch der Core 2 Duo wohl zu den "affected products" zu
gehören, wenn Paul einen Core 2 Duo E8400 sein eigen nennt oder etwa
nicht?
Lediglich der Hinweis im Wiki auf eine abgewandelten Version der
P6-Architektur hat mich ins Schleudern gebracht.
Die Frage bezüglich dieser ominösen Liste ist natürlich, ob Intel sich
die Mühe gemacht hat, alle Prozessoren bis zurück zu Adam und Eva zu
beerücksichtigen. Es fällt nämlich auf, dass sämtliche Intel OOO
Prozessoren angefangen mit den Pentium Pro über Pentium 4 bis zu Pauls
Wolfdale Core darin fehlen. Obwohl die ebenso spekulativ arbeiten wie
ihre Nachfolger.
Eine technische Grenze gibt es allerdings. Und zwar zwischen Pauls
Wolfdale Core und dem Nachfolger Nehalem. Ab Nehalem steht jeder drin,
davor keiner.
Sind diese Oldtimer wirklich nicht betroffen, oder hat sich Intel bloss
nicht die Mühe gemacht, sich darum zu kümmern?
Alles Humbug schrieb:> Bist du sicher?
Nur so sicher wie Intels eigener Marketing-Dekoder. Was immer das
heisst.
https://www.intel.com/content/www/us/en/processors/processor-numbers.html
Demzufolge beschreibt die "2nd Generation Intel® Core™ Processor Family"
Prozessoren der Nomenklatur "Core ix 2yyy". Pauls Prozessor fällt unter
"Intel® Core™2 Duo Processor Family" und ist damit der Vorgänger der
"Intel® Core™ Processor Family".
Etwas kompliziert wirds allerdings bei den dreistelligen "Core ix yyy",
denn die sind zwar "Intel® Core™ Processor Family" und damit draussen,
aber andererseits "Core ix" mit maximal 45nm und damit drinnen. Dass die
"Intel® Core™ Processor Family" nicht in der Liste steht, deren
Prozessoren aber schon, sorgt etwas für Verwirrung.
A. K. schrieb:> Sind diese Oldtimer wirklich nicht betroffen, oder hat sich Intel bloss> nicht die Mühe gemacht, sich darum zu kümmern?
Meiner Einschätzung nach ist Pauls Core 2 Duo E8400 betroffen.
Heise schrieb im FAQ:
5. Welche Prozessoren sind genau betroffen?
"Dazu gehören etwa sämtliche Intel-Core-Prozessoren seit 2008, dazu die
Serien Intel Atom C, E, A, x3 und Z sowie die Celeron- und
Pentium-Serien J und N. Außerdem nahezu alle Server-Prozessoren der
vergangenen Jahre sowie die Rechenkarten Xeon Phi"
Nimm mal die 2008er Einführungszeit der CPU als untere Grenze an
Nun wirf mal einen Blick hier drauf:
https://ark.intel.com/products/33910/Intel-Core2-Duo-Processor-E8400-6M-Cache-3_00-GHz-1333-MHz-FSB
"Launch Date Q1'08"
und damit leider betroffen.
Das Problem ist halt INTEL und dessen zweideutiges Geschwurbel.
Alles Humbug schrieb:> Das Problem ist halt INTEL und dessen zweideutiges Geschwurbel.
Yep. Ich bin ja nicht immer ein Fan von Linus' Ausdrucksweise. Aber
manchmal passt sie.
Da allerdings die technische Seite des Problems weniger vom Datum als
vom konkreten Core abhängen muss, habe ich das vorhin aus dieser Warte
betrachtet. Und da ergibt Intels Liste m.E. eindeutig eine Grenze
zwischen Pauls Wolfdale und dem Nachfolger Nehalem.
Nur kann es natürlich sein, dass Intel bei dieser Liste mal wieder
Nebenkerzen zündete und alles alte Zeug schlicht durch den Raster fallen
liess.
Alles Humbug schrieb:> Meiner Einschätzung nach ist Pauls Core 2 Duo E8400 betroffen.
Durchaus möglich.
Ich schrieb nicht ohne Grund nur, dass Pauls Prozessor nicht auf der
Liste stünde. Ich liess bewusst offen, ob er betroffen sei.
Apropos Nebelkerze: In Intels Original (Link siehe oben) steht wörtlich
"The following Intel-based platforms are impacted by this issue."
Formaler Logik folgend sagt das natürlich nichts über jene Produkte aus,
die nicht darin stehen. ARM wies in deren Liste freundlicherweise auch
auf jene hin, die nicht betroffen sind. Diese Aussage fehlt bei Intel.
Also Paul, du bist immer noch im Limbo.
Paul B. schrieb:> Im Limbo?! Mit dem Prozessor bin ich eher beim langsamen Walzer.
Sorry, das Tanzen wollte ich dir ersparen.
Englisch Limbo = Deutsch Limbus.
O.T.
A. K. schrieb:> Sorry, das war ein Anglismus. Englisch Limbo = Deutsch Limbus.
Man muß nicht unbedingt mit Fremdworten beeindrucken wollen -das kann
auch zur völligen Verwirrung führen:
https://de.wikipedia.org/wiki/Limbus
Paul
Alles Humbug schrieb:> https://www.amd.com/en/corporate/speculative-execution>> Google Project Zero (GPZ)>> Variant "One Bounds Check Bypass":>> Resolved by software / OS updates to be made available by system vendors> and manufacturers. Negligible performance impact expected.>> Variant "Branch Target Injection":>> Differences in AMD architecture mean there is a near zero risk of> exploitation of this variant. Vulnerability to Variant 2 has not been> demonstrated on AMD processors to date>> Variant Three "Rogue Data Cache Load":>> Zero AMD vulnerability due to AMD architecture differences.>> As always, AMD strongly encourages its customers to consistently> undertake safe computing practices, examples of which include: not> clicking on unrecognized hyperlinks, following strong password> protocols, using secure networks, and accepting regular software> updates.
Leider von der Wirklichkeit überholt. Mist!
"AMD rudert zurück: Prozessoren doch von Spectre 2 betroffen,
Microcode-Updates für Ryzen und Epyc in Kürze"
https://www.heise.de/newsticker/meldung/AMD-rudert-zurueck-Prozessoren-doch-von-Spectre-2-betroffen-Microcode-Updates-fuer-Ryzen-und-Epyc-in-3939975.html
Lustig ist ja, dass das laut Intel kein Fehler ist, sondern alles wie
gewünscht funktioniert. So heißt es auf
https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
:
Is this a bug in Intel hardware or processor design?
No. This is not a bug or a flaw in Intel® products. These new exploits
leverage data about the proper operation of processing techniques common
to modern computing platforms, potentially compromising security even
though a system is operating exactly as it is designed to. Based on the
analysis to date, many types of computing devices — with many different
vendors’ processors and operating systems — are susceptible to these
exploits.
Rolf M. schrieb:> Lustig ist ja, dass das laut Intel kein Fehler ist, sondern alles wie> gewünscht funktioniert.
Das wurde oben schon mal thematisiert. Man kann das tatsächlich so sehen
wie Intel. Die Funktion der Prozessoren ist völlig korrekt, es lassen
sich aber Nebenwirkungen des Laufzeitverhaltens ausnutzen. In diesem
Sinn stimme ich ihm zu:
Andreas S. schrieb:> Auf einer sehr abstrakten Ebene kann man das ganze zwar schon als Bug> bezeichnen, nicht jedoch auf der Implementierungsebene der Prozessoren.
Man hat auch schon Security Chips per side channel geknackt, indem man
deren Stromverbrauch analysierte - ist das ein echter Fehler im Sinn der
Spezifikation?
Kleiner Spass am Rande: Ich bin gespannt, ob demnächst Android-Patches
auftauchen werden, offizielle oder inoffizielle, die das Problem
besserer Mobilgeräte in bester Apple-Manier lösen. Wenn von den
enthaltenen Cores die meist 4 langsamen Stromspar-Cores (A53) sicher
sind und die sowieso nur bei Bedarf eingeschalteten 2-4
Performances-Cores (A57 aufwärts) nicht - was könnte man da wohl tun?
Sobald sehr ernst zu nehmende Schädlinge unterwegs sind wär mir das
nicht einmal unrecht. Ok, ein Hersteller-Patch wär natürlich besser,
aber wenns den nicht gibt und nur die Alternative bliebe, das keine 2
Jahre alte Teil andernfalls wegzuwerfen?
Als ARM Strategie würde ich dann für die Zukunft empfehlen, nicht lauter
gleiche Cores einzubauen, sondern lauter verschieden arbeitende (*). Bei
künftig aufkommenden Bugs kann man die dann sukzessive einen nach dem
anderen abschalten. Mikrocode gibts in RISCs ja nicht, kann man also
auch nicht patchen. ;-))
*: Intel und AMD auf der gleichen CPU gibts zwar mittlerweile auch
schon, aber leider nicht in diesem Sinn. ;-)
Update zu anfänglichen Verschwörungstheorien: Wenn Intel das verbrochen
hätte, um neue Prozessoren zu verkaufen, dann ergäbe das auf den ersten
Blick sogar Sinn. Der als Spekulationsbremse gehandelte und in aktuellen
Linux Kernels deshalb vermehrt genutzte LFENCE Befehl ist bei neueren
Intels deutlich schneller (4T) als bei alten (8-9T) und erst recht dem
P4 (38/50T).
Blöd für Intel wär dann bloss, dass AMD dabei einmal mehr vorne liegt
(1T, 4x parallel).
Also abgesehen von seiner Funktion als Spekulationsbremse, die natürlich
ebenfalls zu Wartezyklen führen kann. Quelle: die Tabellen von Agner
Fog.
Apropos LFENCE: Bei genauer Betrachtung der Definition dieses Befehls
fällt mir auf, dass sich diese mit den Jahren verändert hat. Bezog er
sich in der Referenz von 2009 ausschliesslich auf die Ordnung von
Load-Befehlen untereinander, liest sich die Referenz von 2015 so, als ob
alle Befehle betroffen sind, nicht nur Loads.
Intel 2009: "Performs a serializing operation on all load-from-memory
instructions that were issued prior the LFENCE instruction. This
serializing operation guarantees that every load instruction that
precedes in program order the LFENCE instruction is globaly visible
before any load instruction that follows the LFENCE instruction is
globally visible. ..."
Intel 2015 (ebenso Dezember 2017): "Performs a serializing operation on
all load-from-memory instructions that were issued prior the LFENCE
instruction. Specifically, LFENCE does not execute until all prior
instructions have completed locally, and no later instruction begins
execution until LFENCE completes. ..."
AMDs aktuelle Referenz von Dezember folgt Intels ursprünglicher
Definition: "Acts as a barrier to force strong memory ordering
(serialization) between load instructions preceding the LFENCE and load
instructions that follow the LFENCE. Loads from differing memory types
may be performed out of order, in particular between WC/WC+ and other
memory types. The LFENCE instruction assures that the system completes
all previous loads before executing subsequent loads. ..."
Das wirft zwei Fragen auf: Hilft die ursprüngliche Definition überhaupt
gegen Spectre? Ist das eine Änderung im Verhalten von Intels
Prozessoren, oder folgt die Beschreibung dem sowieso immer schon
vorhandenen Verhalten?
A. K. schrieb:> Mampf F. schrieb:>> Ist der Microcode eigentlich persistent?>> Ich gehe davon aus, dass der gesamte für den Befehlssatz benötigte Teil> des Microcodes auf der CPU hart verdrahtet ist und lediglich> Microcode-Modifikationen nachträglich in ein spezielles RAM in der CPU> geladen werden können. Das System startet also mit dem> Standard-Microcode und kann Modifikationen selbst nachladen.
Genau so ist es. Wen es interessiert, kann sich den Vortrag vom letzten
CCC anschauen, da hat sich jemand damit befasst und die (leichte)
Verschlüsselung für die Microcode-Images geknackt. Daraus lassen sich
interessante Angriffe basteln.
"Everything you want to know about x86 microcode, but might have been
afraid to ask
An introduction into reverse-engineering x86 microcode and writing it
yourself"
https://media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask
Lady Hesketh-Fortescue aus North Cothelstone Hall schrieb im Beitrag
#5282770:
> Das ist ja mal richtig schmierig. Wenn es dann irgendwann mal genutzt> wird, kriegt man den Ausführenden dieses Vortrages eventuell wegen> Mitwirkung an Sabotage am Arsch.
Oh ja, lasst es uns totschweigen, wird schon kein anderer auf die Idee
kommen da mal nachzusehen.
Hallooo? Security by obscurity funktioniert nicht!
Karl schrieb:> Security by obscurity funktioniert nicht!
Vielleicht merkt es ja keiner,oder es ist ihnen egal?
Hier will der Innenminister zukünftig nichtmal mehr protokollieren
lassen welcher Polizist wann warum welche Daten abfragt. Und du willst
einen saven Prozessor.
Wie bist du den drauf? Willst du vielleicht auch noch auf Privatspähre,
Perönlichkeitsrechte, (auch elektronisches) Briefgeheimnis,
Telekommunikationsgeheimnis und umfassenden Datenschutz bestehen?
Na du bist mir ja Einer, hast du was zu verbergen?
Namaste
Winfried J. schrieb:> Willst du vielleicht auch noch auf Privatspähre,> Perönlichkeitsrechte, (auch elektronisches) Briefgeheimnis,> Telekommunikationsgeheimnis und umfassenden Datenschutz bestehen?
Nicht das da noch jemand behauptet, diese Schutzrechte würden bei
Nutzung sozialer Netzwerke nicht umfangreich beachtet. Das wäre
vielleicht ein Schelm.
> Na du bist mir ja Einer, hast du was zu verbergen?
Darüber muss er gleich via Twitter mit seiner Gefolgschaft plaudern.
Karl schrieb:> Security by obscurity funktioniert nicht!
Da kann ich nur zustimmen. Nur wenn eine Sicherheitslücke bekannt ist,
kann diese behoben werden, aber wenn eine Sicherheitslücke nicht bekannt
ist, kann diese von läuten, die zufällig darauf stossen trozdem
ausgenutzt werden.
Winfried J. schrieb:> Na du bist mir ja Einer, hast du was zu verbergen?
Ja, ist doch langweilig keine Geheimnisse zu haben, und alles muss nun
wirklich nicht jeder über mich wissen. Auf jeder Webseite nutze ich eine
andere E-Mail/Account. Ich habe einen Twitter Account für Leute die
danach Suchen, und einen den ich eigentlich nutze, mit Dingen von denen
es zwar nichts ausmacht, wenn jemand davon weiss, die aber auch nicht
jeder zu wissen braucht. Und dann habe ich noch ein Pseudonym, dass ich
nur auf dedizierten Systemen nutze, dessen Internet Traffic nur über Tor
geroutet werden kann, für Dinge, von denen wirklich niemand wissen soll,
von wem sie sind. Dann habe ich noch Privates, das auf meinem Server
Zuhause gespeichert ist und nicht öffentlich zugänglich und nicht auf
Fremden Systemen ist. Und dann noch die Dinge, die nur Lokal auf meinem
eigenen PC sind. So kann man recht gut kontrollieren, wer was weiss.
Ich habe mal einen Artikel geschrieben, warum Internetüberwachung keine
gute Idee ist: https://www.danielabrecht.ch/internetueberwachung/
Es ist doch immer das Gleiche mit der Überwachung, immer heisst es man
müsse eben ein paar Rechte und Freiheiten opfern, wenn man sicher leben
wolle, aber was dies am Ende bedeuted, wozu dies alles Führt, daran
denkt natürlich keiner. Man hätte ja nichts zu verbergen. Die Daten
könnten ja nicht misbraucht werden, es währe ja alles Gesetzlich
geregelt. Korruption wäre nur in anderen Ländern möglich, sowas gäbe es
hier nicht. Das habe ich andere alles schon sagen hören, es ist schon
unglaublich, wie Naiv viele Menschen sind. Sicher, es gibt manchmal
Terroranschläge, und das ist schrecklich und alles, aber das passiert
derart selten und trifft derart wenige Menschen im vergleich zu anderen
Tragödien wie Autounfällen usw., dass ich nicht glaube dass es es wert
ist, deswegen jeden seine Freiheiten aufgeben zu lassen. Man sollte
einfach bei guten und Bewährten prinzipien bleiben: Die Leute erst
verurteilen, wenn diese auch tasächlich etwas unrechtes getan haben.
Sorry,
hatte es nicht zur Hand.
deshalb um der um sichgreifenden Verwirrung entgegenzuwirken.
und noch das: "Aber ich habe doch gar kein facebook?"
Namaste
Stephan B. schrieb:> ...und es geht wohl weiter:
Vielleicht. Vielleicht aber doch nicht so. Das wird von Heise und der TU
Graz bislang eher als Scherz gehandelt.
Man muss nicht jeder Karotte hinterher laufen, die einem vor die Nase
gehalten wird. Sondern kann abwarten, bis mehr dahinter ist als 2
Webseiten ohne Inhalt.
Kaj G. schrieb:> Linus Torvalds auf der Mailingliste:> BULLSHIT.
Nun ist Linus nicht gerade für besondere Zurückhaltung bekannt, weshalb
es bei ihm nicht immer leicht ist, ein ernstes Bullshit vom
Grundrauschen zu unterscheiden. ;-)
Aber so wie das läuft frage ich mich schon, was im derzeitigen Stadium
gefährlicher ist: die Löcher, oder die Versuche, sie zu stopfen.
Interessanterweise zieht HPE zwar haufenweise Server-Updates zurück,
aber das BIOS eines HP PCs mit Haswell drin gab es heute noch. Ok, HP
und HPE sind wohl geschiedene Leute, aber ich wüsste schon gern, ob das
System hat, oder bloss Zufall ist. Immerhin, der PC läuft noch.
A. K. schrieb:> Interessanterweise zieht HPE zwar haufenweise Server-Updates zurück,> aber das BIOS eines HP PCs mit Haswell drin gab es heute noch.
Das war Stand gestern. Heute gibts das nicht mehr. Sinn für Timing...
Nach der Ankündigung der KX-5000 (Wudaokou) hat der chinesische Hersteller
2
Zhaoxin die technischen Daten der x86-Prozessoren veröffentlicht und sich
3
auch zur Anfälligkeit für Meltdown und Spectre geäußert. Die Chips basieren
4
auf einem Centaur-Design von Via, wie Wikichip unter Berufung auf Zhaoxin
5
berichtet. Es bleibt unklar, ob es sich um eine Abwandlung der Isaiah- oder
6
der Isaiah-2-Technik handelt, wobei Letzteres wahrscheinlicher ist.
7
8
Laut Zhaoxin sind die Wudaokou nicht für Meltdown anfällig, allerdings für
9
eine nicht genannte Variante von Spectre. Laut Hersteller sei ein Angriff
10
aber aufwendig, da die Sprungvorhersage mit sehr vielen Befehlen bearbeitet
11
werden müsste, um ausgehebelt zu werden - das ist aber bei Chips von AMD,
12
ARM oder Intel nicht viel anders.
Was mich hier etwas stoert, ist dieser Satz:
1
Laut Zhaoxin sind die Wudaokou nicht für Meltdown anfällig, allerdings für
2
eine nicht genannte Variante von Spectre.
"nicht genannte Variante von Spectre" -> Soll das heissen, das der
Hersteller nicht sagt fuer welche Variante, oder heisst das, das es noch
eine andere, bisher unbekannte Variante von Spectre gibt?
Ich frage mich, ob es schon mal ein aehnliches Sicherheitsproblem dieser
Groesse gab? Klar, Heartbleed war auch riesig und wurde auch durch alle
Medien getreten, war aber vergleichsweise einfach zu beheben.
Spectre adressiert das Grundprinzip von Out-Of-Order Prozessoren.
Interessanter wären folglich ausdrückliche Aussagen, dass bestimmte
Typen mit OOO Implementierung definitiv nicht anfällig wären.
Kaj G. schrieb:> "nicht genannte Variante von Spectre"
Da die Spectre Exploits den Sprungvorhersagemechanismus trainieren
müssen, um Wirkung zu erzielen, sind sie abhängig von dessen
Implementierung. Weshalb ein Exploit für Intels Skylake bei AMDs Zen
nicht wirken muss. Da ist ja auch AMD anfangs drauf reingefallen.
"Diese Patches sind absoluter Müll", stellte er fest. "Sie machen
2
buchstäblich wahnsinnige Dinge. Dinge, die keinen Sinn machen."
Interessant finde ich den nachfolgenden Satz:
1
Jemand, so Linus, wolle diese Patches aus Gründen im Kernel haben,
2
über die er nicht die Wahrheit sagen wolle. Eine klare Beschuldigung
3
gegenüber Woodhouse und seinem ehemaligen Arbeitgeber Intel.
Achtung, Aluhut:
Hoert sich fuer mich so an, als ob an den Patches irgendwas faul ist,
und zwar so richtig. Und damit meine ich nicht nur die Codequalitaet...
Kaj G. schrieb:> "Absoluter Müll": Linus Torvalds verliert die Geduld mit Spectre-Patches
"... dass er es wohl lieber gesehen hätte, dass die Firma betroffene
Prozessoren austauscht anstatt die Sicherheitslücken per Software-Update
im Betriebssystem und im Microcode der Prozessoren zu stopfen."
Nette Idee. Von mir aus bis zurück zum Nehalem Core. Allerdings würde
das für Intel an Selbstmord grenzen und bis das durch auch nur zurück
bis Haswell durch wäre, wären die Systeme längst gehackt.
Nope. Da hat sich Linus Torvalds verrannt. Wenn das nicht per Software
geht, Microcode eingeschlossen, dann kurzfristig überhaupt nicht.
PCs und Systeme haben eine Einsatz-Lebensdauer von mindestens 5 Jahren,
Server und Blackboxes nicht selten bis zu 10 Jahren. Mit einer
Verweigerung pragmatischer Lösungen fordert Linus Torvalds im Grunde,
dass weltweit alle Systeme ausser den letzten 1-2 Chipgenerationen
noch dieses Jahr weggeworfen und ersetzt werden sollten, weil FUBAR.
Ach ja: Und Apple tauscht kostenlos alle iPhones der letzten Jahre aus,
sobald sie welche haben, die mit sicheren Prozessoren ausgestattet sind.
Bis dahin müssen sich die iPhone-Jünger mit Android
Lowend/Midrange-Geräten mit Cortex A53 bescheiden. ;-)
Kaj G. schrieb:> Hoert sich fuer mich so an, als ob an den Patches irgendwas faul ist,> und zwar so richtig. Und damit meine ich nicht nur die Codequalitaet...
Das hört sich für mich zunächst nur so an, als ob Torvalds aus der Haut
fährt. Das macht der allerdings öfter und "Nach Torvalds Wutausbruch
gingen die Kernel-Entwickler wie gewohnt schnell wieder zum
Tagesgeschäft über und widmeten sich der Arbeit an den Spectre-Patches."
Man kennt sich.
A. K. schrieb:> Kaj G. schrieb:>> "Absoluter Müll": Linus Torvalds verliert die Geduld mit Spectre-Patches>> "... dass er es wohl lieber gesehen hätte, dass die Firma betroffene> Prozessoren austauscht anstatt die Sicherheitslücken per Software-Update> im Betriebssystem und im Microcode der Prozessoren zu stopfen.">> Nette Idee. Von mir aus bis zurück zum Nehalem Core. Allerdings würde> das für Intel an Selbstmord grenzen und bis das durch auch nur zurück> bis Haswell durch wäre, wären die Systeme längst gehackt.>> Nope. Da hat sich Linus Torvalds verrannt. Wenn das nicht per Software> geht, Microcode eingeschlossen, dann kurzfristig überhaupt nicht.
Das schöne an solchen Meldungen ist immer, dass anscheinend kaum mal
jemand in den Redaktionen den gesamten Text/Thread ließt...
Liste
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/index.html#05708
Message
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html
Es war nicht Linus, sondern David Woodhouse
1
From: Linus Torvalds
2
Date: Sun Jan 21 2018 - 16:36:05 EST
3
Next message: Jes Sorensen: "Re: [PATCH] rtl8xxxu: Fix trailing semicolon"
4
Previous message: Heiko Stübner: "Re: [PATCH 0/2] Input: auo-pixcir-ts: Adjustments for two function implementations"
5
In reply to: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation"
6
Next in thread: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation"
On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
9
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
10
>> All of this is pure garbage.
11
>>
12
>> Is Intel really planning on making this shit architectural? Has
13
>> anybody talked to them and told them they are f*cking insane?
14
>>
15
>> Please, any Intel engineers here - talk to your managers.
16
>
17
> If the alternative was a two-decade product recall and giving everyone
18
> free CPUs, I'm not sure it was entirely insane.
19
20
You seem to have bought into the cool-aid. Please add a healthy dose
21
of critical thinking. Because this isn't the kind of cool-aid that
22
makes for a fun trip with pretty pictures. This is the kind that melts
23
your brain.
> PCs und Systeme haben eine Einsatz-Lebensdauer von mindestens 5 Jahren,> Server und Blackboxes nicht selten bis zu 10 Jahren. Mit einer> Verweigerung pragmatischer Lösungen fordert Linus Torvalds im Grunde,> dass weltweit alle Systeme ausser den letzten 1-2 Chipgenerationen> noch dieses Jahr weggeworfen und ersetzt werden sollten, weil FUBAR.
Er verweigert sich ja nicht, sondern will nur keinen sinnlosen
Schwachsinn mit massiven Performanceeinbußen, wenn es auch anders/besser
geht.
Von Ingo Molnar kommt später noch ein interessanter Vorschlag ohne den
Intel-Kram im Kernel
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05628.html
1
So I talked this over with PeterZ, and I think it's all doable:
2
3
- the CALL __fentry__ callbacks maintain the depth tracking (on the kernel
4
stack, fast to access), and issue an "RSB-stuffing sequence" when depth reaches 16 entries.
5
6
- "the RSB-stuffing sequence" is a return trampoline that pushes a CALL on the stack which is executed on the RET.
7
8
- All asynchronous contexts (IRQs, NMIs, etc.) stuff the RSB before IRET. (The tracking could probably made IRQ and maybe even NMI safe, but the worst-case nesting scenarios make my head ache.)
9
10
I.e. IBRS can be mostly replaced with a kernel based solution that is better than IBRS and which does not negatively impact any other non-SkyLake CPUs or general code quality.
Fakt ist doch, dass diese Patzer der Hersteller sich in einer gewaltigen
Umsatzwelle ($$$) für diese niederschlagen wird. Das Gejammer der User
kostet sie dagegen wenig. Da finde ich die Idee gar nicht abwegig,
selbst in wirtschaftlichen Sinne, daß sie sich an einer breiten
Umrüstung bestehender Systeme beteiligen.
A. K. schrieb:> Nette Idee. Von mir aus bis zurück zum Nehalem Core. Allerdings würde> das für Intel an Selbstmord grenzen>> Ach ja: Und Apple tauscht kostenlos alle iPhones der letzten Jahre aus,> sobald sie welche haben, die mit sicheren Prozessoren ausgestattet sind.> Bis dahin müssen sich die iPhone-Jünger mit Android> Lowend/Midrange-Geräten mit Cortex A53 bescheiden. ;-)
Ja und? Dann ist das eben so. Was Du schreibst kommt folgendem gleich:
"Wir sind too big to fail. Hier gibt's nichts zu sehen, bitte weiter
gehen. Konsequenzen bleiben aus. Wir machen, was wir wollen. Deshalb
kann ähnliches auch zukünftig immer wieder passieren. Warum auch nicht?"
Solch eine Einstellung kann man gut finden, muss man aber nicht.
Rolf M. schrieb:> Winfried J. schrieb:>> Costum Prozessoren>> Da hab ich doch eine Idee, als was ich mich dieses Jahr zu Fasching> verkleide.>> /SCNR/
Und dabei die Bitmaske nicht vergessen!
A. K. schrieb:> AMDs aktuelle Referenz von Dezember folgt Intels ursprünglicher> Definition:
Das Verhalten von LFENCE lässt sich bei den meisten AMD Prozessoren per
MSR so anpassen, dass der Befehl vollständig serialisiert.
Aus AMDs Text zur Umgehung. Den hat allerdings garantiert noch niemand
korrekturgelesen, derzeit wird viel mit der heissen Nadel gestrickt:
http://developer.amd.com/wordpress/media/2013/12/Managing-Speculation-on-AMD-Processors.pdf
PS: Aluhut-Trägern wird bestimmt was im Filenamen auffallen. ;-)
Danke für den Clip, spannend wie ein Krimi.
Mal wieder ne Bitte um Einschätzung der Brisanz für Otto Normal:
Geht nicht generell nach wie vor eine viel größere Gefahr durch defekte
oder manipulierte Treiber aus, die einfach in den Kernel- oder
Realspeicher greifen?
batman schrieb:> Mal wieder ne Bitte um Einschätzung der Brisanz für Otto Normal:
Das Risiko geht von Fremdsoftware auf dem Rechner aus. Je dynamischer
desto höher. Den krassesten Fall bilden deshalb Browser über Javascript
in Webseiten. Da kommt täglich tonnenweise Zeug aus den fragwürdigsten
Quellen rein. Weshalb deren Hersteller auch schnell mit ersten
Massnahmen reagierten.
Deshalb: Augen offen halten, was man da ggf. machen kann, einschalten
kann. Also ob der Browser beispielsweise die Möglichkeit bietet, Seiten
gegeneinander zu isolieren. Ich habe da nicht den Überblick, aber bei
Opera ist das derzeit eine Beta-Option, also explizit einzuschalten.
Sinnvoll sind auch Werbefilter, Browser-Plugins als Javascript-Filter,
sofern man diesem Plugins über den Weg traut. Der am wenigsten
kontrollierte und unsicherste Kram ist Werbung. Da wissen auch die
seriösesten Websites meist selber nicht, was auf ihren Seiten zeitweise
rumlungert.
> Geht nicht generell nach wie vor eine viel größere Gefahr durch defekte> oder manipulierte Treiber aus, die einfach in den Kernel- oder> Realspeicher greifen?
Bei Software, die eigene Treiber mitbringt, generell privilegierten Code
nutzt, braucht man sich um Spectre/Meltdown wenig zusätzliche Gedanken
zu machen. Die können auch ohne diese Lücken viel Unfug stiften. Das war
schon immer Vertrauenssache.
Software, die ohne privilegierte Komponenten auskommt, gewinnt durch die
Lücken erhebliche Möglichkeiten. Es war schon bisher klug, nicht alles
zu installieren, was Web oder Freundeskreis bieten, ist jetzt noch mehr.
Nochmal zu Massnahmen: Dass man bei Intel-Prozessoren einen Kernel
einsetzen sollte, der gegen Meltdown geschützt ist, sollte
selbstverständlich sein. Dagegen spricht auch die Malaise mit dem
Mikrocode nicht, die hat damit nämlich überhaupt nichts zu tun.
Es was schon bisher sinnvoll, kritische Operationen wie Banking,
Einkäufe etc nicht neben anderen Browser-Sessions durchzuführen. Jetzt
noch mehr. Sicherer wirds dann noch, wenn man vorher und nachher den
Browser schliesst - und zwar wirklich, da sollte kein
Schnellstart-Zombie in der Prozessliste mehr rumlungern. Wer es nicht
lassen kann, permanent eine sicherheitskritische Seite offen zu halten,
der kann drüber nachdenken, dafür einen separaten Browser zu verwenden.
Also selbst wenn man nichts ändert, bleiben hoch sicherheitskritische
Systeme relativ sicher, weil kein Fremdcode reinkommt, dem man viel
Handlungsspielraum bietet?
Der heimische PC bleibt unsicher, weil man weiterhin genau das Gegenteil
tut und alle möglichen brandheißen Anwendungen und Gerätchen
ausprobiert. Auch wenn man hier mit speziellen Browsern, Plugins o.ä.
gegensteuern will, schafft man damit doch eher noch bessere
Angriffsmöglichkeiten oder? Glaube nicht so ganz daran, daß jemand sowas
gut prüft.
batman schrieb:> Also selbst wenn man nichts ändert, bleiben hoch sicherheitskritische> Systeme relativ sicher, weil kein Fremdcode reinkommt, dem man viel> Handlungsspielraum bietet?
Ausser natürlich, der Fremdcode kommt über z.B. bereits bestehende
Buffer Overflow Löcher rein, und der bekommt nun neue Möglichkeiten.
> Der heimische PC bleibt unsicher, weil man weiterhin genau das Gegenteil> tut und alle möglichen brandheißen Anwendungen und Gerätchen> ausprobiert.
Ja.
> Auch wenn man hier mit speziellen Browsern, Plugins o.ä.> gegensteuern will, schafft man damit doch eher noch bessere> Angriffsmöglichkeiten oder?
Massnahmen wie Site Isolation dienen generell der Sicherheit. Da
entstehen m.E. auch keine neuen Angriffsvektoren. Ich habe nur, wie
schon gesagt, keinen Überblick darüber, wie welcher Browser heute
arbeitet.
Zunächst einmal lebt es sich ohne Javascript sicherer als mit. Soweit
ists einfach und war auch bisher schon so. Nur ist das nun dank der
Lecks noch weit kritischer.
Dass Plugins eigene Risiken enthalten könnten ist klar. Aber sich für
jede Site durch die Einstellungen des Browser schlängeln zu müssen, um
das je nach Bedarf ein- und auszuschalten - wer macht das freiwillig?
Deshalb läuft es de fakto doch darauf hinaus, einen Kompromiss zwischen
Sicherheit und Nutzbarkeit zu finden.
Auch wenn ich gleich wieder, meine speziellen Freude finden werde, sei
es noch mal ventiliert: Es gibt keine Möglichkeit weder ein Medium noch
einen Kanal „sicher“ abzudichten. Man kann lediglich die Hürden für die
Kompromittierung so hoch legen, dass dem potentiellen Angreifer andere
Ziele lohnender erscheinen oder seine Resuorcen nicht ausreichen.
Alle Daten welche außerhalb meiner Kontrolle liegen muss ich per se als
potentiell kompromiitierbar erachten. Dazu zählt alles was auch nur
zeitweise am Netz hängt.
Namaste
Das war schon immer so. Nur konnte man früher mal ein einfaches System
im geschlossenen Kämmerlein ein paar Jahre Arbeiten lassen. Das ist bei
den heutigen ständigen Bug-Exploit-Update-Spiralen leider utopisch
georden. Wenn man sich da nicht mitdreht, kann das System quasi durch
Rumstehen extrem angreifbar werden. Dann passiert sowas wie Stuxnet.
batman schrieb:> Das war schon immer so. Nur konnte man früher mal ein einfaches System> im geschlossenen Kämmerlein ein paar Jahre Arbeiten lassen.
Das geht auch jetzt noch, wenn das Kämmerlein wirklich geschlossen
ist. Also ohne Netzanbindung, ohne alle naselang reinspazierende
Leutchen mit USB-Sticks etc.
A. K. schrieb:> batman schrieb:>> Das war schon immer so. Nur konnte man früher mal ein einfaches System>> im geschlossenen Kämmerlein ein paar Jahre Arbeiten lassen.>> Das geht auch jetzt noch, wenn das Kämmerlein wirklich geschlossen> ist. Also ohne Netzanbindung, ohne alle naselang reinspazierende> Leutchen mit USB-Sticks etc.
Reinspazieren dürfen sie, nur die Stäbchen gehören vor dem Einsatz am
Target unter Quarantäne und unters „Mikroskop“ und nie direkt an das
Target. Es bedarf eines autarken Filters der die als save eingestuften
Daten über einen physisch kontrollierten autarken Boten dem Target
übergibt. Wobei für Boten Filter und Mikroskop die selben Kriterien
gelten wie fürs Target selbst.
Oberste Prämisse muss sein, dass die Chain nicht untertunnelt werden
kann, und keine Daten ungefiltert rein noch raus können. Hier können wir
von der Stasi lernen: jedes Glied der Überwachungskette muss autark
arbeiten, darf nur über relevante Resuorcen und Kontakte verfügen und
muss seinerseits unabhängig überwacht werden. Gilt ein Glied als
komprommitiert, so ist die gesammte Kette als kompromiitiert zu
betrachten.
Enigma lehrt:
Wiederkehrende Daten dürfen nicht wiederholt übetragen werden. Jeglicher
Formalismus schwächt das kryptologische Prinzip. Deshalb sollte die
notwendige Redundanz ebenfalls mindestens verschleiert werden. Siehe
Wettertelegramm—backdoor.
Zu Spectre Mitigations und Android: Anders als in Windows, iOS und Linux
sollte es in Android eigentlich möglich sein, auch bestehende
Anwendungen ohne Updates der Anwendungen teilweise abzusichern. Immerhin
werden Anwendungen in Android nicht fertig übersetzt ausgeliefert,
sondern in Form von Zwischencode, der erst auf dem Endgerät in Binärcode
übersetzt wird.
Deshalb sollte es eigentlich möglich sein, bestimmte Mitigations in
bereits ausgelieferten Code einzuschleusen, indem man den Übersetzer des
Zwischencodes entsprechend anpasst. Also beispielsweise indem die
indirekten Sprünge aus Variante 2 nun systematisch durch das ARM
Äquivalent von Retpoline implementiert werden. Übersetzer austauschen
und alle Apps neu optimieren, wie es bei Firmware-Updates ohnehin
geschieht.
Klar, das wird bremsen, aber immerhin. Das sollte man dann natürlich
adaptiv machen. Wer nur A53er im Gerät stecken hat, braucht das ja
nicht.
Hat jemand davon schon mal gelesen?
Mox schrieb:> Es gibt doch aber auch Hoffnung :-)
Für die Anwender oder für Intel? ;-)
Das ergibt ein böses Umsatzloch dieses Jahr, weil jeder seine für dieses
Jahre geplanten Beschaffungen aufschieben wird, soweit möglich. Dafür
werden nächstes Jahr die Fabs heisslaufen.
Irgendwie fehlt mir noch immer so richtig der passende Angriffsplan. Die
Ausnutzung der Lücken erfordert ja einige "von hinten durch die Brust
ins Auge"-Verrenkungen. Wenn ich das richtig verstanden habe, sind die
Entdecker auf Datentransferraten im Bereich einiger kB/s gekommen.
Damit wird doch der Zugriff auf irgendwelche Nutzdaten zum reinen
Glüksspiel. Abgesehen davon, daß sich der Inhalt von dynamischen
Speicher halt doch "ab und an" mal ändert, und man mit der niedrigen
Datenrate dann zeitlich verschobene Inhalte erwischt.
Mir fehlt dazu allerdings jeder Hintergrund.
Daher die Frage an die Experten hier: Was könnte ein Angreifer denn
sinnvolles mit den Lücken anstellen?
Oliver
Oliver S. schrieb:> Daher die Frage an die Experten hier: Was könnte ein Angreifer denn> sinnvolles mit den Lücken anstellen?
Stell dir mal einen grossen Hoster vor, z.B. Amazon oder Google.
Kunde A und Kunde B haben jeweils eine eigene VM.
Jetzt kann ein Angreifer ueber einen Angriff auf Kunde A, auch die Daten
von Kunde B auslesen, z.B. Kryptographische Schluessel (SSL/TLS).
Und da so ein Hoster in der Regel mehrere tausend Kunden hat, von privat
Personen bis hin zu riesigen Konzernen, sind durch einen Angriff auf
einen Kunden, moeglicherweise viele, viele Kunden und Daten
kompromitiert.
Aber auch fuer privat Anwender:
Dadurch, dass sich die Luecke auch ueber JavaScript ausnutzen laesst
(sofern der Browser noch nicht gepatched ist, und ja, einige Menschen
halten nicht viel von Updates) kann auch da ein Angreifer z.B.
Passwoerter auslesen. Einfach das JavaScript in die tollen Werbebanner
einschleusen, und fertig.
Hier noch mal eine Erklaerung, auch fuer Leute mit wenig technischem
Hintergrund, von Radio Fritz rbb mit dem CCC:
CR242: Einmal einschmelzen bitte
Warum modernes CPU-Design uns jetzt in Teufels Küche bringt
https://media.ccc.de/v/cr242
1
Mit Meltdown und Spectre sind zwei Sicherheitslücken bekannt geworden,
2
die sich von traditionellen Problemen unterscheiden, denn sie betreffen
3
die CPU, also jene Bausteine, der das Herz eines jeden elektronischen
4
Gerätes bilden. Und weil man sie nicht einfach tauschen kann, ist es nun
5
an den Betriebssystemherstellern, die Probleme soweit wie möglich
6
einzudämmen. Doch noch sind Experten skeptisch, ob diese Maßnahmen
7
ausreichen werden. Im Chaosradio 242 werfen wir einen Blick auf die
8
aktuelle Situation. Live im Frl. Fritz in Kreuzberg versuchen wir nicht
9
nur zu erklären, was sich hinter Meltdown und Spectre verbrigt, sondern
10
auch herauszufinden, welche Konsequenzen und Lehren wir aus den Lücken
11
ziehen sollten.
Oliver S. schrieb:> Irgendwie fehlt mir noch immer so richtig der passende Angriffsplan.
Ein kleiner Tipp von mir, fuer alle die mit sowas nichts oder nur wenig
anfangen koennen:
Nur weil Ihr euch keinen Nutzen von solchen Angriffen vorstellen koennt
(und nein, man muss nicht immer alles verstehen, dazu ist die Welt der
IT zu komplex), heisst das nicht, das andere dafuer keine Anwendung
finden.
Vielleicht nutzt jemand die Luecke nur zum Spass, um zu sehen was so
geht. Andere nutzen das vielleicht um Code einzuschleusen und den
Rechner fuer ein Botnet zu uebernehmen. Aber spaetestens die
Geheimdienste haben fuer sowas verwendung. Sei es nun um
kryptographische Schluessel, Passwoerter, oder sonst was abzugreifen.
Oliver S. schrieb:> sind die> Entdecker auf Datentransferraten im Bereich einiger kB/s gekommen.
Spielt doch keine Rolle, wenn die Luecke Tage, Wochen, oder Monate offen
steht. Es wird gesammelt was geht.
Oliver S. schrieb:> Damit wird doch der Zugriff auf irgendwelche Nutzdaten zum reinen> Glüksspiel.
Irgendwas sinnvolles wird schon dabei sein. Das reicht.
50% von etwas (egal was es ist) ist mehr als 100% von nichts.
Selbst wenn man es nicht schafft, den kompletten kryptographischen
Schluessel abzugreifen: Ein kleiner Teil ist schon viel Wert, weil man
dann den Bereich fuer einen Brute-Force-Angriff verkleinern kann, oder
womoeglich sogar den Restlichen Schluessel berechnen kann.
Kaj G. schrieb:> Vielleicht nutzt jemand die Luecke nur zum Spass, um zu sehen was so> geht. Andere nutzen das vielleicht um Code einzuschleusen und den> Rechner fuer ein Botnet zu uebernehmen.
Die Lücken können ja nur zum Lesen ausgenutzt werden, schreiben geht
nicht. Und auch wenn da eine Schadsoftware im Hintergrund längerfrsitig
mitliest, bekommt die trotzdem nur Daten mit ein paar kB/s ausgelesen.
Da dauert das auslesen eines einzigen Megabytes Stunden. Und in der Zeit
werden sich die Daten darin so oft geändert haben, daß der ausgelesene
Datenblock selber als kryptografischer Einmalschlüssel verwendbar ist,
zu mehr aber auch nicht.
Wenn man ganz genau weiß, wo man Daten findet, fuktioniert das, aber mal
eben den Speicher nach bekannten Daten durchsuchen wird so nicht
klappen.
Oliver
Oliver S. schrieb:> Wenn man ganz genau weiß, wo man Daten findet, fuktioniert das, aber mal> eben den Speicher nach bekannten Daten durchsuchen wird so nicht> klappen.
Früher wusste man, an welcher Stelle im Kernel welche Informationen
liegen. Das machte es Angreifern per vorhandenem Leck leicht,
Informationen zu sammeln. Weshalb man darauf verfiel, die Adressen
zufällig zu verteilen, aka Kernel Address Space Layout Randomization =
KASLR. Das wiederum verlangte geradezu zu nach Wegen, per Side Channel
Attack diese Adressen rauszufinden. Im Rahmen dieser Thematik fand man
nicht nur einen Weg zu den Adressen, sondern auch Meltdown, den Weg zum
Inhalt.
Naja dem Meltdown-Prozeß muß man schon eine Menge Zeit geben, wie ich
das sehe und der kann auch nicht mal am nächsten Tag weitermachen, wenn
der User den Rechner abgeschaltet hat. Wenn man den Browser beendet,
sind die besonders gefährlichen Javascripte schon tot. Einen
aussichtsreichen Angriffsplan auf heimische PCs will ich sehen.
dafür hat der patch auf dem arbeits PC
für spontanes herunterfahren gesorgt :D
am 22. kam der patch ...
und ich hatte mich gewundert warum das ding nach der mittagspause aus
war
patch deinstalliert , alles wieder gut
Hallo Paul!
Paul B. schrieb:> Die Liste von A.K. hatte ich schon vorher gefunden -nur anfangen kann> ich damit nichts.
Wenn Du die Intel-Liste mit der Liste in dem folgenden Link abgleichst,
kannst Du feststellen, dass Dein Core 2 Duo E8400 nicht auf der
Intel-Liste steht.
https://en.wikipedia.org/wiki/Intel_Core
Allerdings besagt die Intel-Liste aber auch nicht, dass alle anderen
Prozessoren nicht betroffen sind.
Es bleibt also beim JEIN.
Kaj G. schrieb:> Oliver S. schrieb:>> Daher die Frage an die Experten hier: Was könnte ein Angreifer denn>> sinnvolles mit den Lücken anstellen?> Stell dir mal einen grossen Hoster vor, z.B. Amazon oder Google.> Kunde A und Kunde B haben jeweils eine eigene VM.> Jetzt kann ein Angreifer ueber einen Angriff auf Kunde A, auch die Daten> von Kunde B auslesen, z.B. Kryptographische Schluessel (SSL/TLS).> Und da so ein Hoster in der Regel mehrere tausend Kunden hat, von privat> Personen bis hin zu riesigen Konzernen, sind durch einen Angriff auf> einen Kunden, moeglicherweise viele, viele Kunden und Daten> kompromitiert.A. K. schrieb:> Früher wusste man, an welcher Stelle im Kernel welche Informationen> liegen. Das machte es Angreifern per vorhandenem Leck leicht,> Informationen zu sammeln. Weshalb man darauf verfiel, die Adressen> zufällig zu verteilen, aka Kernel Address Space Layout Randomization => KASLR.
findet man dann auch in einer akzeptablen Zeit heraus,
wo man suchen muss?
Ich mein', wenn man die Daten gefühltermassen "telexen" lassen muss,
um zu sehen was da steht und man dann auch noch tausende male ins Blaue
schiessen muss um was interessantes zu finden?
andererseits: Arbeitslose Nerds mit genügend Zeit gibts genug.
● J-A V. schrieb:> findet man dann auch in einer akzeptablen Zeit heraus,> wo man suchen muss?
Keine Ahnung, ich bin kein Hacker. Ich würde aber rein vorsorglich davon
ausgehen, dass es mit vertretbarem Aufwand möglich ist, das zu finden
wonach man sucht.
> andererseits: Arbeitslose Nerds mit genügend Zeit gibts genug.
Träumst du nachts von Gigabytes an Hexdumps statt von Schafen? Gute
Nerds suchen nicht selbst, sondern lassen suchen. Arbeitslose Rechner.
Indem sie Programme dafür bauen.
Peter M. schrieb:> Allerdings besagt die Intel-Liste aber auch nicht, dass alle anderen> Prozessoren nicht betroffen sind.>> Es bleibt also beim JEIN.
Ich verstehe nicht so ganz, warum man da keine klare Auskunft geben
kann. Dieser gezeigte Vierzeiler in Assembler müßte doch so ähnlich auf
allen Systemen laufen, zumindest als Test für Meltdown?
batman schrieb:> Ich verstehe nicht so ganz, warum man da keine klare Auskunft geben> kann.
Kommt drauf an von wem du diese Aussage haben willst.
(1) Testprogramm. Nicht trivial, da das Training des Branch Predictors
abhängig von dessen Implementierung sein kann. Eine Positivauskunft
(betroffen) wird sich ableiten lassen, eine Negativauskunft (nicht
betroffen) eher nicht.
(2) Für Spectre 1 und 2 steht die Aussage um Raum, dass diese Lücke eine
Folge des Arbeitsprinzips ist, und somit alle OOO Prozessoren betroffen
sein sollten (plus POWER6). Das wäre bei Intel fast alles ab Pentium
Pro.
(3) Will man sich bei Intel als autoritativer Quelle informieren, dann
ist man auf das entsprechende Dokument angewiesen, aus dem sich für dort
nicht explizit aufgeführte Prozessoren nichts ableiten lässt.
Ergo: Die Aussage "ist betroffen" lässt sich leichter treffen als die
gegenteilige Aussage. Und dann könnte es noch Grauwerte geben, etwa
"prinzipiell betroffen, aber praktisch nicht ausnutzbar".
batman schrieb:> Ich verstehe nicht so ganz, warum man da keine klare Auskunft geben> kann. Dieser gezeigte Vierzeiler in Assembler müßte doch so ähnlich auf> allen Systemen laufen, zumindest als Test für Meltdown?
Folgende Szenarien sind denkbar:
1. Sie wollen nicht.
Sie sehen die Altsysteme als veraltet und überholt an, verweisen auf die
durchschnittliche Lebenszeit von Rechnern im Unternehmen und wollen
keinen Ressourcen auf die Altsysteme verschwenden.
2. Sie können nicht.
Ihnen fehlt ein Testzentrum mit Althardware, auf der sie Exploits testen
können.
3. Rechtliche Konsequenzen: Sie wollen keine Einschätzung abgeben.
Sie haben Angst vor Klagen. Eine ehrliche Aussage der Form: Wir schätzen
die Wahrscheinlichkeit der Ausnutzbarkeit auf einem Core 2 Duo E8400 auf
1% oder geringer könnte sie bei Beweis des Gegenteils viel Geld kosten.
A. K. schrieb:> Gute> Nerds suchen nicht selbst, sondern lassen suchen. Arbeitslose Rechner.> Indem sie Programme dafür bauen.
die einem dann endlich sagen, von wem die Daten stammen?
BTW
meine Träume sind nicht jugendfrei,
das kann ich hier nicht schreiben ;)
first: Aluhut aufsetz.
Der Witz ist doch,
dass mit der Patcherei eine Sicherheit propagiert wird, welche de facto
weder existiert noch herstellbar ist, solange man diese HW zusammen
Software von nicht zertifizierten Herstellern nutzten will.
Und auch bei den Zertifikaten wie beim OS ist es eher wie mit Geld: Die
Vertrauenswürdigkeit ist um so stärker zu relativieren je höher der
Sicherheitsanspruch ausfällt. Und das war noch immer eine
Preis-Leistungs-Abwägung. Wobei die Qualität des nun publikumswirksam
aufgeführten Theaters eher in dem vorgeblich "ewig" unentdeckten Aspekt
liegt, denn in seiner schieren Existenz.
Vielmehr erscheint es mir als wolle man unvorbereitet und überhastet
eine Backdoor schließen, deren Aufdeckung man nicht so bald erwartet
hatte und welche sich für die Verursacher zum Boomerang zu entwickeln
droht.
Die Frage ist ob sie wirklich ungewollt auf Grund
ökonomisch-technologischer Aspekte entstand und billigend genutzt wurde,
wobei das ob für mich außer Frage steht, oder ob sie vielmehr gezielt
schon in der Entwicklung nicht geschlossen wurde.
Die zufällige Entdeckung durch verschiedene Teams nach einer initialen
Mutmaßung einer Einzelperson halte ich für eine Legende, welche leicht
zu implizieren war.
last: Aluhut ab
Namaste
● J-A V. schrieb:> A. K. schrieb:>> Früher wusste man, an welcher Stelle im Kernel welche Informationen>> liegen. Das machte es Angreifern per vorhandenem Leck leicht,>> Informationen zu sammeln. Weshalb man darauf verfiel, die Adressen>> zufällig zu verteilen, aka Kernel Address Space Layout Randomization =>> KASLR.>> findet man dann auch in einer akzeptablen Zeit heraus,> wo man suchen muss?> Ich mein', wenn man die Daten gefühltermassen "telexen" lassen muss,> um zu sehen was da steht und man dann auch noch tausende male ins Blaue> schiessen muss um was interessantes zu finden?
KASLR (Linux und Windows) ist ein Witz. Wenn der Prozessor TSX
(Transactional Synchronization Extensions) unterstützt, geht's innerhalb
von Millisekunden und man hat die "randomisierte" Basisadresse:
https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX-wp.pdf
5 ms unter Linux (i7-6700K) für die Basisadresse, etwa 0.5 Sekunden für
Kernel und alle Module. Allerdings hilft dagegen KPTI/KAISER...
https://gruss.cc/files/kaiser.pdf
Kaj G. schrieb:> MeltdownPrime & SpectrePrime: Neue Software automatisiert CPU-Angriffe> https://www.heise.de/security/meldung/MeltdownPrime-SpectrePrime-Neue-Software-automatisiert-CPU-Angriffe-3970686.html>>> MeltdownPrime and SpectrePrime:> Automatically-Synthesized Attacks Exploiting> Invalidation-Based Coherence Protocols> https://arxiv.org/pdf/1802.03802.pdf
Wer keine Lust hat den Artikeln und/oder das Paper zu lesen:
"Given our observations with mfence and lfence successfully
mitigating Spectre and SpectrePrime in our experiments,
we believe that any software techniques that mitigate Meltdown
and Spectre will also be sufficient to mitigate MeltdownPrime
and SpectrePrime.
On the other hand, we believe that microarchitectural mitigation of our
Prime variants will require new considerations. Where Meltdown and
Spectre arise by polluting the cache during speculation,
MeltdownPrime and SpectrePrime are caused by write requests
being sent out speculatively in a system that uses an
invalidation-based coherence protocol."
Mal was neues: Angriff auf SGX-Enklaven 1) mit Spectre. Es helfen nur
Microcode-Updates, Retpoline alleine reicht nicht.
https://arxiv.org/pdf/1802.09085.pdf
1) "Intel SGX is a set of central processing unit (CPU) instruction
codes from Intel that allows user-level code to allocate private regions
of memory, called enclaves, that are protected from processes running at
higher privilege levels."
https://en.wikipedia.org/wiki/Software_Guard_Extensions
F. F. schrieb:> A. K. schrieb:>> Denn "kauft sofort einen neuen Prozessor,>> aber keinesfalls von uns" bringts irgendwie nicht, oder? ;-)>> Ich habe das nur im Radio gehört und das sagten sie, dass Intel schon> neue Prozessoren hätte, die diese Sichereitslücke nicht hätten. Deshalb> schrieb ich das überhaupt.
Welche denn? Oder sind die noch in der Entwicklung?
Hier ein Auszug von mir von /prog/cpuinfo (i5-3570k):
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 6784.24
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
Gaaanz toll ;-)
Pete K. schrieb:> Welche denn? Oder sind die noch in der Entwicklung?>> Hier ein Auszug von mir von /prog/cpuinfo (i5-3570k):
Da wunderst du dich? Das ist ja noch die dritte Core-i-Generation aus
dem Jahr 2012. Gerade kommen die ersten Rechner mit der achten
Generation raus. Interessant wäre, ob die schon einen Hardware-Fix
enthalten, aber ich vermute mal nicht.
Rolf M. schrieb:> Interessant wäre, ob die schon einen Hardware-Fix> enthalten, aber ich vermute mal nicht.
Mit Glück haben die bereits den vorläufig richtigen Microcode.
A. K. schrieb:> vorläufig richtigen
Die Betonung sollte hier auf dem 1 Adjektiv liegen ;)
aja, an alle Saftyjünger unter euch, gerade haben die höchsten Stellen
für Computersicherheit in der BRD eingeräumt das 100% sichere
Computersystem eine Utopie sind und bleiben. Gleichzeitig sehen sie sich
wohl zur Beruhigung der aufgebrachten Abgeordneten gezwungen öffentlich
zu verkünden sie hätten alles unter Kontrolle und führten die
unbekannten "Hacker" am Ring durch die Manege, um sie zu lokalisieren.
Da möchte man doch Kabarettist werden, mit solchen Steilvorlagen, obwohl
das wäre zu leicht.
Namaste
Winfried J. schrieb:> aja, an alle Saftyjünger unter euch, gerade haben die höchsten Stellen> für Computersicherheit in der BRD eingeräumt das 100% sichere> Computersystem eine Utopie sind und bleiben.
... und in China ist vorhin ein Sack Reis umgefallen.
A. K. schrieb:> vorhin ein Sack Reis umgefallen.
schon wieder?
Ich hatte Ihnen erst letzten Monat ein Zertifizierung angeboten, um dies
zukünftig zu vermeiden.
Aber auf mich hört ja keiner. Resignierend den Kopf mit dem schütteren
Haar schüttelnd.--> ab
Namaste
Winfried J. schrieb:> und führten die> unbekannten "Hacker" am Ring durch die Manege, um sie zu lokalisieren.
Übst du schon fürs Kabarett? Denn ...
> Da möchte man doch Kabarettist werden, mit solchen Steilvorlagen, obwohl> das wäre zu leicht.
... einen noch nicht lokalisierten Hacker am Ring rumzuführen ist schon
ein recht bizarres Bild. ;-)
Ich habe nur zusammengefasst, vertönt wurde das auf der Pressekonferenz
gestern im Anschluss an eine Sitzung des Parlamentarischen
Kontrollgremiums des Bundestages. Leider finde ich die gesamte
Pressekonferenz nicht wieder.
Aber es war schon eine Sternstunde.
rudimente davon finden sich im ersten Beitrag allerdings haben sie die
Extrapossen da weggelassen.
http://mediathek.daserste.de/Tagesschau/tagesschau-20-00-Uhr/Video?bcastId=4326&documentId=50493528
Namaste
Kaj G. schrieb:> Der Prozessorhersteller Intel hat das Hardware-Design kommender> Hautprozessoren geändert, um sie gegen die Angriffsszenarien Spectre 2> und Meltdown zu schützen.
Ah, da war wohl der Zeitpunkt der Veröffentlichung doch ein PR-Push um
die neuen am Markt zu etablieren?
Namaste
Winfried J. schrieb:> Ah, da war wohl der Zeitpunkt der Veröffentlichung doch ein PR-Push um> die neuen am Markt zu etablieren?
Gut möglich. Da heisst es einfach abwarten und sehen, was dabei
rauskommt.
Intel muss natürlich die Leute bei Laune halten, damit die Kundschaft
nicht zu sehr abwartet oder gar auf AMD umsteigt. War da nicht grad auch
was? Honi soit qui mal y pense ;-).
Winfried J. schrieb:> gerade haben die höchsten Stellen> für Computersicherheit in der BRD eingeräumt das 100% sichere> Computersystem eine Utopie sind und bleiben.
Nein? Doch! Ohhh...
Ja, 100% sichere Computersysteme sind genau so Utopie wie alles andere
was damit wirbt, 100% sicher zu sein (inklusive Aufzügen).
Merkregel: Sicher ist nur der Tod.
Jeder, der sich ernsthaft mit der Thematik beschäftigt (das meinst du
wohl mit "Safetyjünger", weiß das).
vn nn schrieb:> Winfried J. schrieb:>> gerade haben die höchsten Stellen>> für Computersicherheit in der BRD eingeräumt das 100% sichere>> Computersystem eine Utopie sind und bleiben.>> Nein? Doch! Ohhh...>> Ja, 100% sichere Computersysteme sind genau so Utopie wie alles andere> was damit wirbt, 100% sicher zu sein (inklusive Aufzügen).
Ja. Auch die Titanic galt als unsinkbar - allerdings nicht sehr lange.
"Absolut sichere" Dinge sind ungefähr so sicher, wie "umweltfreundliche"
Dinge freundlich zur Umwelt sind.
Thread beobachten
Seitenaufteilung abschalten