Naja, nur aus Spaß werden sie bei Linux die kernel space address space
separation ja wohl nicht einbauen, zumal wenn es mit einem
entsprechenden Performanceverlust verbunden ist.
Da scheint ja jemand was richtig verbockt zu haben. Wenn z.B. bei der
spekulativen Ausführung das Verstecken der Kerneldaten nicht richtig
implementiert ist, könnte man schon mit einem einfachen "cmp"
herausfinden ob an einer bestimmten Stelle etwas steht (gut, SO EINFACH
wird es wohl nicht sein).
Joachim D. schrieb:> Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.> Da ist *nix*
Da ist was. Es ist nicht normal, wenn in Linux signifikante
Kernel-Patches ohne grösseren Vorlauf kommentarlos hektisch eingebaut
und sogar backported werden. Und Microsoft rein zufällig in einer Woche
einen Komplett-Reboot von Azure angekündig hat.
Heises sind nicht immer die schnellsten. Fefe steht früher auf. ;-)
Wie sieht es in diesem Falle eigentlich mit der
Haftung/Gewaehrleistung/(was auch immer) aus? Ich stelle mir gerade vor,
wie tausende ThinkPad-Nutzer gerne Geld von Lenovo wieder haben
moechten, da dieser Bug einen erheblichen Produktmangel darstellt. Er
kann zwar gefixt werden, aber dann sinkt moeglicherweise die Leistung
des Systems um einen signifikanten Wert. Aufjedenfall ist der Kunde in
beiden Faellen (fixen: Leistungseinbussen, nicht fixen:
Sicherheitsluecke) der Dumme.
A. K. schrieb:> Heises sind nicht immer die schnellsten. Fefe steht früher auf. ;-)
...und was Fefe meldet, lässt in der Tat Übles vermuten:
> Wie schlimm ist dieser Intel-CPU-Bug?> Der CEO von Intel hat Ende November alle Aktien verkauft,> die er verkaufen durfte.> Ein Schelm, wer einen Zusammenhang vermutet!1!!> https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
Ob es wohl auch einen Patch für Intel-Prozessoren in XP-Systemen geben
wird? Bin da echt in Sorge soweit es mein praktisch neuwertiges Notebook
angeht.
Fra N. schrieb:> Der Kunde ist immer der Dumme. Siehe VW.
Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden
Prozessor ausgetauscht.
Beim 32MB Bug von AMDs K5 lief das etwas holpriger.
Joachim S. schrieb:>> Der CEO von Intel hat Ende November alle Aktien verkauft,>> die er verkaufen durfte.>> Ein Schelm, wer einen Zusammenhang vermutet!1!!
Das wäre dann allerdings Insider-Handel und könnte ihn ggf. sogar hinter
Gitter bringen.
Kaj G. schrieb:> Wie sieht es in diesem Falle eigentlich mit der> Haftung/Gewaehrleistung/(was auch immer) aus?
Also für diese Diskussion ists derzeit wirklich etwas zu früh.
Ich tippe mal auf die Möglichkeit des unatorisierten Zugriffs auf
Fremdpages des L2 Cache durch aktuelle Prozesse.
Das würde bedeuten, dass alle sicherheitsrelvanten Prozesse das Kernel
exclusiv benötigen und am Ende alle Caches putzen müssen.
Das sieht nach viel Arbeit und neuer HW aus.
wer weis mehr darüber ?
A. K. schrieb:> Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden> Prozessor ausgetauscht.
PS: Die waren allerdings noch mehr oder weniger in Produktion und quasi
innerhalb der Garantiefrist (wenn man das so sagen kann). Also selbst
wenn Intel die aktuellen Prozessoren austauschen sollte, wird das bei
einem alten Sandy Bridge wohl nicht mehr passieren.
Winfried J. schrieb:> Ich tippe mal auf die Möglichkeit des unatorisierten Zugriffs auf> Fremdpages des L2 Cache durch aktuelle Prozesse.
Da der Kernel-Patch mit Adressräumen zu tun hat, wird es kaum der
L2-Cache sein. I/D-Caches sind physikalisch getagged. Das läuft eher in
Richtung TLB.
Eine Ring-Transition (Kernel-API) hatte bisher keinen Adressraumwechsel
zur Folge. Und genau das ist der Fix: Beim Kernel-Aufruf wird nun der
Adressraum gewechselt und damit werden automatisch die TLBs geputzt.
In neueren Prozessoren gibt es eine Art Adressraum-ID, um TLB-Flushes
bei Prozessumschaltung zu reduzieren. Die rettet das ein wenig.
> Das sieht nach viel Arbeit und neuer HW aus. wer weis mehr darüber ?
Abwarten und Tee trinken.
das klingt nach Absprachen.
"Plötzlich" wollen die Hersteller ihre Geräte verlangsamen.
erst der Apfel, jetzt Intel.
Wer ist wohl als nächstes dabei?
wer sagt dass man den "Fehler" nicht von langer Hand einplanen kann,
damit nach einer gewissen Zeit
die Leute neue CPUs (bis ganze Rechner) kaufen?
dafür hats in jedwedem Bereich zuviel Schindludwer gegeben,
als dass man noch irgendwas glauben kann.
● J-A V. schrieb:> das klingt nach Absprachen.
Wo Menschen sind, sind Verschwörungstheorien nicht weit. ;-)
> "Plötzlich" wollen die Hersteller ihre Geräte verlangsamen.
Nicht alle. AMD vermeldet, ihre Prozessoren seien nicht betroffen.
Kleine Nebenwirkung dieser Meldung war das so unterfähr einzige
technische Detail, das überhaupt bekannt ist. Nämlich der Zusammenhang
mit spekulativer Ausführung.
Insofern wäre das ein feiner Zug von Intel. Also zum genau richtigen
Zeitpunkt AMDs Umsatz ankurbeln zu wollen. Wo die jetzt nach langer Zeit
endlich wieder CPUs haben, die sich lohnen. ;-)
Harkan der Dritte schrieb:> A. K. schrieb:>> Beim 32MB Bug von AMDs K5 lief das etwas holpriger.> Was war das für ein bug?
Beim branch target cache konnte es vorkommen, dass bei erkanntem self
modifying code Befehle doppelt ausgeführt wurden. Da die Erkennung davon
allerdings nur einen Teil der Adressbits nutzte, erwischte das auch ganz
normale Programme gelegentlich. Abhängig von der RAM-Grösse. Gemerkt
haben es die GCC-Übersetzer. Dar flog bei Systemen mit mindestens 32MB
RAM oft auf die Nase.
Winfried J. schrieb:> Oder jemand hat eine backdoor offengelegt,welche jetzt kompromittiert> ist?
Vorsatz zu vermuten ist unnötig. Prozessoren dieser Klasse sind
dermassen komplex, dass keiner der Prozessoren der letzten Jahrzehnte
fehlerfrei ist. Die meisten Fehler sind relativ harmlos, oder per
Microcode-Patch behebbar. Manche nicht.
A. K. schrieb:> Nämlich der Zusammenhang> mit spekulativer Ausführung.
Das kommt hin. Das war damals vor ca. zehn Jahren ein Hype um Intels
Leistungszuwachs.
Dumm gelaufen. Wenn es aber eine bekannte Bd war, hat sie sicher viel
gebracht für Informierte. Für Intel sicher ein netter Seiteneffekt
sollange nicht öffentlich.
Namaste
Winfried J. schrieb:> Das kommt hin. Das war damals vor ca. zehn Jahren ein Hype um Intels> Leistungszuwachs.
Spekulative Ausführung gibts bei Intel seit dem Pentium Pro 1995 (AMD:
K5 1996). Seither hat sich Stück für Stück das Ausmass der Spekulation
erweitert und vertieft.
A. K. schrieb:> Fra N. schrieb:>> Der Kunde ist immer der Dumme. Siehe VW.>> Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden> Prozessor ausgetauscht.
Aber nur auf Druck. Für Ottonormalo wollten die auch nicht tauschen.
Joachim D. schrieb:> Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.> Da ist nix
Die Sicherheitluecke ist seit November bekannt und sie ist auch
dokumentiert.
Meine Dell-Lappies sind nicht betroffen - woher die Info? Nun zumindest
nicht von heise.de sondern von Intel und einer von Dell gefuehrten
Auflistung.
korax schrieb:> Aber nur auf Druck. Für Ottonormalo wollten die auch nicht tauschen.
Die wollten das auch nicht aufdecken. Errata waren damals
Firmengeheimnis. Bis dann jemand zufällig auf ein Zahlenpaar mit
Divisionfehler stiess, es in CompuServe rausblies. Von da aus landete es
im Usenet, wo ich drauf stiess und die Nacht über Zufallszahlen
dividierte. Damit war die Häufigkeit ungefähr abgeschätzt.
Seither sind Errata öffentlich. Die sind aber teils von der Kunst
geprägt, es so geschickt zu formulieren, dass es harmlos aussieht. AMD
hatte beim 32MB Bug nur den Zusammenhang mit self modifying code
erwähnt. Und wer macht das schon. Dass der auch dann erkannt wird, wenn
es keinen gibt, liessen sie wohlweisslich weg. Da kam dann erst in der
nächsten Ausgabe der Erratas.
Jörg W. schrieb:> Wer hat denn beim Apfel was verlangsamt?
Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte
Akkus nicht überfordert werden.
da es in den meisten berichten von x86 architektur die rede ist aber
nicht von amd64, bleibt die Hoffnung das erstmal nur 32bit systeme aber
nicht die 64 bit systeme von den performance verlusten betroffen sind.
A. K. schrieb:>> Wer hat denn beim Apfel was verlangsamt?>> Die Akku-Affäre.
Sagt mir gerade nix.
Ein auf einem 7 Jahre alten Laptop frisch installiertes High Sierra
lässt ihn geschwindigkeitsmäßig erscheinen wie am ersten Tag. Da habe
ich schon gestaunt, das schafft Windows gleich gar nicht, und auch die
meisten Linux-Distros nicht.
Ben W. schrieb:> da es in den meisten berichten von x86 architektur die rede ist aber> nicht von amd64, bleibt die Hoffnung das erstmal nur 32bit systeme aber> nicht die 64 bit systeme von den performance verlusten betroffen sind.
Mach dir keine Hoffnung. Das hat mit der Codierung der Befehle
sicherlich nichts zu tun. Die Page-Tables sind zwar auch verschieden,
aber nicht das spekulative Verhalten des Cores im Umgang damit.
Wenn man nicht ausdrücklich auf 32- vs 64-Bit rauswill, impliziert x86
das gesamte Spektrum.
Jörg W. schrieb:> Ein auf einem 7 Jahre alten Laptop
Es geht um Smartphones.
hast du die letzten 7 Tage keine News gelesen? :-)
Auch wenn ich Apple wegen der überteuerten Preise, der Arroganz und der
Steuervermeidung nicht leiden kann, aber das war eigentlich gut gemacht.
Besser man bremst Stromspitzen aus, als daß das gerät plötzlich abstürzt
wegen eines zu hohen Akkuinnenwiderstand.
Nur hätte man das rechtzeitig öffentlich machen sollan, aber man macht
halt lieber erst mal wieder auf "information hiding" und "Consumer is an
idiot anyway"
Ben W. schrieb:> da es in den meisten berichten von x86 architektur die rede ist aber> nicht von amd64, bleibt die Hoffnung das erstmal nur 32bit systeme aber> nicht die 64 bit systeme von den performance verlusten betroffen sind.
Aus dem Artikel von The Register:
1
...the flaw is in the Intel x86-64 hardware...
2
3
...
4
5
However, it may be that the vulnerability in Intel's chips is worse than the
6
above mitigation bypass. In an email to the Linux kernel mailing list over
7
Christmas, AMD said it is not affected. The wording of that message, though,
8
rather gives the game away as to what the underlying cockup is:
9
10
AMD processors are not subject to the types of attacks that the kernel page
11
table isolation feature protects against. The AMD microarchitecture does not
12
allow memory references, including speculative references, that access
13
higher privileged data when running in a lesser privileged mode when that
14
access would result in a page fault.
Kurz: Es sind ganzbesonders die 64 Bit Systeme betroffen.
Der Andere schrieb:>> Ein auf einem 7 Jahre alten Laptop>> Es geht um Smartphones.
Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem
x86-Prozessor? ;-) Daher wäre ich jetzt nicht auf die Idee gekommen,
dass jemand hier einen Smartphone-Bug für seine Verschwörungstheorien
heranzieht …
Das mit den iPhones hatte ich wirklich noch nicht gelesen, interessiert
mich aber auch nicht so brennend.
Kaj G. schrieb:> Kurz: Es sind ganzbesonders die 64 Bit Systeme betroffen.
Der Zusammenhang zwischen dem Bug und 64 Bits erschliesst sich mir
allenfalls insofern, als es sicherlich Altsysteme ohne diesen Bug gibt.
Aber wird man deshalb seinen alten Pentium 4 entstauben wollen?
Jörg W. schrieb:> Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem> x86-Prozessor? ;-)
Insbesondere Asus hatte einige Androids auf Atom-Basis. Da Android Apps
nur sehr selten nativen Code enthalten, sondern erst auf dem Gerät
selbst übersetzt werden, war das technisch kein Problem. Intel hat
allerdings aufgrund hartnäckiger Erfolglosigkeit den Markt wieder
aufgegeben.
Winfried J. schrieb:> wer weis mehr darüber ?
AMD erwähnt "speculative references, that access higher privileged data
when running in a lesser privileged mode when that access would result
in a page fault".
Also so etwas (stark vereinfacht):
1
if(a==42){
2
b=*zeiger;
3
c=tabelle[b];
4
}
Wenn man
1. diesen Code mit a=42 und einem gültigen Zeiger ausführt, dann
2. alle Tabelleneinträge aus dem Cache schmeißt, und dann
3. "a" und den Zeiger ändert,
dann wird die Intel-CPU den Code spekulativ ausführen. Auch wenn die CPU
dann die neuen Werte von b und c ignoriert, ist der entsprechende
Tabelleneintrag trotzdem noch im Cache, was man messen kann.
> Das würde bedeuten, dass alle sicherheitsrelvanten Prozesse das Kernel> exclusiv benötigen und am Ende alle Caches putzen müssen.
Nicht alle Caches; es genügt, die Page-Tabellen zu entfernen, so dass
"b=*zeiger" überhaupt nicht mehr mit einer Kernel-Adresse ausgeführt
werden kann.
Jörg W. schrieb:> Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem> x86-Prozessor? ;-)
In irgendeinem Artikel zu diesem Intel-Bug wurde am Ende kurz erwähnt,
dass für ARM64 derzeit offenbar ganz ähnliche massive Patches
vorbereitet werden.
Ich weiss leider gerade nicht mehr, wo genau ich das gelesen habe, aber
auch einer der im OP verlinkten Artikel erwähnt bspw. am Ende:
> PS: It appears 64-bit ARM Linux kernels will also get a set of> KAISER patches, completely splitting the kernel and user spaces,> to block attempts to defeat KASLR. We'll be following up this week.
Also ich habe das so verstanden:
Die Intel CPUs führen Code schon vorher (spekulativ) aus, der COde wird
von der Spekulativer Verzweigungs Entscheidungs Einheit vorhergesagt und
wird im Voraus im Übersetzungs Vorhersage Puffer (TLB) schon in
ausführbare Micro Instruktionen übersetzt.
Der Fehler ist, daß bei diesem Prozess nicht vorher das Privilegien
Level geprüft wird.
Später wird natürlich festgestellt, daß das Privilegien Level nicht
ausreich und der Puffer wird nicht ausgeführt, wenn jedoch dieser
Prüfbefehl übergangen werden kann wird der Puffer fälschlicherweise
augeführt.
Wie der Prüfbefehl übergangen werden kann hab ich mich jetzt nicht
weiter beschäftigt...
Joachim S. schrieb:> In irgendeinem Artikel zu diesem Intel-Bug wurde am Ende kurz erwähnt,> dass für ARM64 derzeit offenbar ganz ähnliche massive Patches> vorbereitet werden.
Man scheint gleich zwei Probleme mit der Adressraumtrennung erschlagen
zu wollen. Eines davon ist der bereits erwähnte Bug bei Intel. Das
andere Problem ist den spärlichen Informationen zufolge eher
prinzipieller Natur und betrifft so ziemlich alles, was Pagetables
verwendet.
uwe schrieb:> wird im Voraus im Übersetzungs Vorhersage Puffer (TLB) schon in> ausführbare Micro Instruktionen übersetzt.
Der TLB übersetzt lediglich lineare in physikalische Adressen. Mit
Befehlen hat er nichts zu tun.
Clemens L. schrieb:> Nicht alle Caches; es genügt, die Page-Tabellen zu entfernen, so dass> "b=*zeiger" überhaupt nicht mehr mit einer Kernel-Adresse ausgeführt> werden kann.
Danke, so tief bin ich zuvor nicht eingetaucht. Seit den 586 bin ich
froh das Prinzip hinter den Neuerungen zu kennen, aber ich bin auch nur
User solcher Technologie.
Namaste
"sind mehr oder weniger alle im letzten Jahrzehnt ausgelieferten
Intel-Prozessoren von einem Problem getroffen, das die von ihnen
angetriebenen Computer angreifbar macht"
muahaha, Nachtigall ick hör dir trapsen
Das is wahrscheinlich eine/die absichtlich in Absprache mit dem
NSA/FBI/CIA eingebaute backdoor, wo bisher deren Schnüffel-Programme
drüber Zugriff auf die Rechner hatten.
Entweder hats jetzt einer verraten oder diese backdoor wurde durch was
moderneres ersetzt und wird nicht mehr gebraucht/benutzt.
Evtl. hab ich aber auch nur zuviel Tom Clancy gelesen...
Mike B. schrieb:> Das is wahrscheinlich eine/die absichtlich in Absprache mit dem> NSA/FBI/CIA eingebaute backdoor, wo bisher deren Schnüffel-Programme> drüber Zugriff auf die Rechner hatten.
Das als "wahrscheinlich" zu betrachten ist doch eher eine
Verschwörungstheorie. Gerade sieht es danach aus, als bräuchte man schon
mindestens Userspace-Zugriff um in die Kernelebene vorzudringen.
> Entweder hats jetzt einer verraten oder diese backdoor wurde durch was> moderneres ersetzt und wird nicht mehr gebraucht/benutzt.
Es gibt genügend Leute die gezielt nach so etwas suchen und dann
veröffentlichen werden. Also ist auch hier keine Verschwörungstheorie
angebracht.
Leider sind noch zu wenig Details bekannt um wirklich abschließend etwas
aussagen zu können. Diese Systeme sind hoch komplex. Da kommt es schon
mal vor, dass Implementierungsfehler gemacht werden.
Da Linux einen Update Mechanismus für Microcode besitzt, kann man,
sobald ein Patch bereitsteht, sein System damit updaten, sofern sich der
Bug überhaupt mit Microcode behandeln lässt:
https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t
Im TGZ sind Anleitungen und Dateien für alte Systeme (mit
/dev/cpu/microcode Verzeichnis) und für neuere mit
'/sys/devices/system/cpu/microcode/reload' Mechanismus.
Die Intel ME aber bleibt bestehen und ist vermutlich die
undurchsichtigste Sicherheitslücke.
Matthias S. schrieb:> sofern sich der Bug überhaupt mit Microcode behandeln lässt:
In diesem Fall ist das ziemlich unwahrscheinlich. Per Microcode lassen
sich komplexe Befehle reparieren und fehlerhafte Befehlsgruppen und
Beschleunigungsoptionen abschalten. Aber das grundsätzliche Verhalten
des OOO-Cores im Umgang mit Mikro-Ops wird damit kaum reparabel sein.
Zudem wär dann keine Hektik bei den Kernelbauern, sondern bei den
PC-Herstellern (wie etwa bei ME).
A. K. schrieb:> In diesem Fall ist das ziemlich unwahrscheinlich.
Ich habs jetzt trotzdem mal auf meine Box gespült, die gerade von wheezy
auf jessie hochgepeitscht wurde und schau dann ab und zu mal bei Intel
vorbei. Mal sehen, ob sich da in nächster Zeit was tut - der letzte
Update bei denen war vom 17. November 2017.
Thomas schrieb:> Der Link lässt sich nicht öffnen.
Da steht auch nur, das der Support von XP eingestellt wurde - hast nix
versäumt. Die absolut letzte Tat war das Wegpatchen der 'WannaCry'
Verletzlichkeit im Frühjahr.
Der Spass beim o.a. MS Link ist ja der Untertitel:
> Gilt für: Windows 10
:-)
A. K. schrieb:> Harkan der Dritte schrieb:>> A. K. schrieb:>>> Beim 32MB Bug von AMDs K5 lief das etwas holpriger.>> Was war das für ein bug?>> Beim branch target cache konnte es vorkommen, dass bei erkanntem self> modifying code Befehle doppelt ausgeführt wurden.
PS: Es war der K6, nicht der K5.
meckerziege schrieb:> Mike B. schrieb:>> Das is wahrscheinlich eine/die absichtlich in Absprache mit dem>> NSA/FBI/CIA eingebaute backdoor, wo bisher deren Schnüffel-Programme>> drüber Zugriff auf die Rechner hatten.> Das als "wahrscheinlich" zu betrachten ist doch eher eine> Verschwörungstheorie. Gerade sieht es danach aus, als bräuchte man schon> mindestens Userspace-Zugriff um in die Kernelebene vorzudringen.
"Was der Bauer nicht kennt, das gibt es auch nicht!"
und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung
die Wahrscheinlichkeit dass es solche backdoors gibt ist mindestens
genauso hoch wie die, das wir davon nix wissen.
Aus der Erkenntnis, dass zumindest die Russen und wahrscheinlich auch
die Chinesen eigene Chips und nicht INTEL in ihre Militärtechnik
einbauen, lassen sich evtl. doch gewisse Erkenntnisse derer
Entwicklungsabteilungen über die Intel-Chips ableiten.
Die Lösung ist, eine Abstraktionsebene hinzuzufügen. Die gibt sogar
bereits: FPGAs. Mit Softcores (beispielsweise RISC-V) auf FPGAs wird so
etwas beliebig schwierig. Denn die tatsächliche HW (beim FPGA die
SRAM-Zellen, die die Konfig halten), "verstehen" das Design nicht und
ein tatsächliches Flipflop des RISC-V kann nahezu beliebig im
FPGA-Fabric platziert werden.
Da gibts aber 3 Probleme:
1.: Viel teurer als die "harte Lösung"
2.: Energiehungriger als die "harte lösung"
3.: Braucht wesentlich mehr Silizium-Platz als die "harte Lösung"
Dem Aktienkurs von AMD scheint die Sache ganz gut zu bekommen.
Intel schien ja den Kampf um die lieben kleinen Prozessoren gewonnen zu
haben, aber AMD hat voriges Jahr doch wieder Bewegung reingebracht. Und
das hier dürfte gut für den Wettbewerb sein. Keine schöne Vorstellung,
wenn eine einzige Firma 90% des Marktes beherrscht.
A. K. schrieb:> Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte> Akkus nicht überfordert werden.
Was ja durchaus vernünftig ist... Hat aber einige Idioten nicht daran
gehindert, im Land der unbegrenzten Unmöglichkeiten gleich deswegen
gegen Appel zu klagen. Man darf gespannt sein, was dabei heraus kommt.
1., 2., 3. sind jeweils nur relativ. Zudem ergäben sich Vorteile durch
mehr Heterogenität. Eine Stelle, die Sound verarbeitet, muss nicht auch
Grafik verarbeiten können. Lediglich die "harte Lösung" erzwingt
derartige Universalität, auch aufgrund fehlender
Veränderbarkeit/Anpassbarkeit.
Uhu U. schrieb:> Man darf gespannt sein, was dabei heraus kommt.
Längst bekannt: Neue Akkus zum Spottpreis (für die Verhältnisse von
Apple). Bei den 6ern war der Akku noch einigermassen selbst tauschbar,
aber danach nicht mehr. Einziger Haken: Man lebt einige Tage ohne
iPhone, also vielleicht künstliches Koma oder so.
Wenn Bescheid gegeben worden währe das gedrosselt wird und wie es
behoben werden kann währe es schon in Ordnung gewesen.
Aber so ist das doch ein mieses Vorgehen
Das ist doch nur das übliche Marketing Blabla.
Wenn Batterien Verschleißteile sind.
Warum wird dann nicht gesagt wenn sie hinüber sind?
Warum ermöglicht man nicht das Tauschen?
So sagt man nur das Apple Geräte als ganzes Verschleißteile sind.
War da nicht eine Aussage von Apple bei einer Gerichtsverhandlung das
ihre Geräte nur für eine Lebensdauer von einem Jahr ausgelegt sind und
das der Kunde das auch von ihnen erwartet?
Und lese ich da richtig aus dem Text heraus das Apple auch bei den neuen
Geräten anstatt ordentlich dimensionierter Akkus lieber Schrott verbaut
und weiterhin fröhlich drosseln wird.
Der Lipo in meinem Nokia 3510 Monochrom Arbeits-Handy ist jetzt nach
über 10 Jahren noch einigermaßen fitt und hat eine längere Laufzeit als
ein neues Wischerhandy.
mich stört, dass der bug 10 jahre lang unentdeckt und damit ungepatcht
blieb.
einerseits. andererseits stützt das meine these, dass entwickler (egal
ob soft- oder hardware) ab einer bestimmten komplexität keinen überblick
mehr haben was die frameworks die sie benutzen eigentlich genau
machen.
das verhalten der verbuggten CPU's ist nicht nur den intel entwicklern
bei verschiedenen CPU versionen 10 jahre lang nicht aufgefallen, sondern
auch den kernelentwicklern von windows, linux...
wer hat den bug eigentlich gefunden?
Mike B. schrieb:> "Was der Bauer nicht kennt, das gibt es auch nicht!"> und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung
Erstens kann ich als nicht-angemeldeter Benutzer gar nicht bewerten...
Zweitens ist mir die Hardwaresicherheit nicht gerade fremd, da ich
selbst schon Schwachstellen in ICs aufgedeckt und darüber publiziert
habe. Damit sollte sich die Frage erübrigen, wer hier "der Bauer" ist
;-)
Es ist sehr schwierig, wenn nicht unmöglich, Hardware auf 100% zu
testen. Besonders Grenzfälle mit sehr knappem Timing führen immer mal
wieder zu Fehlern.
Schau einfach mal in die Errata von aktuellen Mikrocontrollern, das ist
oft überraschend viel.
> die Wahrscheinlichkeit dass es solche backdoors gibt ist mindestens> genauso hoch wie die, das wir davon nix wissen.
Wenn du dir Sorgen machen willst, dann schau dir die Intel Management
Engine an.
Einen Bug in Hardware fest einzubauen, mit dem vom Userspace Zugriff auf
den Kernelspace erlaubt wird, ist auch gar nicht notwendig => siehe
Intel ME. Ähnliches könnte man übrigens auch mit Microcode-Schadcode
erreichen.
> Aus der Erkenntnis, dass zumindest die Russen und wahrscheinlich auch> die Chinesen eigene Chips und nicht INTEL in ihre Militärtechnik> einbauen, lassen sich evtl. doch gewisse Erkenntnisse derer> Entwicklungsabteilungen über die Intel-Chips ableiten.
Militärtechnik ist nochmal ein ganz anderes Gebiet, da spielen viel mehr
Faktoren mit rein. Abhängigkeit von externen Lieferanten, spezifizierter
Temperaturbereich, Zuverlässigkeit, Fehlertoleranz,
Strahlungsempfindlichkeit, etc. => Sehr vieles was für den normalen
CPU-User gar nicht relevant ist.
meckerziege schrieb:> Mike B. schrieb:>> "Was der Bauer nicht kennt, das gibt es auch nicht!">> und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung>> Erstens kann ich als nicht-angemeldeter Benutzer gar nicht bewerten...
Ich meinte auch nicht dich persönlich, da ich eben nicht weiss von wem
die -1 kam. Es war allgemein an unbekannt adressiert.
c.m. schrieb:> mich stört, dass der bug 10 jahre lang unentdeckt und damit ungepatcht> blieb.
Der Bug wird bei korrekten Programmen nicht zu Fehlverhalten führen.
Sondern es ermöglichen, auf mehr der weniger komplizierte Art an
verborgene Informationen heranzukommen. Vor 10 Jahren gab es deutlich
weniger Leute, die ihre ganze Energie darauf konzentrieren, genau danach
zu suchen.
Im Zusammenhang mit den Kernel Patches wird ASLR erwähnt. Das ist eine
Massnahme, die Buffer Overflows schwerer ausnutzbar macht. So arg alt
ist die jedoch noch nicht. Erst "Seit Kernelversion 3.14 gibt es eine
vollständige Implementierung von ASLR. Ab Version 4.8 kollidiert die
Kernel Address Space Layout Randomization (KASLR) nicht mehr mit der
Hibernate-Funktion." (Wikipedia)
> wer hat den bug eigentlich gefunden?
Geduld ist eine seltene Tugend. ;-)
Uhu U. schrieb:> A. K. schrieb:>> Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte>> Akkus nicht überfordert werden.>> Was ja durchaus vernünftig ist... Hat aber einige Idioten nicht daran> gehindert, im Land der unbegrenzten Unmöglichkeiten gleich deswegen> gegen Appel zu klagen. Man darf gespannt sein, was dabei heraus kommt.
Ja, es ist vernünftig, unvernünftig und Ursache der Klagen ist das Apple
das nicht kommuniziert hat und den Akku auch fest eingebaut hat.
Gruß,
Holm
Mike B. schrieb:> "Was der Bauer nicht kennt, das gibt es auch nicht!"> und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung
Auch wenn wir in einer Zeit leben, in der paranoides Denken in
unangenehm hohem Umfang gerechtfertigt ist: Die meisten Fehler in
Produkten sind immer noch einfach nur Fehler. Kein böser Wille.
Wer genug um die Komplexität moderner Prozessoren weiss, der hat m.E.
kein Problem, sich das einfach nur als Fehler vorzustellen. Dein Bauer
jedoch, der erklärt sich ihm unverständliche Dinge gerne mit Gott oder
Teufel. Früher wie heute.
Marc H. schrieb:>> Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem>> x86-Prozessor? ;-)>> Nokia Lumia mit WindowsPhone
Lumias hatten m.W. durchweg ARM Prozessoren drin. Nicht alles wo Windows
draufsteht hat x86 drin.
A. K. schrieb:> Lumias hatten m.W. durchweg ARM Prozessoren drin. Nicht alles wo Windows> draufsteht hat x86 drin.
Bei den Lumias , Nokia und Microsoft, gab es nur mit Qualcom SoC.
Die ja auf ARM basieren.
Prozessoren im Smartphone wie beim PC, werden nicht verwendet.
Da hat Intel aber Glück gehabt, dass Sie mit SoC für Smartphones nie in
den Markt gekommen sind.
@ A.K.
wer eine grobe Ahnung von der Komplexität sowohl der Prozessoren wie der
resultierenden Begehrlichkeiten hat, vermag auch mögliche Schnittmengen
zu überschlagen ohne zwangsläufig Kenntnis in allen Details zu
benötigen.
Das geht auch ohne Hinzuziehung extranatürlicher Entitäten.
Namaste
Winfried J. schrieb:> Das geht auch ohne Hinzuziehung extranatürlicher Entitäten.
Im Sinn meiner Aussage sind deine Begehrlichen die modernen Nachfolger
der extranatürlichen Entitäten. Insofern sehe ich deine Aussage eher als
Bestätigung von meiner. ;-)
OS schrieb:> A. K. schrieb:>> Lumias hatten m.W. durchweg ARM Prozessoren drin. Nicht alles wo Windows>> draufsteht hat x86 drin.>> Bei den Lumias , Nokia und Microsoft, gab es nur mit Qualcom SoC.> Die ja auf ARM basieren.> Prozessoren im Smartphone wie beim PC, werden nicht verwendet.
Nicht mehr wirklich, aber ich meine in letzter Zeit wieder mal was von
einem Atom basierten Phone gelesen zu haben.
> Da hat Intel aber Glück gehabt, dass Sie mit SoC für Smartphones nie in> den Markt gekommen sind.
Eigentlich schade, ich hatte mal ein Asus ME302C, das ist dank Atom
gerannt wie Sau unter Android x86, und das schon 2013. Leider sind die
bei Android 4.3 stehen geblieben...
Christian R. schrieb:> Eigentlich schade, ich hatte mal ein Asus ME302C, das ist dank Atom> gerannt wie Sau unter Android x86,
Intel war in Summe voll konkurrenzfähig, bei halb so viel Cores, hatte
also eine wesentlich bessere Leistung pro Core. Das ist für den Eindruck
der Geschwindigkeit klar im Vorteil.
Ist beim PC nicht anders, ein Dualcore bringt bei gleicher oder nur
unwesentlich geringerer Gesamtleistung subjektiv meist mehr als ein
Quadcore.
Uhu U. schrieb:> A. K. schrieb:>> Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte>> Akkus nicht überfordert werden.>> Was ja durchaus vernünftig ist... Hat aber einige Idioten nicht daran> gehindert, im Land der unbegrenzten Unmöglichkeiten gleich deswegen> gegen Appel zu klagen. Man darf gespannt sein, was dabei heraus kommt.
Ob es nun vernünftig ist, heimlich die Performance massiv auszubremsen,
damit der Benutzer nicht merkt, dass der Akku schon langsam nix mehr
taugt, ist wohl Ansichtssache.
A. K. schrieb:> Ist beim PC nicht anders, ein Dualcore bringt bei gleicher oder nur> unwesentlich geringerer Gesamtleistung subjektiv meist mehr als ein> Quadcore.
Bei welchem Anforderungsprofil?
Sheeva P. schrieb:> A. K. schrieb:>> Ist beim PC nicht anders, ein Dualcore bringt bei gleicher oder nur>> unwesentlich geringerer Gesamtleistung subjektiv meist mehr als ein>> Quadcore.>> Bei welchem Anforderungsprofil?
Normale Mail/Browser/Office Umgebung.
Die interaktiv spürbare Reaktionszeit von Programmen bestimmt sich aus
einem Mix aus parallelisierbaren Aufgaben (mehrere Threads teilen sich
die Arbeit gleichermassen) und rein sequentiellen Operationen (ein
Thread dominiert). Mehrere Cores verbessern die Laufzeit des
parallelisierbaren Teils, aber nicht die des sequentiellen Teils.
Ist nun der Anteil parallelisierten Codes recht überschaubar, wie das
bei obigem Profile weiterhin der Fall ist, wird die Reaktionszeit
wesentlich von der Zeit bestimmt, die sequentiellen Aufgaben zu
erledigen.
Wenn 2 CPUs in gut parallelisierbaren Benchmarks die gleiche
Summenleistung haben, ein Dualcore und ein Quadcore, dann hat beim
Dualcore der einzelne Core die doppelte Leistung gegenüber einem Core
des Quadcores. Folglich kann der Dualcore den sequentiellen Teil doppelt
so schnell ausführen wie der Quadcore. Und ist folglich spürbar
schneller.
Wenn man sich also nicht gezielt auf länger dauernde, stark
rechenintensive und gut parallelisierbare Aufgaben konzentriert, sondern
am PC/Handy mit Allerweltsaufgaben sitzt und die Performance daran
bemisst, wie flott die Kiste sich anfühlt, wird eine gute single thread
Performance weiterhin eine wesentliche Rolle spielen.
Im Grunde ist das nichts anderes als Amdahls Law.
Eine der Möglichkeiten, den Inhalt einer nicht direkt zugreifbaren
Speicherstelle *mem rauszufinden, sieht wohl sinngemäss ungefähr so aus.
Als Schema, nicht als Code zu verstehen:
for (uint8_t a = 0; a < 256; ++a) {
char b; // in vom Rest getrennter Cache Line
..b aus dem Cache werfen..
if (cond) { // als true vorhergesagt, spät als false erkannt
..auf b genau und nur dann zugreifen wenn *mem==a..
..nicht selbst über spekulativen Code, CMOV kann helfen..
}
..Laufzeit von Zugriff auf b messen..
if (b ist offensichtlich im Cache)
return a; // *mem==a trifft zu
}
Weil das einige hier unterschätzen:
Die Lücke lässt sich angeblich über Javascript ausnutzen.
Anbei ein Beispiel, wieviele Scripte SPON nachlädt. Das kann kein Mensch
mehr kontrollieren, insbesondere niemand bei SPON mehr. Und es gibt
Seiten, die treiben es deutlich bunter.
D.h. wenn das stimmt, ist die Gefahr riesig. Viele Webseiten verwenden
viele Skripte aus vielen Quelle, auch seriöse Webseiten. Es reicht ein
gehackter Adserver, um das breit zur Anwendung zu bringen.
Die Regel "Hirn an" funktioniert deswegen nicht mehr. Selbst bei
seriösesten Seiten muss man immer damit rechnen, dass ein Werbebanner
ein böses Skript mitbringt.
Mich stört die Skriptinflation schon länger, aber damit scheine ich zu
einer Minderheit zu gehören...
A. K. schrieb:> Eine der Möglichkeiten, den Inhalt einer nicht direkt zugreifbaren> Speicherstelle *mem rauszufinden, sieht wohl sinngemäss ungefähr so aus.
Der Unterschied zwischen Intel und AMD könnte in diesem Beispiel darin
bestehen, dass Intel im Load von *mem ein TRAP Flag setzt, die
Load-Operation unter bestimmten Randbedingungen bzgl TLB/Caches aber
trotzdem durchführt und das Ergebnis in noch spekulativen Folgebefehlen
genutzt werden kann. Wenn AMD demgegenüber nicht nur das TRAP Flag
setzt, sondern auch kein Ergebnis liefert, wäre dieser Angriff nicht
möglich.
Entspricht oben Variante 3, CVE-2017-5754.
Statement von AMD: http://www.amd.com/en/corporate/speculative-execution
Javascript schrieb:> Mich stört die Skriptinflation schon länger, aber damit scheine ich zu> einer Minderheit zu gehören...
Es stöhrt viele Menschen wenn man die Nutzerzahl von uMatrix, NoScript
usw. betrachtet.
Manche Seiten wie Netflix usw. haben mitunter >99 Scripte direkt auf der
Seite eingebunden.
Kaj G. schrieb:> Ich lehne mich mal etwas aus dem Fenster und sage:> Die Kacke ist am dampfen... und zwar so richtig.
Umso dampfender, je weniger Kontrolle man über den auf der Kiste
laufenden Code hat. Clients sind schon per Browser direkt betroffen,
ebenso natürlich die Hoster/Cloud-Provider. Installierte Programme
können Unfug treiben, aber das können sie oft sowieso schon.
Reine Web/DB/App-Server sind deutlich weniger betroffen, zumindest
solange sie keinen externen Code dynamisch nachladen und Updates
vertrauenswürdig sind. Die sind aber ebenso dran, wenn andere Bugs die
Ausführung von eingeschleustem Code ermöglichen, zumal die bisherige
Sicherheitsmassnahme KASLR nicht mehr viel Wert ist.
Wenn ich die neuesten Infos (Google Blog-Eintrag etc.) richtig verstehe,
dann ist es also ungefähr so:
- es gibt einen Hardware-Bug, dem man den Namen "Meltdown" gegeben hat.
Dieser Bug betrifft nur Intel-CPUs
- dieser Bug ist allerdings im Grunde nur eine besonders leicht
ausnutzbarer Spezialfall einer viel grösseren Sicherheitslücke, die
"Spectre" getauft wurde, und die alle drei grossen CPU-Hersteller
(Intel, ARM, AMD) und fast alle CPUs betrifft
Was ich übrigens merkwürdig finde: Laut Wikipedia wurde der
"Meltdown"-Bug der Intel-CPU quasi gleichzeitig, aber unabhängig
voneinander von drei verschiedenen Institutionen entdeckt:
- Google's Project Zero
- Cyberus Technology
- Graz University of Technology
(Quelle:
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)#History)
Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem
Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast
gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen
entdeckt wird?
Die einzige Erklärung, die mir auf Anhieb einfällt, ist, dass zu der
Zeit mglw. bereits eine Schadsoftware im Umlauf war, die diese
Sicherheitslücke ausgenutzt hat, und die dann fast gleichzeitig von
mehreren Sicherheits-Teams untersucht wurde. Oder wie lässt sich das
sonst erklären?
Joachim S. schrieb:> - dieser Bug ist allerdings im Grunde nur eine besonders leicht> ausnutzbarer Spezialfall einer viel grösseren Sicherheitslücke
Es sind 3 völlig verschiedene Szenarien, die aber alle vom gleichen Fix
behoben werden. Wenn man die fehlende Kernel-Isolation nicht schon
selbst als Sicherheitslücke sieht.
> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?
Weil einer eine noch nicht fertig durcherforschte Idee hat, diese im
Sommer 2017 öffentlich macht, und sich danach die Habichte darauf
stürzen. Beispielsweise
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
Joachim S. schrieb:> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?
Das Problem ist bereits seit langem bekannt, aber keiner der Wissenden
wollte ohne Anlass allein seinen Hals riskieren.
Lars R. schrieb:> Joachim S. schrieb:>> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem>> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast>> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen>> entdeckt wird?>> Das Problem ist bereits seit langem bekannt, aber keiner der Wissenden> wollte ohne Anlass allein seinen Hals riskieren.
Oder die Lücken waren gar keine Lücken.
Möglicherweise ist möglicherweise iregenwas über dieses schöne
Hintertürchen durchgesickert, und die "falschen" Stellen fangen an, das
auszunutzen. z.B. die falschen Geheimdienste oder Kriminelle, was ein
Schließen nötig macht.
Dann kann man das einfach ein paar Informationen durchsickern lassen
(indem man eine Idee äußert oder ähnliches) und die Lücke finden lassen.
Dann muss sie geschlossen werden.
Das ist natürlich reine Spekulation.
Auch denkbar:
Es reicht ja schon die Vermutung, dass das ein Hintertürchen ist, um die
viele Leute zum Schweigen zu bringen. Wer will schon für ein bischen
Ruhm die Aufmerksamkeit der falschen Leute erregen?
Hmm schrieb:> Oder die Lücken waren gar keine Lücken.
Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten
der Sicherheit. Ganz klassisch.
> Möglicherweise ist möglicherweise iregenwas über dieses schöne> Hintertürchen durchgesickert, ...
Du meinst, MIL macht seit Jahrzehnten für alle ihre PCs und Geräte,
sowie den Geräten der Vertragspartner mit den Kernelpatches rum? Für
Windows und Linux? Für jede Kernelversion? Glaube ich nicht. Oder meinst
Du, die setzen sich absichtlich ihrer eigenen Schwachstelle aus? Glaube
ich auch nicht.
Hmm schrieb:> Lars R. schrieb:>> Joachim S. schrieb:>>> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem>>> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast>>> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen>>> entdeckt wird?>>>> Das Problem ist bereits seit langem bekannt, aber keiner der Wissenden>> wollte ohne Anlass allein seinen Hals riskieren.>> Oder die Lücken waren gar keine Lücken.
Auf Twitter liest sich das eher so, als ob bestimmte Leute das nicht als
Sicherheitsluecke eingestuft haben, weil es kein PoC (Proof of Concept)
gab. KAISER sollte demnach wohl schon auf der Black Hat USA vorgestellt
werden, was aber abgelehnt wurde.
https://twitter.com/lavados/status/948536300830851072
1
Daniel Gruss @lavados
2
3
#FunFact: We submitted #KAISER to #bhusa17 and got it rejected.
4
We can just assume that it lacked practical relevance or had no
Lars R. schrieb:> Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten> der Sicherheit. Ganz klassisch.
Wobei das in den 90ern keine konkrete Alternative war, sondern höchstens
eine allgemeine. Klar war damals IMHO nur, dass mit der Komplexität der
Implementierung von CPUs, besonders bei OOO execution, ganz allgemein
das Risikoniveau steigt.
Und auf Ideen muss immer erst jemand kommen, die fallen nicht von allein
und sofort von den Bäumen. So lange niemand auf die Idee kam,
Laufzeiteffekte von Befehlsausführung in Abhängigkeit von spekulativer
Ausführung zu testen, tauchte das auf keinen Radar auf.
Dass viel sich nachher fragen, wieso sie nicht vorher drauf gekommen
sind, ist völlig normal. Das ist meistens so.
Kaj G. schrieb:> Auf Twitter liest sich das eher so, als ob bestimmte Leute das nicht als> Sicherheitsluecke eingestuft haben, weil es kein PoC (Proof of Concept)> gab. KAISER sollte demnach wohl schon auf der Black Hat USA vorgestellt> werden, was aber abgelehnt wurde.
Ach. Und wenn Sie einen Proof of Concept gehabt hätten, dann hätten sie
das so auf der Konferenz vorgestellt dürfen?
A. K. schrieb:> Lars R. schrieb:>> Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten>> der Sicherheit. Ganz klassisch.>> Wobei das in den 90ern keine konkrete Alternative war, sondern höchstens> eine allgemeine. [...]> Und auf Ideen muss immer erst jemand kommen, die fallen nicht von allein> und sofort von den Bäumen. So lange niemand auf die Idee kam,> Laufzeiteffekte von Befehlsausführung in Abhängigkeit von spekulativer> Ausführung zu testen, tauchte das auf keinen Radar auf.
Naja. Man kann keinen Weg gehen, der einem aus technologischen oder
wirtschaftlichen Gründen versperrt ist. Deshalb will ich niemanden aus
der Vergangenheit kritisieren.
Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in
dem Maße den Interessen des Anwenders dienen, wie dies technologisch und
auch wirtschaftlich möglich wäre.
Lars R. schrieb:> Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in> dem Maße den Interessen des Anwenders dienen, wie dies technologisch und> auch wirtschaftlich möglich wäre.
???
Lars R. schrieb:> Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in> dem Maße den Interessen des Anwenders dienen, wie dies technologisch und> auch wirtschaftlich möglich wäre.
Du schreibst in Rätseln.
Wem dienen denn die CPU-Architekturen sonst? Den Geheimdiensten?
Dem Satan™? Der Weltverschwörung?
Dass Intels Architektur nicht unbedingt der Stein der Weisen ist,
das zeigt letztlich der Siegeszug von ARM im Mobilbereich. Sie haben
damals wohl beim Aufkommen von RISC ihre Felle davon schwimmen sehen
und haben auf Teufel komm raus versucht, alles das, was man bei RISC
dem Compiler als Intelligenz überlassen wollte, stattdessen in die
CPU zu stopfen. Da das Silizium aufgrund kleiner werdender Strukturen
immer billiger wurde, ging diese Rechnung technologisch sogar
einigermaßen auf – wenn man davon absieht, dass ein riesiges, Strom
fressendes Gattergrab aus diesen CPUs geworden ist. Wie man nun sieht,
durchaus eins, das am Ende wohl auch keiner mehr überblickt.
Aber: sie haben mit dieser Strategie im Desktop- und Serverbereich RISC
tatsächlich nahezu verdrängt. CPUs mit deutlich schönerer Architektur
(wie UltraSPARC) sind auf der Strecke geblieben, übrig ist noch PowerPC
–
und ARM halt.
AMD hat weitgehend nur nachgezogen, mit einer Ausnahme: amd64. Da
hatten sie die Nase vorn, Intel hatte sich mit dem Itanium verrannt.
Da musste dann ein Windows-Release warten, bis Intel eiligst ihr
Pendant auch fertig hatte, und man hat die Architektur dann schnell
noch in "x86_64" umgetauft, um nicht so sehr an die große Glocke zu
hängen, dass hier AMD tatsächlich mal Innovation eingebracht hat.
Allerdings bewegte sich auch diese Innovation natürlich nach wie vor
in dem Gattergrab-CISC-Bereich, in dem auch Intel zu Hause ist.
Hmm schrieb:> Auch denkbar:> Es reicht ja schon die Vermutung, dass das ein Hintertürchen ist, um die> viele Leute zum Schweigen zu bringen. Wer will schon für ein bischen> Ruhm die Aufmerksamkeit der falschen Leute erregen?
Willkommen im Club,
hier dein ALU-Hut, trage ihn mit Stolz und Würde, denn die wirst du
brauchen.
Ockhams Messer ist scharf und wird besonders gern an den Hals derer
angesetzt, welche zu laut denken. Denk leise an Mrs. Chalsea Manning.
oh Lars,
du brauchst auch einen Bitte hier ist deiner.
Namaste
A. K. schrieb:> Lars R. schrieb:>> Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in>> dem Maße den Interessen des Anwenders dienen, wie dies technologisch und>> auch wirtschaftlich möglich wäre.>> ???
Wie ich oben schon schrieb: "Virtualisierung" der CPU-Architektur mit
FPGA. Natürlich haben kommerzielle IC-Entwickler und IC-Verkaufer kein
Interesse daran, sich selbst obsolet zu machen.
Hypothetisches Beispiel: RISC-V Multicore auf aktuellem FPGA. Dazu
Linux.
Aktuell sind die Softcores noch etwas zu langsam, aber viel fehlt nicht
mehr. Dann genügt das für Office und co. Ob der Rechner deshalb 50EUR
mehr kostet, spielt nur eine untergeordnete keine Rolle.
Ein Zwischenschritt ist die Verwendung von CPU hard macros (ab 1...2GHz)
und der Peripherie als "virtuelle" Realisierung.
Wenn wir so weit sind, wird vieles wieder aus der CPU "heraus wandern".
Das System wird dadurch konzeptionell bedingt leistungsfähiger und
sicherer (thematisch verwandt mit Microkernel).
Dateisystem, Sound, usw. läuft dann gar nicht mehr auf der "zentralen"
CPU.
Vielmehr läuft das Dateisystem dann auf einer CPU, die nur das macht und
nichts anderes. Alles wird auf dem Chip zusammengebunden, zB mittels NoC
(Network on Chip).
Jörg W. schrieb:> Du schreibst in Rätseln.>> Wem dienen denn die CPU-Architekturen sonst?
Hoffe, es war verständlich, sonst frag nach.
Lars R. schrieb:> "Virtualisierung" der CPU-Architektur mit FPGA.
Also Stromfresser ohne Ende.
Außerdem: wer soll das bezahlen?
Bei meinem vorigen Brötchengeber wurde ein FPGA gesucht, mit dem man
einen IC emulieren kann, der am Ende weniger als 10 Währungseinheiten
(EUR oder USD) im Verkauf kostet. Das Teil war so komplex, dass das
dafür nötige FPGA im fünfstelligen Bereich kostet.
Aktuelle CPUs sind nochmals deutlich komplexer als dieser Baustein …
Da sich hier ja der Ein oder Adnere fragt, wie sowas jahrelang
unentdeckt bleiben konnte, hier mal ein Vortrag von der BlackHat 2015
https://youtu.be/lR0nh-TdpVgA. K. schrieb:> Und auf Ideen muss immer erst jemand kommen, die fallen nicht von allein> und sofort von den Bäumen.
Genau so sieht es aus.
Jörg W. schrieb:> Lars R. schrieb:>> "Virtualisierung" der CPU-Architektur mit FPGA.>> Also Stromfresser ohne Ende.
Strombedarf ergibt sich vor allem beim Schaltvorgang. FPGAs befinden
sich in Smartphones.
> Außerdem: wer soll das bezahlen?
Das ist eine Frage der Stückzahlen und der Märkte.
> Bei meinem vorigen Brötchengeber [...]
Dazu kann ich mangels Information (noch) keine Bewertung abgeben.
Die Transistor-Zahl von FPGAs und CPUs ist prinzipiell ähnlich. Eine CPU
mit 1Mrd Transistoren passt natürlich nicht in einen FPGA mit 4 Mrd
Transistoren. Nur: Brauchst Du denn die neue top-of-the-edge CPU oder
genügt auch eine von vor 6 Jahren? Brauchst Du ständig
Befehlssatzerweiterung a,b,c,d,e,...?
Dafür herrschst Du über jedes einzelne Bit. Tendenziell komplett
open-source.
Lars R. schrieb:> Dafür herrschst Du über jedes> einzelne Bit. Tendenziell komplett open-source.
Du herrscht über gar nichts, weil so hochgezüchtete FPGAs noch mehr
Fehler und Angriffsmöglichkeiten hätten die der Entwickler nie für
möglich gehalten hätte.
Und da du dann durch die programmierbare Struktur der Hardware noch eine
Ebene mehr an Komplexität hast kann es endgültig keiner mehr überblicken
und schon gar nicht mehr flächendeckend bei Fehlern patchen.
A. K. schrieb:> Joachim S. schrieb:>> - dieser Bug ist allerdings im Grunde nur eine besonders leicht>> ausnutzbarer Spezialfall einer viel grösseren Sicherheitslücke>> Es sind 3 völlig verschiedene Szenarien, die aber alle vom gleichen Fix> behoben werden. Wenn man die fehlende Kernel-Isolation nicht schon> selbst als Sicherheitslücke sieht.
Der von Dir zitierte Teil meines Postings war im Grunde nur eine
Übersetzung aus dem Wikipedia-Artikel: "The Meltdown vulnerability can
be thought of as a particularly easy and efficient-to-implement special
case of Spectre."
Somit ist Dein Kommentar vermutlich inhaltlich zutreffend, aber auch
kein Widerspruch zu der von Dir zitierten Aussage.
>> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem>> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast>> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen>> entdeckt wird?>> Weil einer eine noch nicht fertig durcherforschte Idee hat, diese im> Sommer 2017 öffentlich macht, und sich danach die Habichte darauf> stürzen. Beispielsweise> https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
Danke, das ist in der Tat ebenfalls eine plausible Erklärung.
Wobei mir gerade nicht ganz klar ist, ob der verlinkte Artikel jetzt die
"nicht fertig durcherforschte Idee" darstellen soll, oder ein Beispiel
für einen "Habicht". :)
Der Andere schrieb:> und schon gar nicht mehr flächendeckend bei Fehlern patchen.
Immerhin könnte man Fehler wie hier patchen.
Hinsichtlich Stromeffizienz wird das nichts mit Softcores in FPGAs. Ich
denke nicht, dass deren Stromverbrauch auch nur annähernd die gleiche
Rechenleistung pro Watt abliefern kann, wenn man nicht nebenbei auch
anwendungsspezifische Befehle implementiert.
Man braucht viel mehr Aufwand für das gleiche Ergebnis und kann die
einzelnen Schaltelemente nicht auf die jeweils nötigen Parameter zu
Tempo und Leistung tunen. Auch die selektive Trennung ganzer
Funktionsbereiche vom Strom dürfte interessant werden.
Der Andere schrieb:> Lars R. schrieb:>> Dafür herrschst Du über jedes>> einzelne Bit. Tendenziell komplett open-source.>> Du herrscht über gar nichts, weil so hochgezüchtete FPGAs noch mehr> Fehler und Angriffsmöglichkeiten hätten die der Entwickler nie für> möglich gehalten hätte.
Eben nicht. Du verwechselt hier Angriffe auf FPGAs mit Angriffen auf
CPUs.
Bei Angriffen auf FPGAs versucht man insbesondere, an das Design heran
zu kommen.
Bei Angriffen auf CPUs versucht man, Bits zu kippen. Man weiß, dass
Millionen von Bausteinen das selbe machen, wenn Bit xy gekippt wird.
Das ist aber beim FPGA überhaupt nicht der Fall. Da müsstest Du schon
exakt zu 100% das selbe Design laden. Dazu gibt es natürlich keinen
Anlass. Auch bei gleicher Funktionalität kann man hinreichend
randomisieren, welches physikalische Bit des FPGAs welches Bit der CPU
Architektur repräsentiert.
> Und da du dann durch die programmierbare Struktur der Hardware noch eine> Ebene mehr an Komplexität hast kann es endgültig keiner mehr überblicken> und schon gar nicht mehr flächendeckend bei Fehlern patchen.
Der FPGA wird funktional unabhängig getestet. Natürlich, Du kannst
heutzutage ein Python-Script ausführen und es stürzt Dir wegen
CPU-Hardware-Bugs in Milliarden von Transistoren ab. Trotzdem
beherrschbar, nicht wahr?
A. K. schrieb:> Hinsichtlich Stromeffizienz wird das nichts mit Softcores in FPGAs. Ich> denke nicht, dass deren Stromverbrauch auch nur annähernd die gleiche> Rechenleistung pro Watt abliefern kann, wenn man nicht nebenbei auch> anwendungsspezifische Befehle implementiert.
Man macht einen ganzen CPU-Kern anwendungsspezifisch, bzw
Task-spezifisch.
Lars R. schrieb:> Man macht einen ganzen CPU-Kern anwendungsspezifisch, bzw> Task-spezifisch.
Wer ist "man" und weshalb macht "man" das perfekter als normale
Allerwelts-Programmierer? Deren Grad an Perfektion ist wohl hinlänglich
bekannt.
Wie wird darin verhindert, dass Anwendungslösungen (früher Programme
genannt) direkten Durchgriff auf alle Hardware-Ressourcen bekommen? Die
ja direkt dranhängen.
Wie wird erreicht, dass ein Gerät mehr als eine Aufgabe mehr oder
weniger gleichzeitig erledigt, wenn jede davon das gesamte FPGA
benötigt? Zeitmultiplex, d.h. alle Naselang bekommt das FPGA ein
komplett neues Programm rauf, zyklisch wechselnd? Oder geht nicht, muss
alles zusammen drauf passen?
Irgendwie erinnert mich das an DOS. Ohne Filesystem.
Also ich setz mir noch mal meinen AlCuHut, bessere Ableitung durch
Skineffekt, auf.
Für mich lautetet die Botschaft des konzertierten öffentlichen
SW-Patches folgendes:
1. Was dort Im Sommer endgültig öffentlich wurde wissen wir schon lange.
2. Wir wollten es aus verschiedenen Gründen nicht diskutieren. (mögliche
grüne selbst finden)
3. Jetzt nach dem es Anderen bekannt ist können wir es nicht länger
ignorieren.
4. Da wir es versäumten das Problem rechtzeitig ernst zu nehmen sind wir
nicht in der Lage ein sehr aufwendiges HW basiertes Äquivalent zu
bieten.
5. Deshalb liebe Softworker holt bitte schnell die Kohlen aus dem Feuer,
sonst haben wir die Scheiße am Schuh.
6. Wir wissen was zu tun ist. Hier unseren bisher Top Secret SW
Workarrounds
pflegt das mal schnell ein.
7. und an die ungewollt Informierten wir schlagen euch mal kurz die Tür
vor der Nase zu. Habt bitte Verständnis, dass wir wissen, dass Ihr wisst
was wir wussten. Leider ist es für uns nun nicht nur nutzlos, sondern zu
riskant.
Namaste
A. K. schrieb:> Lars R. schrieb:>> Man macht einen ganzen CPU-Kern anwendungsspezifisch, bzw>> Task-spezifisch.>> Wer ist "man" und weshalb macht "man" das perfekter als normale> Allerwelts-Programmierer? Deren Grad an Perfektion ist wohl hinlänglich> bekannt.
Kommt alles von der Stange. Oder schreibst Du heute jede Software-Lib
selbst und mit ASM.
> Wie wird darin verhindert, dass Anwendungslösungen (früher Programme> genannt) direkten Durchgriff auf alle Hardware-Ressourcen bekommen? Die> ja direkt dranhängen.
Wie man das halt in einem Netzwerk so macht. ;)
> Wie wird erreicht, dass ein Gerät mehr als eine Aufgabe gleichzeitig> erledigt, wenn jede davon das gesamte FPGA benötigt?
So, wie das heute jeder Server auch macht.
Das sind keine "fest verdrahteten" Komponenten. Das können dutzende CPUs
sein. Jedoch, die Festplatten hängen nur an einer ganz bestimmten CPU.
Selbiges für Sound, usw.
Du hast mehrere 64-Bit-CPUs in einem FPGA. Ja wenn's nicht reicht, dann
reicht's eben nicht. Dann muss eben Taskwechsel gemacht werden. Macht
man doch heute auch, wo ist das Problem?
Lars R. schrieb:> Das sind keine "fest verdrahteten" Komponenten. Das können dutzende CPUs> sein. Jedoch, die Festplatten hängen nur an einer ganz bestimmten CPU.> Selbiges für Sound, usw.
Also ein FPGA fürs Festplatteninterface, eines für den generischen
SCSI-Layer, eines für den Festplattencache des Systems, eines für das
Filesystem, eines für den Filesystem-Dispatcher, ... und all das nur, um
an Files ran zu kommen.
Und das war noch der einfache Fall. Ich will lieber nicht wissen,
welchen Zoo du für USB kriegst. ;-)
Joachim S. schrieb:> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?> Die einzige Erklärung, die mir auf Anhieb einfällt, ist, dass zu der> Zeit mglw. bereits eine Schadsoftware im Umlauf war, die diese> Sicherheitslücke ausgenutzt hat, und die dann fast gleichzeitig von> mehreren Sicherheits-Teams untersucht wurde. Oder wie lässt sich das> sonst erklären?
Ganz einfach:
1
Für Meltdown haben die Forscher der TU Graz bereits einen Patch, also
2
eine wirksame Gegenmaßnahme, entwickelt. Der so genannte KAISER-Patch
3
wurde bereits vor einiger Zeit gegen eine andere Art von Cyberangriff
4
entwickelt.
5
6
Zu dem Zeitpunkt war noch nicht klar, dass sämtliche Prozessoren von
7
AMD, ARM und Intel von einer Lücke betroffen sind, die mit einem
8
solchen Patch zu schließen ist.
9
10
Anfang Dezember 2017 merkten die Forscher, dass dieser KAISER-Patch
11
im Kernel von Linux-Betriebssystemen auftauchte. "Wir haben uns gedacht
12
'Da muss etwas Größeres dahinter sein' und haben das untersucht", meint
13
Gruss. Sein Team nahm mit Intel Kontakt auf und erfuhr, dass auch andere
14
IT-Sicherheitsexperten bereits aufmerksam geworden waren.
Lars R. schrieb:> Wie ich oben schon schrieb: "Virtualisierung" der CPU-Architektur mit> FPGA. Natürlich haben kommerzielle IC-Entwickler und IC-Verkaufer kein> Interesse daran, sich selbst obsolet zu machen.
Was soll das bringen? Möglicherweise schnellere Patches. Ansonsten liegt
das Problem, falls ich die Angriffe richtig verstanden habe, schlicht an
der (fehlerhaften) spekulativen Ausführung von Befehlen (Spectre) bzw.
dem Ausführen von Befehlen Out-of-order (Meltdown) -> das machen alle
heutigen Hochleistungs-CPUs: RISC-V
https://github.com/ucb-bar/riscv-boom ebenso wie Power(PC) oder SPARC.
Für Power ist die Lücke ebenfalls bestätigt worden:
https://access.redhat.com/security/vulnerabilities/speculativeexecution
(System Z, Power8 und Power9)
A. K. schrieb:> Lars R. schrieb:>> Das sind keine "fest verdrahteten" Komponenten. Das können dutzende CPUs>> sein. Jedoch, die Festplatten hängen nur an einer ganz bestimmten CPU.>> Selbiges für Sound, usw.>> Also ein FPGA fürs Festplatteninterface, eines für den generischen> SCSI-Layer, eines für den Festplattencache des Systems, eines für das> Filesystem, eines für den Filesystem-Dispatcher, ... und all das nur, um> an Files ran zu kommen.>
Nein. Eine von mehreren CPUs imFPGA nur für Festplatten. Im FPGA gibt
es zB. Ethernet. Diese CPU dient als FileServer und wird logisch auch
genauso angesprochen. Nur, dass sich der Fileserver auf dem selben Chip
befindet.
Das spart schon mal einige Kontext-Switches und branches.
> Und das war noch der einfache Fall. Ich will lieber nicht wissen,> welchen Zoo du für USB kriegst. ;-)
Intel nimmt nun sogar die dedizierte Graphik von AMD mit auf das
Package, weil sie mit dem Silizium nichts besseres mehr anzufangen
wissen. Findest Du das auch amüsant?
> Was soll das bringen?
Es ermöglichst, dass sich Architekturen wieder in eine andere Richtung
(zB. multicore Mikrokernel) entwickeln. Ein Problem aktueller
Architekturen ist, dass sie alles können müssen und dabei schnell sein
müssen. Entsprechend komplex sind Kernel mitsamt Scheduling und
Architektur.
Ein erster Ansatz sind CPUs für Smartphones mit verschiedenen Cores.
Lars R. schrieb:> Nein. Eine von mehreren CPUs imFPGA nur für Festplatten. Im FPGA gibt> es zB. Ethernet. Diese CPU dient als FileServer und wird logisch auch> genauso angesprochen. Nur, dass sich der Fileserver auf dem selben Chip> befindet.
Also eine ganz gewöhnliches NAS mit ganz gewöhnlichen CPUs mit einem
eigenen Betriebssystem, nur als Softcore, damit die zig beteiligten
Module verschiedener Entwickler miteinander kooperieren? Was
unterscheidet dabei die FPGA-Lösung von einer Prozessorlösung?
> Intel nimmt nun sogar die dedizierte Graphik von AMD mit auf das> Package, weil sie mit dem Silizium nichts besseres mehr anzufangen> wissen.
Intel hatte schon bisher Grafik auf den meisten Desktop-Prozessoren
drauf, aber AMD hat die bessere. Was hat das mit FPGA zu tun?
A. K. schrieb:> Lars R. schrieb:>> Nein. Eine von mehreren CPUs imFPGA nur für Festplatten. Im FPGA gibt>> es zB. Ethernet. Diese CPU dient als FileServer und wird logisch auch>> genauso angesprochen. Nur, dass sich der Fileserver auf dem selben Chip>> befindet.>> Also eine ganz gewöhnliches NAS mit einer ganz gewöhnliches CPU drauf,> damit die zig beteiligten Module miteinander kooperieren? Was> unterscheidet dabei die FPGA-Lösung von einer Prozessorlösung?
Variante A: CPU mit verschiedenen Dateisystemen und Festplatten
Variante B: CPU ohne Festplatte. Alles über einen Fileserver.
Variante C: wie B, aber der Fileserver ist auf dem selben IC.
Für die Grafik machst Du das ähnlich, bzw gibt es schon.
Für die Verarbeitung von Druckaufträgen spendieren wir auch eine eigene
per "Ethernet" angebundene CPU, usw.
>> Intel nimmt nun sogar die dedizierte Graphik von AMD mit auf das>> Package, weil sie mit dem Silizium nichts besseres mehr anzufangen>> wissen.>> Intel hatte schon bisher Grafik auf den meisten Desktop-Prozessoren> drauf, aber AMD hat die bessere. Was hat das mit FPGA zu tun?
Es zeigt, dass genügend Silizium für den vorgeschlagenen Ansatz da ist.
Ob jemand die Intel HD-Grafik nutzt oder nicht, spielt preislich
praktisch keine Rolle.
Lars R. schrieb:> Variante A: CPU mit verschiedenen Dateisystemen und Festplatten
Worin besteht der Unterschied zu einem ganz gewöhnlichen NAS? Bitte dran
denken, dass du bei bereits dieser Aufgabe zig Entwickler
verschiedenster Firmen quer über die Welt kombinieren musst. Wenn du
nicht das Rad neu erfinden willst.
> Es zeigt, dass genügend Silizium für den vorgeschlagenen Ansatz da ist.> Ob jemand die Intel HD-Grafik nutzt oder nicht, spielt preislich> praktisch keine Rolle.
Die Idee, klassische CPUs mit einem FPGA zu verheiraten, wird immer
wieder mal ventiliert. Bislang allerdings nachhaltig erfolglos, auf
Stückzahlen bezogen. Grund: die Programmierung. Softcores sind in diesem
Zusammenhang nur für Kleinkram sinnvoll und spezifisch programmierte
Hardware ist schwer zu entwickeln.
Kaj G. schrieb:> Warum ist bei POWER9 nur Little Endian, bei POWER8 aber Big Endian und> Little Endian betroffen?
Das wird sich auf Redhats Linux-Distro beziehen. Vielleicht gibts die
nur so.
Lars R. schrieb:> Ein erster Ansatz sind CPUs für Smartphones mit verschiedenen Cores.
Also sowas wie Intels PCU? Ein Microcontroller für
Strom/Leistungsverwaltung. Ist seit knapp einem Jahrzehnt auf den CPUs
mit drauf.
warum muss man nun auch auf Linux basiertem Kram Patches rausgeben?
heisst es nicht immer, dass sich ein Linux keine Schadsoftware einfängt?
Ein linuxbasiertes OS ist doch sicher :-)
A. K. schrieb:> Lars R. schrieb:>> Variante A: CPU mit verschiedenen Dateisystemen und Festplatten>> Worin besteht der Unterschied zu einem ganz gewöhnlichen NAS?
Der Unterschied zum NAS ist, dass bei meinem Vorschlag das NAS auf dem
selben Silizium/Die sitzt.
>> Es zeigt, dass genügend Silizium für den vorgeschlagenen Ansatz da ist.>> Ob jemand die Intel HD-Grafik nutzt oder nicht, spielt preislich>> praktisch keine Rolle.>> Die Idee, klassische CPUs mit einem FPGA zu verheiraten, wird immer> wieder mal ventiliert. Bislang allerdings nachhaltig erfolglos, auf> Stückzahlen bezogen. Grund: die Programmierung.
Ja, aber mit unter an einer anderen Stelle als Du implizierst: Beim
letzten Ansatz war die Schnittstelle sowie die Konfiguration des
Hybriden viel zu kompliziert. Vielleicht ist/war dies auch der
Komplexität der CPU geschuldet.
Anders herum funktioniert es ganz gut: CPU ins FPGA. Da gibt es bereits
Linux mit GUI, usw.
● J-A V. schrieb:> warum muss man nun auch auf Linux basiertem Kram Patches rausgeben?> heisst es nicht immer, dass sich ein Linux keine Schadsoftware einfängt?
Ist dir langweilig? Willst du den Thread in ein Linux/Windows-Gefetze
abbiegen?
A. K. schrieb:> Lars R. schrieb:>> Ein erster Ansatz sind CPUs für Smartphones mit verschiedenen Cores.>> Also sowas wie Intels PCU? Ein Microcontroller für> Strom/Leistungsverwaltung. Ist seit knapp einem Jahrzehnt auf den CPUs> mit drauf.
Bei den Smartphones, auf die ich mich bezog, sind das eigenständige
Cores.
● J-A V. schrieb:> Ein linuxbasiertes OS ist doch sicher :-)
Lass doch deine <zensiert> Polemik bitte da, wo sie hin gehört: im
Mülleimer.
Es geht hier um Würgarounds für einen Hardwarebug, deren Implementierung
einfach (zwangsweise) auf die Performance schlägt, und die man daher
nicht freiwillig vorgenommen hätte, wenn einen die Hardware nicht dazu
verdammt.
So viel solltest du doch wohl aus dem bisherigen Thread mühelos
entnehmen können, oder?
Lars R. schrieb:> Anders herum funktioniert es ganz gut: CPU ins FPGA. Da gibt es bereits> Linux mit GUI, usw.
Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung
und Betriebszeit Akku und Wakü im Rucksack mitschleppst.
A. K. schrieb:> Lars R. schrieb:>> Anders herum funktioniert es ganz gut: CPU ins FPGA. Da gibt es bereits>> Linux mit GUI, usw.>> Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung> und Betriebszeit Akku und Wakü im Rucksack mitschleppst.
Welches?
Lars R. schrieb:>> Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung>> und Betriebszeit Akku und Wakü im Rucksack mitschleppst.>> Welches?
Korrektur: Das ergibt ein Handy, bei dem ...
A. K. schrieb:> Lars R. schrieb:>> Bei den Smartphones, auf die ich mich bezog, sind das eigenständige>> Cores.>> Bei Intel auch. Die PCU ist ein eigenständiger Core.
Auf der ich meine Software ausführe?
A. K. schrieb:> Lars R. schrieb:>>> Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung>>> und Betriebszeit Akku und Wakü im Rucksack mitschleppst.>>>> Welches?>> Korrektur: Das ergibt ein Handy, bei dem ...
Korrektur von Korrektur: "Das hatten wir schon" streichen?
Kaj G. schrieb:> Please talk to management. Because I really see exactly two> possibibilities:>> - Intel never intends to fix anything>> OR>> - these workarounds should have a way to disable them.>> Which of the two is it?>> Linus
both
Namaste
Lars R. schrieb:> Auf der ich meine Software ausführe?
Herzlichen Dank, aber an die Verwaltung von Strom, Takt und Wärme lasse
ich lieber ausschliesslich Intel ran.
A. K. schrieb:> Lars R. schrieb:>> Auf der ich meine Software ausführe?>> Herzlichen Dank, aber an die Verwaltung von Strom, Takt und Wärme lasse> ich lieber ausschliesslich Intel ran.
Mein Gott. Du hast doch davon angefangen und gemeint, mit der PCU gäbe
es so etwas wie meinen Vorschlag oder wie bei den Smartphones bereits.
Auf den Smartphones ist das nicht anders. Auch da ziehe ich es vor, den
Baseband-Prozessor nicht von den App-Programmierern füttern zu lassen.
Rest ähnlich.
A. K. schrieb:> Auf den Smartphones ist das nicht anders. Auch da ziehe ich es vor, den> Baseband-Prozessor nicht von den App-Programmierern füttern zu lassen.> Rest ähnlich.
Ja. Aber: es gibt dort CPUs mit verschiedenen Cores.
Lars R. schrieb:> Ja. Aber: es gibt dort CPUs mit verschiedenen Cores.
An welche dachtest du? Alle, die ich kenne, haben eine homogene Gruppe
generischer Cores, eine GPU, und ein paar spezialisierte Cores anderer
Bauart als die generischen Cores.
Hey
Windows besser als Linux.....
====================
Weil das Problem auf Prozessorebene liegt, betrifft es auch alle
gängigen Betriebssysteme. Laut Daniel Gruss ist es den Grazer Forschern
gelungen, unter Linux und macOS alles auszulesen, was im Arbeitsspeicher
der Rechner abgelegt war, unter Windows "das meiste".
====================
Die IT-Forscher, die das Problem nun bekannt machten, haben
Spectre-Angriffe auf Prozessoren von Intel, AMD sowie auf sogenannten
ARM-Prozessoren durchführen können. ARM-Prozessoren stecken in fast
allen Smartphones und Tablets.
http://www.spiegel.de/netzwelt/gadgets/spectre-und-meltdown-die-wichtigsten-antworten-zu-den-schwachstellen-in-prozessoren-a-1186193.html#ref=rss
Obiges Info nur fuer Windoofler(wie mich)- Profis bitte nur Heise
lesen.....
:-)
Lars R. schrieb:> Etwas runter scrollen.
Ach das meinst du. ARMs bigLITTLE. Ein paar Cores mit viel Leistung viel
Watt und ein paar mit wenig Leistung wenig Watt. Softwarseitig
identisch. Kann man machen um Strom zu sparen. Intels Handy/Table-SoCs
schafften das auch ohne.
Aber was hat das mit dem Thema hier zu tun?
A. K. schrieb:> Ach das meinst du.
Was sonst.
> Aber was hat das mit dem Thema hier zu tun?
Mit der Sicherheitslücke direkt gar nichts. Mit meinem Vorschlag
insofern, als dort eben auch verschiedene, jedoch prinzipiell
generische, Kerne zusammen betrieben werden und auf jedem Core bevorzugt
diejenigen Tasks laufen, für die dieser Core geeignet ist.
Ggf. ist beispielsweise auch die Sprungvorhersage unterschiedlich
implementiert. Dh, hinsichtlich meines Vorschlages ist das ein erster
Ansatz. Dies hatte ich mit einer Zeile erwähnt.
Winfried J. schrieb:> Kann es sein dass der high sierra bug auch schon darin seine Ursache> hatte? Zeitlich käme das hin.> Namaste
ts ts
> Apple-Rechner haben den notwendigen Schutz bereits mit Mac OS 10.13.2> erhalten, Chrome-OS-Systeme mit der Version 63, die Mitte Dezember an alle>ausgeliefert wurde. - derstandard.at/2000071445192/Kritische>Prozessorluecken-gefaehrden-fast-alle-Computer-und-Smartphones
Genau das War das Patch das den High Sierra Bug behoben hat.
Inzwischen ist auch klar, dass es den Cache betrifft aber eventuell eher
den L3 als den von mir vermuteten L2, den ja jeder CORE exklusive
besitzt aber ganz klar ist mir das noch nicht.
Ich sehe mehr Bestätigung als Widerlegung meiner "ALCUHut"Gedanken
sorry
Namaste
Lars R. schrieb:> auf jedem Core bevorzugt> diejenigen Tasks laufen, für die dieser Core geeignet ist.
Das wird vom Betriebssystem bedarfsgemäss entschieden, nach momentanem
Leistungsbedarf, ob interaktiv oder Hintergrund etc. Und kann sich
mittendrin ändern, d.h. ein Thread setzt die Arbeit plötzlich auf einem
anderen Core fort.
Winfried J. schrieb:> Genau das War das Patch das den High Sierra Bug behoben hat.
Meinst du damit den, dass man sich einfach als Root anmelden konnte?
Wenn, dann war das purer Zufall, dass beide mit dem gleichen Patch
behoben worden sind.
A. K. schrieb:> Lars R. schrieb:>> auf jedem Core bevorzugt>> diejenigen Tasks laufen, für die dieser Core geeignet ist.>> Das wird vom Betriebssystem bedarfsgemäss entschieden, nach momentanem> Leistungsbedarf, ob interaktiv oder Hintergrund etc. Und kann sich> mittendrin ändern, d.h. ein Thread setzt die Arbeit plötzlich auf einem> anderen Core fort.
Einverstanden. Man kann es auch so sehen, dass es mit meinem Vorschlag
nichts zu tun hat.
Javascript schrieb:> Weil das einige hier unterschätzen:> Die Lücke lässt sich angeblich über Javascript ausnutzen.>> Anbei ein Beispiel, wieviele Scripte SPON nachlädt. Das kann kein Mensch> mehr kontrollieren,
doch! nosript+adblock rein und wenn die Seite jammert man möge dies
ausstellen dann gibt es diesen hier .I.. und die Seite wird geschlossen
wenn mir das Angebot nicht gefällt dann muss ich es nicht konsumieren
so ne Zeitung aus Papier schnüffelt mich schliesslich auch nicht aus
während ich sie lese
Für W10 wird schon ein Patch angeboten. Ich erwarte allerdings für alle
noch im Einsatz befindlichen Betriebssysteme einen solchen. XP und Vista
dürfen da nicht außen vor bleiben ebenso nicht alte Smartphones.
Toxic schrieb:> ARM-Prozessoren stecken in fast allen Smartphones und Tablets.
Der Januar-Patch repariert das. Für jene, die ihn kriegen. Wer den nicht
mehr kriegt und trotzdem Sicherheit will, der darf ein neues Handy
kaufen.
Insofern reiht sich dieser Bug in die Liste der diversen Probleme ein,
die es bisher schon gab. Da waren diverse Bugs in der Multimedia-Engine,
der WLAN-Bug vor ein paar Monaten, ... Da steht man jedes Mal vor dem
Problem, ob alte Geräte noch einen Update kriegen.
Das wurde ganz bestimmt nur deshalb von der NSA gemacht, damit Huawei
wieder neue Handys verkauft. ;-)
https://youtu.be/bReA1dvGJ6YJörg W. schrieb:> Meinst du damit den, dass man sich einfach als Root anmelden konnte?
Ja ich hatte gerade High Sierra auf meinen Vorgängermodell des aktuellen
MC-BookPro installiert und musste noch mein Office patchen weil es nicht
mehr lief, 2 Tage später dann diese Meldung und dann der o.g. Patch
Namaste
herbert schrieb:> XP und Vista dürfen da nicht außen vor bleiben ebenso nicht alte> Smartphones.
MS-DOS auch? :-)
Träum mal weiter … der Würgaround ist so gravierend, dass du da
für nicht mehr supportete Systemversionen vergeblich warten darfst.
Dass sie Wannacry auf Windows XP noch repariert haben, lag doch nur
daran, dass es vergleichsweise einfach zu reparieren war.
Winfried J. schrieb:>> Meinst du damit den, dass man sich einfach als Root anmelden konnte?>> Ja
Naja, das mit dem Root-Nutzer war aber eine völlig andere Klasse von
Bug. Root hatte auf diesem System ja wohl tatsächlich kein (gesetztes)
Passwort, nur dass man es hätte als Benutzer gar nicht zulassen sollen.
Das ist ein (relativ einfacher) Programmierfehler, der keinen Workaround
für Hardwarebugs braucht.
A. K. schrieb:> Wer den nicht mehr kriegt und trotzdem Sicherheit will, der darf ein> neues Handy kaufen.
Das dürfte der Preis sein, denn man für billige Handys zahlt.
Großartige Softwarewartung ist da wohl nicht drin. (Leider.)
Jörg W. schrieb:> Naja, das mit dem Root-Nutzer war aber eine völlig andere Klasse von> Bug. Root hatte auf diesem System ja wohl tatsächlich kein (gesetztes)> Passwort, nur dass man es hätte als Benutzer gar nicht zulassen sollen.
Der Unterschied ist klar aber High Sierra kam relativ kurz nach Sierra
auf den Markt. Ich tippe mal das der "Root" bug eher der überhasteten
Auslieferung von High Sierra geschuldet war. High Sierra aber leise die
eigentliche Lücke schließen sollte, wobei man die Tür versehentlich ganz
offen stehen ließ. Im Stress geht sowas gern unter.
Namaste
Hallo,
Jörg W. schrieb:> Das dürfte der Preis sein, denn man für billige Handys zahlt.> Großartige Softwarewartung ist da wohl nicht drin. (Leider.)
Und was ist mit teuren, "alten", noch voll funktionsfähigen Handys?
rhf
Roland F. schrieb:> Und was ist mit teuren, "alten", noch voll funktionsfähigen Handys?
Musst du deren Hersteller fragen.
Von einem, welches 500 Euro kostet, würde ich zumindest einen besseren
Support erwarten als eins, was für einen Hunderter verscherbelt wird.
Allerdings wäre ich für erstere auch zu geizig. :)
Jörg W. schrieb:> A. K. schrieb:>> Wer den nicht mehr kriegt und trotzdem Sicherheit will, der darf ein>> neues Handy kaufen.>> Das dürfte der Preis sein, denn man für billige Handys zahlt.> Großartige Softwarewartung ist da wohl nicht drin. (Leider.)
Bei Linux und Windows geht's doch auch mit unterschiedlichsten
Konfigurationen vom Server bis zum Phone mit Updates... nur der G-Kram
hat ein Problem. Bei älteren und aktuellen Geräten sieht's zumindest mit
Qualcomm SoCs besser aus (Lineage), MediaTek bzw. deren Abnehmern müsste
mal mit etwas GPL-Enforcement auf die Sprünge geholfen werden. Bin mal
gespannt wie das bei Intels chinesischem Partner Spreadtrum aussieht,
der SoCs mit Intel-Kernen für Smartphones baut aktuell im Leagoo T5C
http://www.spreadtrum.com/en/SC9853I.html
Jörg W. schrieb:> Das dürfte der Preis sein, denn man für billige Handys zahlt.
Es ist ironischerweise geradewegs andersrum. In Handys der Unterklasse
und auch in vielen der Mittelklasse stecken meistens 4-8 Cortex A53
Cores drin, in älteren Unterklasse-Geräten auch Cortex A7.
Und diese Cores arbeiten nicht spekulativ, sind folglich von der
ganzen Geschichte überhaupt nicht betroffen! Daher auch nicht die
RasPis.
Gekniffen sind derzeit nur die schnelleren Geräte mit Cortex A57
aufwärts, wahrscheinlich auch jene mit Krait Cores und aus diesen ARM
Cores abgeleiteten eigenen Qualcomm Cores.
https://developer.arm.com/support/security-update
Wobei andererseits viele der doch betroffenen ARM Prozessoren auch für
Variante 3 empfänglich sind, das ist die mit Intels Hardware-Bug.
herbert schrieb:> Für W10 wird schon ein Patch angeboten. Ich erwarte allerdings für> alle> noch im Einsatz befindlichen Betriebssysteme einen solchen. XP und Vista> dürfen da nicht außen vor bleiben ebenso nicht alte Smartphones.
jaja, die jährliche Publikumsumfrage beim "security nightmares"-vortrag
am CCC-Congress lässt grüßen:
"wer von euch hat wieder ein XP wegmachen dürfen?" :)
im Ernst, wenn du einen alten Käfer fährst und nach einem Unfall dank
nicht vorhandener Nackenstütze einen Querschnitt hast, dann bist auch du
schuld da das Ding einfach nicht mehr "supported" wird.
XP hat so in etwa den selben Status.
Bei DOS ist patchen dagegen unnötig... kann ja ohnehin jeder auf alles
zugreifen wenn er möchte :)
73
Hans schrieb:> im Ernst, wenn du einen alten Käfer fährst und nach einem Unfall dank> nicht vorhandener Nackenstütze einen Querschnitt hast, dann bist auch du> schuld da das Ding einfach nicht mehr "supported" wird.
Mal im Ernst ... ich wäre froh wenn ich so einen alten Käfer hätte.
Hans schrieb:> XP hat so in etwa den selben Status.
Geh weida... wenn man diesen gefährlichen Fehler als "Teil" betrachtet
dann hat es beseitigt zu werden egal wo es verbaut worden ist. Gäbe es
die Betrugs-Software der Autohersteller schon fünfzehn Jahre , dann hat
auch ein Halter mit einem betagten Auto das recht,dass wie bei einem
Neuwagen nachgebessert wird.
Winfried J. schrieb:> Viel Spass beim autonomen Fahren via Cloud.
Ach was! Das wird dann, wie heute auch schon im Reisebüro zu buchen,
eine "Fahrt in's Blaue". Nur eben ohne Fahrer.
MfG Paul
OS schrieb:> Da hat Intel aber Glück gehabt, dass Sie mit SoC für Smartphones nie in> den Markt gekommen sind.
Wobei die Atom Prozessoren mit Bonell Mikroarchitektur, also alle Atoms
vor Silvermont, vom aktuellen Problem überhaupt nicht betroffen sein
dürften, weil nicht spekulativ arbeitend. Erst mit Silvermont 2013 hielt
auch in dieser Prozessorschiene spekulative Ausführung Einzug.
Joachim D. schrieb:> Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.> Da ist *nix*
Seit Jahren gehen die Verkaufszahlen zurück. Neue
Hochleistungsprozessoren werden wenig gekauft, weil die Leistung heute
nicht mehr so eine große Rolle spielt.
Kommt es da nicht gelegen, wenn man sagt, dass das Sicherheitsproblem
nur richtig zu beseitigen ist, wenn man einen neuen Prozessor nimmt?
F. F. schrieb:> Kommt es da nicht gelegen, wenn man sagt, dass das Sicherheitsproblem> nur richtig zu beseitigen ist, wenn man einen neuen Prozessor nimmt?
Wäre es bei dieser Strategie nicht sinnvoller, den Leuten dann aber auch
einen neuen Prozessor anbieten zu können? Also einen, der das
Sicherheitsproblem nicht hat. Denn "kauft sofort einen neuen Prozessor,
aber keinesfalls von uns" bringts irgendwie nicht, oder? ;-)
Es dürfte, vorsichtig ausgedrückt, nicht einfach sein, den aktuellen
Desktop/Server-Prozessoren von Intel und AMD die Spekulation
abzugewöhnen. Da wird eher eine Variante in der Implementierung vom
Paging kommen, die das Problem auch ohne teurem TLB-Flush löst.
herbert schrieb:> Geh weida... wenn man diesen gefährlichen Fehler als "Teil" betrachtet> dann hat es beseitigt zu werden egal wo es verbaut worden ist. Gäbe es> die Betrugs-Software der Autohersteller schon fünfzehn Jahre , dann hat> auch ein Halter mit einem betagten Auto das recht,dass wie bei einem> Neuwagen nachgebessert wird
Du siehst das falsch, per se hat xp (in diesem Fall) keinen Fehler!
Das ist ein workaround um einen Bug in der cpu!!
Ähnlich der Nackenstütze beim Käfer... das ist ein workaround für die
nicht unfehlbaren Menschen.
Wenn überhaupt müsste man Microcode Updates für die CPUs fordern falls
möglich.
73
Hans schrieb:> Das ist ein workaround um einen Bug in der cpu!!
Nur eine der 3 Varianten geht direkt auf einen Bug zurück, nämlich die
Variante 3, von der AMD wohl tatsächlich nicht betroffen ist. Die
anderen Varianten gehen IMHO eher auf zwei prinzipielle Schwachstellen
zurück. Die nicht so sehr Bugs sind, als vielmehr Konzeptprobleme:
-1- Kerneladressen im Userspace gemappt
-2- spekulative Ausführung von Befehlen
die jeweils deutlich die Performance steigern, aber zusammengenommen zu
den aktuellen side channel attacks einladen. Prozessorübergreifend, also
ganz offensichtlich kein einfacher Implementierungsfehler.
Problem 1 wird gerade gelöst. Das ist daher kein Workaround, sondern
tatsächlich eine Lösung des Konzeptproblems. Es gibt Betriebssysteme,
die schon länger oder vielleicht schon immer mit Adressraumtrennung
arbeiten. So wäre ich nicht erstaunt, wenn IBMs POWER Prozessoren nur
mit Linux betroffen sind, nicht aber mit AIX. Die jetzige
Implementierung der Adressraumtrennung könnte freilich einen gewissen
Quick-and-Dirty Charakter haben, über den man vielleicht demnächst reden
wird.
Problem 2 liesse sich lösen, indem man komplexe OOO Prozessoren durch
einfachere und langsamere nicht-spekulative Prozessoren ersetzt. Also
beispielsweise die 4-8 Cores eines Core i7 durch sowas wie die ~60 Cores
eines Xeon Phi der ersten Generation. Die mit aktualisierten Pentium
P54C Cores, die zweite nutzt Silvermont Cores und ist auch gekniffen.
Allerdings wären viele Anwender damit nicht wirklich glücklich, denn die
weitaus meisten PC-Anwendungen würden dadurch drastisch langsamer.
Grund: siehe oben unter Amdahls Law.
Ich gehe daher davon aus, dass zukünftige Prozessoren sich nicht sehr
von den aktuellen unterscheiden werden. Aber Mechanismen enthalten
werden, die den Performance-Einbruch der Adressraumtrennung abmildern
oder eliminieren.
c.m. schrieb:> das verhalten der verbuggten CPU's ist nicht nur den intel entwicklern> bei verschiedenen CPU versionen 10 jahre lang nicht aufgefallen, sondern> auch den kernelentwicklern von windows, linux...
Man sollte es nicht "verbuggt" nennen, wenn ein Stück Technik in dem
Bestreben aufgebaut wird, die technisch höchstmögliche Performance zu
erreichen. Ohne die Sparte der spekulativen Berechnungen wären die
heutigen PC's eben ein ganzes Stück langsamer. Willst du das als Preis
wirklich akzeptieren?
Kaj G. schrieb:> Ich lehne mich mal etwas aus dem Fenster und sage:> Die Kacke ist am dampfen... und zwar so richtig.
Ach nö. Sie hat bereits 10 Jahre des Dampfens hinter sich.
Lars R. schrieb:> Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten> der Sicherheit. Ganz klassisch.
Eben - mal ganz ohne Ironie. Alle möglichen Autostart-Funktionalitäten
(gerade bei Windows) sind Features, die gedacht sind für die
Bequemlichkeit der Benutzer - insbesondere derjenigen Benutzer, die eben
keine Vorstellung von Begriffen wie "Datei", "Verzeichnis" und
dergleichen haben. Das ist übrigens die allergrößte Benutzergruppe - und
man sollte sie nicht schmähen, denn diese Leute haben schlichtweg ein
anderes Feld ihrer Kenntnisse. Wer von euch Programmierern kennt sich
denn z.B. in den Details internationalen Seerechts aus? oder in den
Details von Geologie und Bergbau oder den Details, die ein Zahnarzt
wissen muß? He?
Jörg W. schrieb:> Es geht hier um Würgarounds für einen Hardwarebug, deren Implementierung> einfach (zwangsweise) auf die Performance schlägt, und die man daher> nicht freiwillig vorgenommen hätte, wenn einen die Hardware nicht dazu> verdammt.
Nenne es nicht so. Nenne es lieber ein Schließen von Einfallslöchern,
die Spitzbuben für Übeltaten benutzen könnten.
Toxic schrieb:> Laut Daniel Gruss ist es den Grazer Forschern> gelungen, unter Linux und macOS alles auszulesen, was im Arbeitsspeicher> der Rechner abgelegt war,
Ja. Bei so rund 8 Gigabyte pro gehacktem PC hat man ne Menge zu tun, um
das alles auszuwerten oder über's Netz zur NSA zu schaufeln, damit die
dann die 8 GB durchsuchen können. Technisch einfacher wäre es, die
pagefile.sys oder hiberfile.sys zur NSA zu senden.
Ach Leute,
bleibt doch mal ein bissel auf dem Teppich. Das, was ihr alle jetzt
durchhechelt, ist kein BUG - in dem Sinne, daß darunter normale brave
anständige Programme zu leiden hätten.
Es ist lediglich eine Einfallstür für Leute, die ein ERHEBLICHES
Spitzbuben-Potential besitzen. Ob das in den letzten 10 Jahren nun
staatlich angestellte Spitzbuben waren und ab jetzt eben auch mit
privaten Spitzbuben zu rechnen ist, sei mal dahingestellt.
Aber wie sieht diese Einfallstür aus? Man kann eventuell all das
auslesen, was in als "geschützt" angenommenen RAM-Bereichen des BS so
herumsteht. Toll. Bis also jemand eure noch gültigen Transaktionscodes
für euer E-Banking zusammengekratzt hat, dürfte es noch ein Weilchen
dauern.
Abgesehen davon sehe ich mich mal wieder ein bissel bestätigt, ich hatte
vor Jahren schon mal hier gepostet, daß man Sicherheit eben nur mit
sicheren Strukturen hinkriegt und nicht mit Paßwortabfragen, "Trusted"
Speicherbereichen und dergleichen. Das Stichwort dazu lautet schlicht
und einfach: Nur das ans Netz dran, was wirklich dran muß - und sonst
nix. Also der Arbeitsplatz-PC, wo eure wichtigen Entwicklungsdaten
stecken, gehört eben NICHT an's Netz. Von wegen "bei uns steckt alles in
der Cloud..".
Ich bin ja mal gespannt, was man auf der diesjährigen Embedded zum Thema
erleben darf. Von wegen IOT und so.
W.S.
FYI schrieb:> Hauptsache Mr. Intel wird auf 'links' gezogen. Sein Aktien Deal ist ja> die größte Frechheit als add on.
Das könnte davon abhängen, ob dieses Verhalten für ihn normal war. Wenn
er das Jahr für Jahr als Gehaltsanteil versilberte, das also kein
besonderes Verhalten war, dann wird man ihm wohl keinen Strick draus
drehen können. Und wenn er das Geld nachvollziehbar für ein schon eine
Weile geplantes privates Projekt braucht evtl. auch nicht.
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.
W.S. schrieb:> Es ist lediglich eine Einfallstür für Leute, die ein ERHEBLICHES> Spitzbuben-Potential besitzen.
Kann es sein dass du das aktuelle Risiko-Potential etwas zu gering
einschätzt?
Offensichtlich können die Lücken sogar mit JS genützt werden; und viel
schlimmer: Virtualisierung ist anfällig (und das in Zeiten von Azure und
AWS/EC2 und wie sie alle heissen). Heisst für mich: ich miete einen
Mini-Server für lau, und in Kürze hab ich Host und alle VMs
übernommen...
Unterhalte dich mal mit einem Security-Experten deines Vertrauens... mir
macht das Angst
W.S. schrieb:> Wer von euch Programmierern kennt sich denn z.B. in den Details> internationalen Seerechts aus?
Wahrscheinlich keiner. Allerdings wird auch keiner auf die Idee kommen,
eigenhändig ein Schiff über internationale Schifffahrtsstraßen zu
steuern.
> oder in den Details von Geologie und Bergbau oder den Details, die ein> Zahnarzt wissen muß? He?
Gleiches Thema: Da ich diese Details nicht kenne, werde ich eben einfach
keine Zähne aufbohren und füllen. Aber ausgerechnet bei sowas komplexem
wie einem Computer wird erwartet, dass er für jeden auch ohne
Vorkenntnisse so leicht zu bedienen ist wie ein Toaster.
Selbstverständlich soll man dabei aber trotzdem alles damit machen
können, und sicher soll es auch noch sein.
Rolf M. schrieb:> Allerdings wird auch keiner auf die Idee kommen, eigenhändig ein Schiff> über internationale Schifffahrtsstraßen zu steuern.
Hab' ich schon gemacht. ;-) Allerdings war ein Kapitän dabei, der die
Verantwortung trug und die nötigen Rechtskenntnisse hatte … Hat Spaß
gemacht, bspw. durch die Brücke über den Großen Belt zu fahren.
Gut, aber das nur, weil du es erwähntest. :)
Anders als W.S. sehe ich schon den Bug. Habe schon zu viele Huftiere
sich vor der Apotheke übergeben sehen, als dass man davor die Augen
verschließen sollte. Ganz plötzlich wissen die Spitzbuben dann halt
doch, wie man in kürzester Zeit eben tatsächlich interessante Nadeln
in diesem 8 GiB großen Heuhaufen finden kann … konnte doch keiner
ahnen, dass die wirklich so spitz(buben)findig sein würden, oder?
F. F. schrieb:> 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.
Gibts zu dem Thema tatsächlich Radio mit Fachkenntnis?
Alles ich derzeit von Intel zu lesen finde, läuft auf die PTI Patches
raus.
Michael R. schrieb:> AWS/EC2 und wie sie alle heissen). Heisst für mich: ich miete einen> Mini-Server für lau, und in Kürze hab ich Host und alle VMs> übernommen...
Die sind die erste Adresse für solche Spielchen und wissen das auch.
Deshalb tut sich da ja auch was.
A. K. schrieb:> Ich gehe daher davon aus, dass zukünftige Prozessoren sich nicht sehr> von den aktuellen unterscheiden werden. Aber Mechanismen enthalten> werden, die den Performance-Einbruch der Adressraumtrennung abmildern> oder eliminieren.
PS: Zumindest dürfte das Meltdown und dessen Abwehr entschärfen.
Bei Spectre bleibt es spannend.
Da scheint wohl doch was per Microcode zu gehen, zumindestens fuer
"Variant 2: branch target injection (CVE-2017-5715)"
Red Hat Security Advisory 2018-0013-01
https://packetstormsecurity.com/files/145650
1
Red Hat Security Advisory 2018-0013-01
2
3
The microcode_ctl packages provide microcode updates for Intel and AMD
4
processors.
5
Security Fix: An industry-wide issue was found in the way many modern
6
microprocessor designs have implemented speculative execution of
7
instructions. There are three primary variants of the issue which differ in
8
the way the speculative execution can be exploited. Variant CVE-2017-5715
9
triggers the speculative execution by utilizing branch target injection.
10
11
It relies on the presence of a precisely-defined instruction sequence in
12
the privileged code as well as the fact that memory accesses may cause
13
allocation into the microprocessor's data cache even for speculatively
14
executed instructions that never actually commit. As a result, an
15
unprivileged attacker could use this flaw to cross the syscall and
16
guest/host boundaries and read privileged memory by conducting targeted
A. K. schrieb:>> Virtualisierung ist anfällig> Aus dieser Ecke fand bisher allenfalls heisse Luft. Hast du mehr dazu?https://googleprojectzero.blogspot.co.at/2018/01/reading-privileged-memory-with-side.html
Ich lese das so:
Bounds Check bypass (Spectre) - works cross VM
Branch Target Injection (Spectre) - works cross VM
Rogue Data Cache Load (Meltdown) - does not work cross VM
Ich hab aber grad eine andere Idee: Beide Attacken nutzen als
side-channel ja das Timing (einmal cache hit/cache miss, einmal
branch/call predictor), und das jeweils mit dem guten alten TSC... macht
man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte
vielleicht per Microcode implementiert werden?
Hans schrieb:> Wenn überhaupt müsste man Microcode Updates für die CPUs fordern falls> möglich.
Formal betrachtet und aus Sicht der Anwälte "ja", denn dann spielt das
BS keinerlei Rolex weil der Patch dann auf den Betriebssystemen laufen
muß die der Prozessor unterstützt.
73
Toxic schrieb:> Meine Dell-Lappies sind nicht betroffen - woher die Info? Nun zumindest> nicht von heise.de sondern von Intel und einer von Dell gefuehrten> Auflistung.
wo bitte? hab auch Dell...
Kaj G. schrieb:> Da scheint wohl doch was per Microcode zu gehen, zumindestens fuer> "Variant 2: branch target injection (CVE-2017-5715)"
Ich frage mich allerdings, ob damit zwar die jetzige Version von Spectre
ausgehebelt wird, aber bald die nächste Methode ansteht, das
grundlegende Problem auszunutzen.
Michael R. schrieb:> macht> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte> vielleicht per Microcode implementiert werden?
Vorstellbar. Nebenwirkungen allerdings nicht ausgeschlossen. Nur
adressiert auch das nur die verwendete Methode, das Problem auszunutzen,
nicht aber das Problem.
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.
Da drängen sich Parallelen zum Dieselskandal auf. Einen Hardwarefix gibt
es nicht, nur Softwareupdates. Zur endgültigen Lösung des Problems muß
eine neue CPU her. Vielleicht zahlt Intel bald eine Abwrackprämie in
Form von Rabatten auf neue Prozessoren und kurbelt damit den Verkauf an.
Microsoft reibt sich auch schon die Hände, weil die neuen CPUs nur noch
unter W10 laufen. Wie immer zahlen die Endkunden die Zeche. Ist der Ruf
erst ruiniert, verdient es sich ganz ungeniert...
Michael R. schrieb:> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte> vielleicht per Microcode implementiert werden?
Wobei die Technik der Virtualisierung, die von VMware genutzt wurde, als
x86 eigentlich noch nicht virtualisierbar war, auch in der Lage sein
könnte, solche Verhaltensänderungen der ISA zu implementieren.
A. K. schrieb:> Michael R. schrieb:>> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte>> vielleicht per Microcode implementiert werden?>> Wobei die Technik der Virtualisierung, die von VMware genutzt wurde, als> x86 eigentlich noch nicht virtualisierbar war, auch in der Lage sein> könnte, solche Verhaltensänderungen der ISA zu implementieren.
Hängt vermutlich davon ab, ob sich RDTSCx trappen lässt... so wie damals
beim FDIV
Icke ®. schrieb:> Ist der Ruf erst ruiniert, verdient es sich ganz ungeniert...
Oder das triggert eine längerfristige Veränderung in der IT, in der
manche Platzhirsche am Ende dastehen wie Heizer in der E-Lok. Nämlich
dann, wenn sich aufgrund von über die Jahre wiederkehrenden Attacken auf
das Grundprinzip hochkomplexer spekulativer Prozessoren die bisherige
Nutzungsweise von IT-Geräten wesentlich verändert.
Michael R. schrieb:> Hängt vermutlich davon ab, ob sich RDTSCx trappen lässt...
Soweit ich mich erinnere scannt oder emuliert die besagte alte
Virtualisierungstechnik die Befehle, bevor sie das erste Mal per
Hardware ausgeführt werden, um jene rauszufischen und zu ersetzen, die
einer Virtualisierung im Weg standen. PUSHF war wohl so ein Kandidat.
Als VMware anfing war x86 in sich nicht vollständig virtualisierbar. Für
das Statusregister gab es im VM86 Mode für DOS ein virtuelles
Interrupt-Flag, nativ aber nicht. Ohne schmutzige Tricks ging das also
überhaupt nicht.
A. K. schrieb:> Michael R. schrieb:>> macht>> man TSC "ungenau" sollten die Angriffe ins Leere laufen. Sowas könnte>> vielleicht per Microcode implementiert werden?>> Vorstellbar. Nebenwirkungen allerdings nicht ausgeschlossen. Nur> adressiert auch das nur die verwendete Methode, das Problem auszunutzen,> nicht aber das Problem.
Hmmm... das kann man so oder so sehen. Auf die schnelle fällt mir jetzt
außer Timing kein "aus der Ferne nutzbares" sideband ein. Und wenn man
das sideband zumacht, wären auch zukünftige andere Attacken zumindest
erschwert.
A. K. schrieb:> Oder das triggert eine längerfristige Veränderung in der IT, in der> manche Platzhirsche am Ende dastehen wie Heizer in der E-Lok. Nämlich> dann, wenn sich aufgrund von über die Jahre wiederkehrenden Attacken auf> das Grundprinzip hochkomplexer spekulativer Prozessoren die bisherige> Nutzungsweise von IT-Geräten wesentlich verändert.
Ich glaube nicht an den Weihnachtsmann. Um noch eine Parallele zur
Automobilindustrie zu ziehen, hat sich das Nutzungsverhalten dort
geändert, weil die Karren aufgrund immer komplexerer Technik
störanfälliger werden und die Betriebskosten drastisch nach oben gehen,
weil Wartung und Reparaturen teilweise nur noch von Vertragswerkstätten
zu Apothekenpreisen ausgeführt werden können? Nein, die Leute kaufen
noch dickere Boliden mit noch mehr Schnickschnack zu noch höheren
Preisen.
Der gemeine IT-User hat doch kaum ein Wahl, das Nutzungsverhalten wird
von den Monopolisten diktiert. Siehe die Absprachen zwischen
CPU-Herstellern und MS bezüglich Betriebssystemunterstützung. Der
Vernetzung kann sich auch keiner mehr entziehen, die wird ihm teilweise
per Order Mufti aufgezwungen (z.B. elektronische Abgabe von Steuer- und
SV-Meldungen) oder ist aus wirtschaftlichen Gründen unvermeidbar, um
konkurrenzfähig zu bleiben. Privatusern ist es mittlerweile sowieso
scheißegal, was mit ihren Daten passiert. Die sind genauso gierig nach
hippem Schnickschnack und geben freiwillig Unsummen dafür aus.
Das Nutzungsverhalten wird sich erst ändern, wenn du eines Tages ohne
totale Vernetzung nicht mal mehr ein Brötchen kaufen kannst und dann der
große Crash kommt...
Icke ®. schrieb:> Ich glaube nicht an den Weihnachtsmann.
Ich hab ihn gesehen, ebenso Intel und Microsoft. Die sahen vor einigen
Jahren durch Mobilgeräte wie Tablets breits ihre Felle davonschwimmen
und reagierten. Kam dann doch nicht so wie befürchtet, aber...
Jungs macht euch locker. Alles was passiert ist lässt sich schnell in
wenigen Sätzen zusammenfassen:
Die Speicherbereiche bei Systemen mit INTEL-Architektur wurden endlich
liberalisiert! Vorbei ist es mit dem bisherigen Speicher-Nationalismus,
dieser auf strickte Grenzen setzenden altbackenen Abschottung. Man
erhofft sich mit dieser Öffnung die Umsatzzahlen kräftig anzukurbeln.
Von der Liberalisierung sollen vor allem das Kern-Geschäft mit neuen,
dann noch besseren, sichereren INTEL-Prozessoren profitieren. Die
Analysten warten bereits auf die neuen Produkte.
Ihr IT-Berater des Vertrauens erwartet Sie als Kunden noch heute in
Ihrem nächst gelegenen Medwida-Markt (alternativ bei Sutarn).
Jau! Die Deregulierung rollte nach 30 Jahren endlich auch den PC-Markt
auf. Speicherverwaltung und Sicherheit? Sozialistischer Humbug! Die
Umsätze steigen und steigen, die Blasen werden grösser und grösser.
Icke ®. schrieb:> Siehe die Absprachen zwischen> CPU-Herstellern und MS bezüglich Betriebssystemunterstützung
Hä? Wieso braucht es da Absprachen? Wenn Microsoft will das nur noch
Windows 10 auf neuen Kisten läuft, dann programmieren die entsprechend.
Sven D. schrieb:> Hä? Wieso braucht es da Absprachen?
Als AMD die 64-Bit x86 ISA definierte, signalisierte Microsoft an Intel,
dass sie bitteschön auf den Zug aufspringen mögen, statt selber etwas in
dieser Richtung zu definieren. Sonst seien sie bei 64 Bit x86 draussen.
A. K. schrieb:> Gibts zu dem Thema tatsächlich Radio mit Fachkenntnis?
Mein Gott, wie borniert du doch bist.
Die berichteten da, dass die Sicherheitslücke nur mit neuen Prozessoren
zu beseitigen sei, Intel aber schon Prozessoren habe, die diese
Sicherheitslücke nicht hat.
F. F. schrieb:> Mein Gott, wie borniert du doch bist.
Danke für die Blumen. Aber ich bin über die Jahre mit dem "Stille Post"
Spiel der Medien einigermassen vertraut geworden. Daher ist nicht ganz
unwichtig, woher eine Information stammt und wieviele andere Leute
zwischen der letzten sachkundigen Quelle und der Präsentation sitzen.
Soll heissen: Ich versuche, nicht unbesehen alles wörtlich zu glauben,
was ich irgendwo höre oder lese. Sondern ziehe es ab und zu vor,
gegenzuchecken. Aber ich weiss, dass ich damit in der Minderheit bin.
Es ist schon klar, wenn man etwas genauer wissen will, dass es dann
nicht reicht Radio zu hören.
Aber für die Annahme, dass Intel den Markt ankurbeln will, weil gerade
die höherwertigen Prozessoren (z.b. i 7) nicht die erhofften
Verkaufszahlen brachten.
Ich weiß von dir, dass du auch nicht mehr so ganz jung bist und die
Anfänge noch kennst. Intel hat über Jahre Zuwachsraten im zweistelligem
Prozent Bereich gehabt.
Wo sie aktuell liegen weiß ich nicht. Vor einigen Jahren hatten sie
immer noch 13%, was so nicht schlecht für andere Firmen wäre, aber nur
zwei Jahre vorher hatten sie 25,...% gehabt.
Und heute?
Wo fängt ein Büro Computer an (der so für die meisten Heimanwender
völlig reicht), ist es nicht um die 300 €?
Dabei ist dann schon satt Software.
Aber die meisten kaufen nicht mal mehr diese, weil ihnen ihr Tablet und
Mobiltelefon reicht.
F. F. schrieb:> Mein Gott, wie borniert du doch bist.
Ähem, Foldi, das hat sich A.K. bestimmt nicht verdient. Er gehört
zu denen, die hier allemal am ausgewogensten daherkommen.
F. F. schrieb:> Aber für die Annahme, dass Intel den Markt ankurbeln will, weil gerade> die höherwertigen Prozessoren (z.b. i 7) nicht die erhofften> Verkaufszahlen brachten.
Ich bräuchte eine einigermassen glaubhafte Quelle für
> dass Intel schon neue Prozessoren hätte, die diese Sichereitslücke> nicht hätten."
Ich hatte daraufhin gesucht, und nichts in dieser Richtung gefunden.
Lediglich etwas Info, die man in dieser Richtung missverstehen kann. Die
sich aber tatsächlich auf OS-Patches bezieht und evtl. auch
Microcode-Patches.
Bis dahin ist das für mich Spekulation. Hier im Thread wurde auch schon
spekuliert, dass es nur so qualmt, ohne dabei mehr Grundlage zu haben
als ein Bauchgefühl und allgemeine politische und wirtschaftliche
Ansichten.
Joachim S. schrieb:> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?
Laut orf.at haben die zusammengearbeitet.
http://orf.at/stories/2421147/2421148/
A. K. schrieb:> Soll heissen: Ich versuche, nicht unbesehen alles wörtlich zu glauben,> was ich irgendwo höre oder lese. Sondern ziehe es ab und zu vor,> gegenzuchecken. Aber ich weiss, dass ich damit in der Minderheit bin.
Apropos glauben, ich kann auch gar nicht glauben was MS mir da gerade
alles frisch als Update getarnt 1) reingespült hat auf meinem Rechner:
Hier der Inhalt fürs liebe Excel
http://download.microsoft.com/download/4/6/E/46EE95B4-7B13-4157-BAD1-854D4FA4855A/4056894.csv
1)
2018-01 – Monatliches Sicherheitsqualitätsrollup für Windows 7 für
x64-basierte Systeme (KB4056894)
Installationsdatum: 05.01.2018 09:36
Installationsstatus: Erfolgreich
Updatetyp: Wichtig
In einem Microsoft-Softwareprodukt wurde ein Sicherheitsproblem
festgestellt, das Auswirkungen auf Ihr System haben könnte. Durch die
Installation dieses Updates von Microsoft können Sie zum Schutz Ihres
Systems beitragen. Eine vollständige Liste der Problembehebungen in
diesem Update finden Sie in dem entsprechenden Microsoft Knowledge
Base-Artikel. Nach der Installation dieses Updates müssen Sie das System
gegebenenfalls neu starten.
Weitere Informationen:
http://support.microsoft.com/help/4056894
Hilfe und Support:
http://support.microsoft.com/help/4056894
W.S. schrieb:> Wer von euch Programmierern kennt sich> denn z.B. in den Details internationalen Seerechts aus?
Frag mal was Konkretes, mit etwas Glück kann ich's dir beantworten,wenn
es nicht zu vertrackt ist.
Aber die Frage ist gut gewählt, wie beim internationalen Seerecht ist es
schwierig Greift die Hoheitlich Gesetzgebung nur bei Wirken der
Beteiligten vom Hoheitsgebiet aus. Alles weiter ist Vertragsrecht.
Allerdings gibt es die Seefahrt betreffend Schon lange internationale
Abkommen. Das internationale Recht das Internet betreffend steckt
dagegen in den Kinderschuhen. muss aber kommen.
Wie im Seerecht mauern die Staaten allerdings wenn die Eigenen
Souveränität z.B. der Marine betroffen ist. Im Internet nehmen die
Geheimdienste diese Position ein.
Namaste
A. K. schrieb:> Aber ich bin über die Jahre mit dem "Stille Post"> Spiel der Medien einigermassen vertraut geworden.
Doktorarbeiten: teilweise falsch abgeschriebene Bedeutung von
Theoriebegriffen, -> leicht falsche Hauptannahmen -> die ganze Arbeit
für die Tonne - wie auch die anschließenden Veröffentlichungen.
"Schuld" z.T. maßlose Übertreibung mit Fachbegriffen oder anderen
abstrakten Wörterwelten.
Medien: die wiederholen seit etwa 20 Jahren penetrant 3 - 5
Kampfbegriffe, nach politischem Gusto, das ist nicht stille Post, das
ist Gehirnwäsche.
Stille Post wäre ein gutes Beispiel für einen "lebendigen" Vorgang.
(Medienimitation für einen Bot wäre im Moment viel einfacher, als stille
Post Imitation).
Mampf F. schrieb:> Mal eine dumme Frage ... Wenn unter Linux der gesamte> Physikalische> Speicher ausgelesen werden kann, was bringt dann der KAISER-Patch> überhaupt?
Er verhindert das dieser im Betriebsystem offene Sidechanal mit
legitimierter Software für Illegitime Zugriffe benutzt werden kann.
Er verhindert nicht, das Schadsoftware welche der User dummerweise
installiert und mit passender Prio ausstattet (wissend oder nicht) die
bekannten Lücken auch zukünftig nutzt.
was Apple jüngst zum Anlass nimmt wieder einmal darauf hinzuweisen SW
nur via Appstore zu beziehen.
Namaste
Jörg W. schrieb:> Ganz plötzlich wissen die Spitzbuben dann halt> doch, wie man in kürzester Zeit eben tatsächlich interessante Nadeln> in diesem 8 GiB großen Heuhaufen finden kann
OK. Sämtliche Spitzbuben dieser Welt hätten das bereits vor etwa 10
Jahren wissen und ausnützen können. Nehmen wir also mal an, daß
tatsächlich alle Spitzbuben, denen dies wichtig und machbar war/ist,
selbiges bereits seit langem praktiziert haben.
Was ich sehe, ist ein sehr unguter Zug dieser Zeit, der darin besteht,
alles und jedes nur noch im und mit Netzwerk und Internet tun zu wollen.
Guck in die Läden, guck auf's Publikum in U-Bahn und Bus, was die
machen. Das Nutzungsverhalten ist massiv vom stationären PC zu
Smartphones und Tablets übergegangen und ein jeder, der mit sowas
herumfuchtelt, ist eben eine Zielscheibe für obige Spitzbuben. Es ist
nicht das Stück Hardware, sondern die allzeitige Verbindung in den
elektronischen Urwald.
Das sind - mal ganz kurz gefaßt - eben UNSICHERE STRUKTUREN.
Mir hatte es schon vor langen Jahren nicht geschmeckt, daß sowohl Apple
als auch Google aus der Ferne auf Millionen von Mobiltelefonen Dateien
gelöscht hatten.
Entsinnst du dich daran?
Das waren die Vorboten, die zumindest mir klar gemacht hatten, daß man
auf allen Systemen, die an fernzugänglichen Netzwerken hängen, auf gar
keinen Fall wirklich sensible Daten halten darf.
Wer es dennoch tut, steht eben mit beiden Beinen auf unsicheren
Strukturen und braucht sich nicht zu wundern, wenn er ne Zielscheibe für
Spitzbuben abgibt.
Dabei wäre es ja einfach, dem zu begegnen: Zwei PC's, einer mit all dem,
was einem wirklich wichtig ist, der andere für's Herumdaddeln im
Internet. Also Trennung der Sphären auf die brachiale Art. Das hilft
zumindest jedem Privaten.
Die Probleme bei den Rechenzentren in den Netzwerken und allgemein im
Internet sind was anderes. Aber für sowas sollten eigentlich keine
PC-Komponenten, sondern Mainframes benutzt werden, die für
sicherheitsrelevante Arbeiten geeignet sind. OK, die kosten dann auch
was.
Aber keiner hat in den letzten Jahre von Sicherheitsbedenken wirklich
etwas hören oder sehen wollen. Auch hier in diesem Forum nicht (* s.u.).
Ich kann das verstehen, die Leute fassen eben diese Vernetztheit als
einen Zugewinn an Lebensqualität auf. Vielleicht ist es das ja auch -
aber eben wie ein siamesischer Zwilling mit einem "Zugewinn" an
Unsicherheit verbunden.
Es geht in die falsche Richtung:
- möglichst alles drahtlos,
- Daten in der Cloud,
- IOT,
- zwangsweise elektronische Übermittlung von sensiblen Daten an die
Obrigkeit,
- Software, die sich nur dann benutzen lassen will, wenn sie ins
Internet kommt,
- Verwendung von PC-Komponenten und PC-Software für Zeugs, wo das
eigentlich nicht hingehört - von der AKW-Steuerung über Bankautomaten
bis zur Fahrtenplanung bei Bahn und Bus.
Ich sehe das so, daß sich wohl gar nichts in die richtige Richtung
ändern wird, weil alle Leute jedem Hype begeistert nachrennen. Die Leute
werden es wohl nie begreifen, daß man sich im elektronischen Wald eben
nicht mit einem Paßwort oder ner Girlande wo "Firewall" draufsteht gegen
die elektronischen Wölfe schützen kann.
W.S.
(*) Ich kann mich entsinnen, daß auf meine Bedenken bezüglich
sicherheitskritischer Strukturen damals von "Spezialisten" geantwortet
wurde, daß men eben bessere Virenscanner benötigte...
W.S. schrieb:>> Die Probleme bei den Rechenzentren in den Netzwerken und allgemein im> Internet sind was anderes. Aber für sowas sollten eigentlich keine> PC-Komponenten, sondern Mainframes benutzt werden, die für> sicherheitsrelevante Arbeiten geeignet sind. OK, die kosten dann auch> was.
Und sind vor allem nicht weniger betroffen, denn deren Performance wäre
unterirdisch, würden sie nicht heute genau so gebaut sein wie die bösen
PC CPUs. Und ja, ich habe schon Assembler-Code auf Mainframes
geschrieben. Und zwar zu Zeiten, als der noch nicht spekulativ
ausgeführt worden ist.
Winfried J. schrieb:> Mampf F. schrieb:>> Mal eine dumme Frage ... Wenn unter Linux der gesamte>> Physikalische>> Speicher ausgelesen werden kann, was bringt dann der KAISER-Patch>> überhaupt?>> Er verhindert das dieser im Betriebsystem offene Sidechanal mit> legitimierter Software für Illegitime Zugriffe benutzt werden kann.>> Er verhindert nicht, das Schadsoftware welche der User dummerweise> installiert und mit passender Prio ausstattet (wissend oder nicht) die> bekannten Lücken auch zukünftig nutzt.
Das versteh ich nicht ...
Ich hab gelesen, dass man mit Meltdown auf jede Zelle des physischen
Speichers zugreifen kann und dagegen gibt es imho dann keinen Schutz.
Man findet den Kernel evtl nur nicht so leicht.
Egal ob es jetzt legitimierte Software ist, die böses macht oder
Schadsoftware (imho eh das gleiche).
Mampf F. schrieb:> Ich hab gelesen, dass man mit Meltdown auf jede Zelle des physischen> Speichers zugreifen kann
Von der Art des Bugs her kann Meltdown eigentlich nur den gesamten
virtuellen Speicher des aktuellen Prozess-Adressraums lesen, Userspace
und Kernelspace. Egal ob er offiziell zugreifen darf oder nicht. Sollte
allerdings der physikalische Speicher vollständig in den virtuellen
Kernelspace gemappt sein, dann geht das natürlich.
> und dagegen gibt es imho dann keinen Schutz.
Die PTI (Page Table Isolation) Patches der Betriebssysteme sorgen dafür,
dass der Kernelspace im Userkontext eines Prozesses nicht mehr Teil des
Prozess-Adressraums ist. Dann kommt Meltdown nicht mehr an den
Kernelspace ran, somit auch nicht an den darin gemappten physikalischen
Speicher.
Ich konnte lesen, dass bei diesem Problem Virenscanner und Firwall
schräge Aktivitäten bezüglich dieser "Lücke"bemerken würden. Wo sind
denn eigentlich die von der "Snakeoil Fraktion" zu diesem Thema? Im
übrige denke ich wird zur Zeit dieses Thema zu heiß gegessen. Die
wirklich bösen Buben denke ich waren bis dto. ahnungslos. Klein Erna und
groß Hugo werden auch in Zukunft ruhig schlafen können. Intel hat
mittlerweile eine Liste betroffener CPU´s veröffentlicht. Von AMD hat
man noch nichts vernommen.
Kaj G. schrieb:> Ich musste schon sehr lachen :D
Der Vergleich hinkt. Im Sinn von Meltdown schickt dich das Navi (branch
predictor) in die Bar. Aber nachdem du merkst, dass das nicht der Weg
nach Hause ist, kommst du wieder raus. Nur kannst du dich an nichts mehr
erinnern. Was drin passierte lässt sich jedoch aus dem Seiteneffekt
rekonstruieren, dass dein Cash leer ist (du aber voll).
A. K. schrieb:> Der Vergleich hinkt. Im Sinn von Meltdown schickt dich das Navi (branch> predictor) in die Bar. Aber nachdem du merkst, dass das nicht der Weg> nach Hause ist, kommst du wieder raus. Nur kannst du dich an nichts mehr> erinnern. Was drin passierte lässt sich jedoch aus dem Seiteneffekt> rekonstruieren, dass dein Cash leer ist (du aber voll).
Das Navi schickt Dich selbstsicher in die Bar. Dort gibst Du Dein Geld
aus und trinkst. Dann erst bemerkt das Navi, daß es Dich dort nicht
hätte hinschicken dürfen. Es versucht jetzt schnell noch alles zu
vertuschen, besticht den Kellner daß er das Geld wieder rausrückt, etc.
- aber letztlich erkennt man doch noch an der Fahne wo Du warst.
Gerd E. schrieb:> Dann erst bemerkt das Navi, daß es Dich dort nicht> hätte hinschicken dürfen.
Nope. Diese Sorte Navis merkt das nicht. Das merkt man erst selber. Ein
branch predictor korrigiert sich nicht selbst, sondern wird von der
execution unit korrigiert.
Auch kriegst du den Inhalt vom Cash (Cache) nicht wieder. Das ist es ja
gerade, anhand dessen Meltdown merkt, was drinnen passiert ist.
Winfried J. schrieb:> Oder jemand hat eine backdoor offengelegt,welche jetzt kompromittiert> ist?
Ich hoffe dies beruhigt dich: ;-)
Rob Joyce, White House cybersecurity coordinator, said, “NSA did not
know about the flaw, has not exploited it and certainly the U.S.
government would never put a major company like Intel in a position of
risk like this to try to hold open a vulnerability.”
A. K. schrieb:> Ich hoffe dies beruhigt dich: ;-)>> Rob Joyce, White House cybersecurity coordinator, said, “NSA did not> know about the flaw, has not exploited it and certainly the U.S.> government would never put a major company like Intel in a position of> risk like this to try to hold open a vulnerability.”
Da haben wir ja noch mal Glück gehabt ;-)
A. K. schrieb:> Ich hoffe dies beruhigt dich: ;-)
Ja genau, weil der Dienstgeber dem von Ihm Beauftragten Dienst ein
Alibi ausstellt.
Bitte! Nur wegen so einer Erklärung ist doch nicht die Begehrlichkeit
ausgeräumt oder gar ein solcher Dienst rein gewaschen. Also jetzt
erstaunst du mich doch etwas. Soll ich dir mein Ironieschild leihen?
Ein Dementi im falschen Augenblick und ohne Not verkündet, damit kenne
wir Ossis uns aus, da klingelt es Alarm und die Erdschlussklappe fällt
aus dem Klappenschrank.
Namaste
Winfried J. schrieb:> Bitte! Nur wegen so einer Erklärung ist doch nicht die Begehrlichkeit> ausgeräumt oder gar ein solcher Dienst rein gewaschen. Also jetzt> erstaunst du mich doch etwas. Soll ich dir mein Ironieschild leihen?
Könnte es sein, dass du deinen Detektor grad schon verliehen hast. ;-)
Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch
für fragwürdig.
Fakt ist, es ist ein Stück Hardware, welche man nicht eben ändern kann.
Eine Softwarelücke ist schnell gepatcht bzw. verschwunden und
hinterlässt dabei kaum Spuren. Die werden solch ein Risiko sicher nicht
eingehen. Von daher glaube ich Ausnahmsweise auch, was die NSA sagt :)
Trotzdem kann man sich nicht sicher sein. Vielleicht hat Intel auch eine
entsprechend große Hand aufgehalten, für den Fall des Falles. Wer weiß.
Aber Spekulationen haben noch nie viel gebracht...
Billiger Kommentator schrieb:> Aber Spekulationen haben noch nie viel gebracht...
rofl
Hier dein Ironischild bitte sorgfältig benutzen.
Erklär das mal den Jungs an de Börse.
Namaste
Winfried J. schrieb:> der liegt grad unter der Glaskugel und sucht nach der witzigen Stelle in> deinem Post. ;)
Die Kugel ist sicherlich schon länger in deinem Besitz und daher
befangen, das wird dann nichts. Ironie wird nicht immer als witzig
empfunden. Besonders nicht von jenen, die man damit auf den Arm nimmt.
;-)
Billiger Kommentator schrieb:> Aber Spekulationen haben noch nie viel gebracht...
Besonders schlecht ist, wenn spekulative Codeausführung für Angriffe
ausgenutzt werden kann.
Bei der ganzen Aufregung wird leider oft vergessen, dass sich die
Prozessoren durchaus spezifikationskonform verhalten, d.h. das
Zusammenspiel von OOO-Ausführung, MMU und Cache erfolgt genau so, wie
man es "gemäß Lehrbuch" erwarten würde. Es geht hierbei nicht um eine
fehlerhafte Implementierung, die ursprünglich vielleicht einen IP-Block
betraf und anhand derer man dessen Weitergabe hätte verfolgen können.
Nein, das Problem steckt schon in dem ganzen Konzept und lag die ganze
Zeit offen! Daher wird man auch Intel usw. auch nicht juristisch ans
Bein pinkeln können. Die Art und Weise, wie die Prozessoren aufgebaut
sind, entsprach eben bis vor ein paar Monaten dem aktuellen Stand der
Technik. Neuerdings aber eben nicht mehr.
Billiger Kommentator schrieb:> Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch> für fragwürdig.
Dann ist dir was entgangen. Die sammeln Daten von jedem,
Bewegungsprofile werden erstellt und sogar ein Zusammenhang hergestellt.
Wenn du wissen willst, ob deine Frau sich mit einem anderen trifft oder
ob sie da ist, wo sie angibt zu sein, dann frag die NSA. Hast du die
riesigen Serverfarmen nicht gesehen. Riesige Gebäude.
Andreas S. schrieb:> Bei der ganzen Aufregung wird leider oft vergessen, dass sich die> Prozessoren durchaus spezifikationskonform verhalten, d.h. das> Zusammenspiel von OOO-Ausführung, MMU und Cache erfolgt genau so, wie> man es "gemäß Lehrbuch" erwarten würde.
Wobei ich zwischen Meltdown und Spectre etwas unterscheiden würde.
Bei Meltdown kann man drüber streiten, ob ein spekulativ ausgeführter
Load im unzulässigen Fall wirklich die realen Daten liefern sollte. Das
muss nicht sein, wie man an AMD sieht. Auch wenn nicht nur Intel
betroffen ist, sondern auch diverse ARMs, sehe ich das schon als Bug.
Bei Spectre hingegen liegt es voll im Prinzip der Arbeitsweise. Weshalb
auch wirklich jeder betroffen ist, es nur vielleicht bei manchen
schwieriger auszunutzen ist.
> Nein, das Problem steckt schon in dem ganzen Konzept und lag die ganze> Zeit offen!
Wobei noch die eine oder andere Stinkbombe platzen könnte. Denn
ausnutzbare side channels sind schon länger bekannt. Dass es möglich
sein kann, Crytoverfahren über ähnliche side channels abzugreifen ist
schon seit Jahren bekannt und davon hatte ich auch schon mal gehört. Bei
Fefe sammeln sich grad ein paar Links über frühe Erkenntnisse darüber:
https://twitter.com/TheSimha/status/949361495468642304https://twitter.com/cperciva/status/949216126331887616
F. F. schrieb:> Wenn du wissen willst, ob deine Frau sich mit einem anderen trifft oder> ob sie da ist, wo sie angibt zu sein, dann frag die NSA.
Da würde ich eher Google fragen, die haben Handy standort Daten (für
W-Lan ortungs verbesserung), Mails vom Gmail Account, Browser history,
eventuell noch einige Fotos und andere Daten über Google Drive & co
(z.B. deine What's App Nachrichten vom online Backup), etc. Ziemlich
lückenlose geschichte.
A. K. schrieb:> Stinkbombe platzen könnte
fehlplatzierter Konjunktiv
ersetzte durch FuturII
-platzen könnte +geplatzt sein wird
Von der zukünftigen Vollendung kann bereits sicher ausgegangen werden.
Namaste
Andreas S. schrieb:> Bei der ganzen Aufregung wird leider oft vergessen, dass sich die> Prozessoren durchaus spezifikationskonform verhalten, d.h. das> Zusammenspiel von OOO-Ausführung, MMU und Cache erfolgt genau so, wie> man es "gemäß Lehrbuch" erwarten würde. Es geht hierbei nicht um eine> fehlerhafte Implementierung, die ursprünglich vielleicht einen IP-Block> betraf und anhand derer man dessen Weitergabe hätte verfolgen können.>> Nein, das Problem steckt schon in dem ganzen Konzept und lag die ganze> Zeit offen! Daher wird man auch Intel usw. auch nicht juristisch ans> Bein pinkeln können. Die Art und Weise, wie die Prozessoren aufgebaut> sind, entsprach eben bis vor ein paar Monaten dem aktuellen Stand der> Technik. Neuerdings aber eben nicht mehr.
Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die
Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,
wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms
verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben
manchmal darauf verzichten.
Carl D. schrieb:> Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die> Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,> wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms> verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben> manchmal darauf verzichten.
Das gehört zum Thema "Abwehr bestimmter Angriffe". Genau darüber sichert
man sich nun in Browsern gegen Spectre per Javascript ab, über das
Sessions sich gegenseitig belauschen können. Das wäre auch ein Thema für
Microcode-Updates, also RDTSC ausreichend zu jittern.
Nur: Es ändert nichts am Prinzip. Das Grundproblem von Spectre, dass
sich Prozesse gegenseitig beeinflussen, bleibt. Man braucht nur einen
neuen Weg, das auszunutzen.
F. F. schrieb:> Billiger Kommentator schrieb:>> Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch>> für fragwürdig.>> Dann ist dir was entgangen. Die sammeln Daten von jedem,> Bewegungsprofile werden erstellt und sogar ein Zusammenhang hergestellt.> Wenn du wissen willst, ob deine Frau sich mit einem anderen trifft oder> ob sie da ist, wo sie angibt zu sein, dann frag die NSA. Hast du die> riesigen Serverfarmen nicht gesehen. Riesige Gebäude.
Naja, hier wird von Seiten der USA auch bewusst versucht einen Mythos
aufrechtzuerhalten, nämlich den der (angeblichen) permanenten
Totalüberwachung und damit Allwissenheit über so ziemlich jeden von uns,
insbesondere der eigenen Bürger. Das mag vereinzelt schon mal so sein,
aber wenn das immer so wäre, wäre es auch ein leichtes gewesen
beispielsweise das FBI vorbeizuschicken, als der Trump Clan sich mit
einer russischen Anwältin traf, zum "Informationsaustausch" (man könnte
es auch Spionage nennen) über einen bzw. eine mögliche nächste
US-Präsidentin (lies Äußerungen von Steve Bannon dazu). Das hätte einen
Skandal gegeben und womöglich die paar Prozent abgehalten ihn (Trump) zu
wählen, die ihn knapp ins Amt beförderten.
Jetzt wird natürlich wieder ein Schlaumeier daherkommen und sagen, klar
hat die NSA das alles gewusst und aufgezeichnet sowieso, nur halt aus
bestimmten Gründen nicht verwertet. Nur sind wir dann wieder bei den
beliebten Verschwörungstheorien, die immer dann sich Raum verschaffen,
wenn es gilt: "Nix genaues weiß man nicht".
Bedenke, je mehr Informationen gesammelt werden, desto schwieriger wird
es daraus noch das Wissenswerte zu filtrieren. Kennt jeder von seiner
eigenen Festplatte. Je mehr Info, desto gröber muss das Suchraster sein,
um in angemessener Zeit noch das zu finden, was man sucht und im Fall
der NSA ist es mit der Suche allein auch nicht getan. Irgendjemand muss
das Gefundene dann auch noch bewerten und selbst beim Einsatz von KI
wird man nicht um eine individuelle und damit zeit- und
personalaufwändige Einschätzung dieser Daten herumkommen.
Hierzulande braucht es mehr als zwei Dutzend Spezialisten um auch nur
EINEN mutmaßlichen Gefährder (Islamisten) rund um die Uhr zu überwachen.
Glaubt du diese Arbeit könnte die NSA aus der Ferne mittels ihrer
Computer übernehmen, so dass man sich die Spezialisten hierzulande
einsparen könnte? Ich nicht!
Wüssten sie bei der NSA zu jeder Zeit immer alles, wäre Edward Snowden
wohl die Flucht niemals geglückt.
Alles Humbug schrieb:> klar> hat die NSA das alles gewusst und aufgezeichnet sowieso
Sicher nicht alles, aber schon 'WannaCry' hat ja gezeigt, das die Damen
und Herren der NSA durchaus Sicherheitlücken in populärer Software
verschweigen, wenn es ihnen nützlich erscheint, wobei das 'Security' in
der Bezeichnung ihrer Behörde dann ein wenig nach blankem Hohn klingt.
Eine Attacke mit Spectre oder auch Meltdown hat zudem den Vorteil, das
so gut wie jedes Stückchen Software, das sich das Opfer auf den Rechner
lädt, unauffällig im Hintergrund seine Schnüffelarbeit tut - ideal für
Massenangriffe auf Privatdaten. Und diesmal muss es nicht mal Windows
sein, wie sonst immer. Es reicht ein Intel oder AMD, und damit sinds
auch die Apples und Linuxe.
Interessant wird es bei IBMs zSeries, also deren Mainframes. Das sind so
ungefähr die letzten Highend-Prozessoren gewesen, die erst 2010 auf
spekulative Ausführung umschwenkten. Das ist aber eine Plattform, bei
der neben Verfügbarkeit bestimmt auch Sicherheit ein wichtiges Thema
ist.
Zwar sind die nicht erste Adresse bei der Ausnutzbarkeit, weil da
seltener Fremdcode ohne weiteres draufhuschen dürfte, als es bei Clouds
oder Clients der Fall ist. Aber dafür sind die Kunden empfindlicher.
Matthias S. schrieb:> Eine Attacke mit Spectre oder auch Meltdown hat zudem den Vorteil, das> so gut wie jedes Stückchen Software, das sich das Opfer auf den Rechner> lädt, unauffällig im Hintergrund seine Schnüffelarbeit tut - ideal für> Massenangriffe auf Privatdaten.
Konzeptfehler auszunutzen hat gegenüber Software-Bugs einen schwer
wiegenden Nachteil: Man sitzt genauso tief in der Tinte wie alle
anderen, ohne etwas dagegen tun zu können. Wenn ich als NSA ein Leak
ausnutzen will, dann achte ich darauf, das ich es bei Bedarf schnell
stopfen kann. Andernfalls kann das auch jeder andere ausnutzen.
Mal auf Handys bezogen: Wetten, dass es in Nordkorea praktisch keine
betroffenen Handys gibt? Aber umgekehrt hat Nordkorea seit Datum
xx.yy.20zz einen auf einem fehlerhaften Konzept beruhenden
Freifahrtschein für Angriffe auf Handys in den USA. Also da würde ich
als NSA nicht gut schlafen.
A. K. schrieb:> Interessant wird es bei IBMs zSeries, also deren Mainframes. Das sind so> ungefähr die letzten Highend-Prozessoren gewesen, die erst 2010 auf> spekulative Ausführung umschwenkten.
PS: Hätte die NSA das Thema damals auf dem Radar gehabt: Hätten die
nicht ausgerechnet dort diesen Weg verhindern müssen? Das wäre vmtl auch
niemandem aufgefallen, denn ein Beharren auf nichtspekulativer
Ausführung kann man in diesem Sektor auch anders begründen.
A. K. schrieb:> PS: Hätte die NSA das Thema damals auf dem Radar gehabt: Hätten die> nicht ausgerechnet dort diesen Weg verhindern müssen? Das wäre vmtl auch> niemandem aufgefallen, denn ein Beharren auf nichtspekulativer> Ausführung kann man in diesem Sektor auch anders begründen.
Unterstellen wir mal sie hatten es nicht "auf dem Radar". Was sagt uns
das dann über deren Fähigkeiten bei der NSA Sicherheitslücken zu finden,
um Spähsoftware dort einzuschleusen? Oder anders ausgedrückt, hat Google
vielleicht oder sogar anscheinend doch bessere Experten auf diesem
Gebiet als einer der bestausgerüsteten Auslandsgeheimdienste der Welt?
Alles Humbug schrieb:> Oder anders ausgedrückt, hat Google> vielleicht oder sogar anscheinend doch bessere Experten auf diesem> Gebiet als einer der bestausgerüsteten Auslandsgeheimdienste der Welt?
Den attraktiveren Arbeitsplatz bietet sicherlich Google. Besonders für
jene, die man nur unter Einsatz von Gewalt in Organisationen wie die NSA
kriegt.
Mit Geld kannst du Aufwand erschlagen, aber keine Ideen erzwingen. Das
funktioniert öffentlich besser als geheim.
Einer hat in einem Bürokratieapparat eine halbgare Idee. Chef sagt:
vergiss es! Ende der Geschichte. Öffentlich machen ist keine
Alternative. Wer will schon in der Bude neben Snowden wohnen.
Im offenen Markt von Ideen hat einer eine halbgare Idee. Macht ein Paper
draus, aber die passende Konferenz lehnt es ab. Also platziert er es im
Web. Jemand anders irgendwo auf der Welt sieht das vielleicht, greift
sie auf und findet das fehlende Glied, postet selber. Schwupps werden 10
weitere hellhörig und merken was da abgeht.
A. K. schrieb:> Wobei ich zwischen Meltdown und Spectre etwas unterscheiden würde.
Ja, definitiv. Obwohl beide aus taktischen Gründen gleichzeitig
veröffentlicht wurden, handelt es sich schon um unterschiedliche
Angriffe.
> Bei Meltdown kann man drüber streiten, ob ein spekulativ ausgeführter> Load im unzulässigen Fall wirklich die realen Daten liefern sollte.
Nach "altem Stand der Technik"(tm) war dies völlig akzeptabel, solange
sichergestellt wurde, dass diese Daten verworfen werden. Folglich
genügte es, bei der Architektur, dem Entwurf, der Implementierung und
den Tests solcher Prozessoren ausschließlich alle Ausführungspfade zu
analysieren, in denen eine Verwertung der spekulativ berechneten Daten
erfolgt.
> Das muss nicht sein, wie man an AMD sieht. Auch wenn nicht nur Intel> betroffen ist, sondern auch diverse ARMs, sehe ich das schon als Bug.
Ich sehe das ganze etwas formeller, gemäß dem Motto: "Operation
gelungen, Patient tot". Das zeitliche Verhalten der Prozessoren wurde ja
sehr teuer (Entwicklungsaufwand, Chipfläche) erkauft, aber niemand(?)
erkannte, was das alles bedeutete. Vor einigen Jahren befasste ich mich
auch mit möglichen Seitenkanälen durch Caching usw., aber erkannte auch
nicht die nun beschriebenen Angriffsmöglichkeiten.
Auf einer sehr abstrakten Ebene kann man das ganze zwar schon als Bug
bezeichnen, nicht jedoch auf der Implementierungsebene der Prozessoren.
> Bei Spectre hingegen liegt es voll im Prinzip der Arbeitsweise. Weshalb> auch wirklich jeder betroffen ist, es nur vielleicht bei manchen> schwieriger auszunutzen ist.
Ja.
> Wobei noch die eine oder andere Stinkbombe platzen könnte.
Es werden mit Sicherheit auch noch etliche andere
Implementierungsschwächen sehr weit verbreiteter Prozessorfamilien
bekannt werden, aber ob noch weitere derart universelle Schwächen
aufgedeckt werden, wage ich nicht zu beurteilen.
> Denn> ausnutzbare side channels sind schon länger bekannt. Dass es möglich> sein kann, Crytoverfahren über ähnliche side channels abzugreifen ist> schon seit Jahren bekannt und davon hatte ich auch schon mal gehört.
Insbesondere kommt es durchaus auch vor, dass das Stopfen eines
Seitenkanals plötzlich einen neuen überhaupt erst schafft. Es gibt
einige Computer, bei denen man mit großem Aufwand die elektromagnetische
Abstrahlung miniert hat. Allerdings wurde nicht bedacht, dass die vielen
verwendeten Drosseln und Keramikkondensatoren tolle magnetostriktive und
Piezolautsprecher darstellten. Bei früheren Versionen von GPG konnte man
daher die Entschlüsselungsvorgänge akustisch belauschen und mit
statistischen Verfahren sogar große Teile der geheimen Schlüssel
extrahieren.
Carl D. schrieb:> Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die> Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,> wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms> verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben> manchmal darauf verzichten.
Das war bei bisherigen Prozessoren eben kein Entwurfsziel, was sich aber
nun ändern wird. Sobald aber irgendein Fachmagazin dann aber
herausfindet, dass der neue Prozessor in irgendeinem synthetischen
Benchmark um 0,2% langsamer ist als die vorherige Generation, wird es
ein großes Geschrei geben, und die Erkenntnisse dieser Tage sind wieder
vergessen.
A. K. schrieb:> Interessant wird es bei IBMs zSeries, also deren Mainframes. Das sind so> ungefähr die letzten Highend-Prozessoren gewesen, die erst 2010 auf> spekulative Ausführung umschwenkten. Das ist aber eine Plattform, bei> der neben Verfügbarkeit bestimmt auch Sicherheit ein wichtiges Thema> ist.
Ich kann mir sehr gut vorstellen, dass man bei diesen Prozessoren sogar
die spekulative Ausführung deaktivieren kann. Womöglich wurde so etwas
schon implementiert, weil man ahnte, dass es irgendwann Probleme durch
Seitenkanalangriffe geben kann, ohne sie genau benennen zu können.
> Zwar sind die nicht erste Adresse bei der Ausnutzbarkeit, weil da> seltener Fremdcode ohne weiteres draufhuschen dürfte, als es bei Clouds> oder Clients der Fall ist. Aber dafür sind die Kunden empfindlicher.
Bei der Sicherheitsanalyse solcher Systeme geht man davon aus, dass
jeder Benutzer und jedes Programm für Angriffe genutzt wird und damit
versucht, Zugriff auf höher eingestufte Daten zu erhalten. Eines der
hierfür relevanten Stichwörter ist MLS (Multilevel security):
https://en.wikipedia.org/wiki/Multilevel_security
Systeme auf Basis der zSeries werden auch in solchen Umgebungen
eingesetzt, siehe:
ftp://public.dhe.ibm.com/s390/zos/racf/pdf/r04_mls_introduction.pdf
ftp://ftp.software.ibm.com/s390/zos/racf/pdf/r04_mls_update.pdf
Andreas S. schrieb:> Ich kann mir sehr gut vorstellen, dass man bei diesen Prozessoren sogar> die spekulative Ausführung deaktivieren kann.
Dafür reicht meine Phantasie nicht. Man kann sicherlich zig Dinge
abschalten, wie etwa bestimmte Sprungvorhersageverfahren. Aber einen OOO
Prozessor spekulationsfrei zu kriegen? Das bricht seine gesamte
Arbeitsweise.
Technisch mag das zwar möglich sein, wenn man es entsprechend eingeplant
hat. Der Einbruch wäre aber m.E. dramatisch. Auf 3-4 Befehle kommt ein
Sprung und der blockiert alles bis er retired ist. Das endet wesentlich
schlechter als feste Pipelines in einem nichtspekulativen Design.
Jedenfalls wäre IBM dann mächtig im Zugzwang. Mit "kauft einen neuen
teureren Recher, sobald wie einen haben, bis dahin bricht euch eben ab
zu der Laden zusammen" macht man sich keine Freunde. Klar, wer noch
nicht am Limit ist kriegt Prozessoren umsonst/verbilligt freigeschaltet.
Aber wer es schon ist?
Wer beim Bau ernsthaft ist Erwägung zieht, die OOO Arbeitsweise im
produktiven Umfeld abschalten zu müssen, der baut sie nicht erst ein.
Aber ich lasse mich da gerne überraschen. IBM fällt Jahr für Jahr
hauptsächlich damit auf, was sie alles nicht mehr machen. ;-)
Andreas S. schrieb:> Carl D. schrieb:>> Ist nicht ein zentraler Bestandteil des Angriffs die Zeit für die>> Ausführung von Befehlen usw. exakt messen zu können. Ist zwar schön,>> wenn der Prozessor mir sagen kann, wie oft er sich die letzten 0,5ms>> verspekuliert hat, aber wenn es ohne sicherer ist, dann muß man eben>> manchmal darauf verzichten.>> Das war bei bisherigen Prozessoren eben kein Entwurfsziel, was sich aber> nun ändern wird. Sobald aber irgendein Fachmagazin dann aber> herausfindet, dass der neue Prozessor in irgendeinem synthetischen> Benchmark um 0,2% langsamer ist als die vorherige Generation, wird es> ein großes Geschrei geben, und die Erkenntnisse dieser Tage sind wieder> vergessen.
Naja, die Performance-Counter abzuschalten sollte kein
Performance-Promille ausmachen. Wie gesagt, schön für den Programmierer,
der sein Programm fein-tunen will, aber für bunte Graphiken mit
Cloud-Performancedaten muß man nicht mit Nanosekunden Auflösung zählen.
Zur z-Serie:
Die hat den großen Vorteil, daß sie tauschbare Prozessorboards hat und
nicht in Millionenstückzahlen in irgendwelchen Notebooks verlötet ist.
Peter D. schrieb:> Also alles nur heiße Luft. Schade um die mit Lesen vergeudete Zeit.
Aus heutiger Sicht wohl schade um die vergeudete Zeit, diesen Beitrag zu
schreiben
> Beim branch target cache konnte es vorkommen, dass bei> erkanntem self modifying code Befehle doppelt ausgeführt wurden.
Wenn es um sowas geht, so einen "Fehler" hatte auch der 486er schon.
Wenn man einen Befehl im Speicher unmittelbar vor dessen Ausführung
modifiziert hat, blieb diese Modifikation wirkungslos, da der Befehl
bereits in den Dekoder geladen war und nicht neu aus dem Speicher geholt
wurde.
Ben B. schrieb:>> Beim branch target cache konnte es vorkommen, dass bei>> erkanntem self modifying code Befehle doppelt ausgeführt wurden.> Wenn es um sowas geht, so einen "Fehler" hatte auch der 486er schon.> Wenn man einen Befehl im Speicher unmittelbar vor dessen Ausführung> modifiziert hat, blieb diese Modifikation wirkungslos, da der Befehl> bereits in den Dekoder geladen war und nicht neu aus dem Speicher geholt> wurde.
Der BTIC war kein Teil eines Prefetchers, sondern ein spezieller I-Cache
für Sprungziele. Griff also dann, wenn man das tut, was man bei self
modifying code nach dem Speichern seit 8086 korrekterweise immer tun
sollte: springen. Denn solch ein Sprung vermeidet die von dir
beschriebenen Schmutzeffekte.
Der Bug führte dazu, dass nicht etwa der falsche Befehl ausgeführt
wurde, oder der alte, sondern 1-2 Befehle zweimal ausgeführt wurden.
Dieser Bug trat auch dann auf, wenn überhaupt kein self modifying code
vorlag. Der BTIC enthielt Befehlscode, musste also Schreiboperationen
scannen. Und dafür hat er nur einen Teil der Adressbits genutzt. Das
führte zu einer vorsätzlich in Kauf genommenen Fehlerkennung, die aber -
weil sehr selten - normalerweise nur die Laufzeit eines Programms
unmerklich beeinflusst hätte.
Der GCC enthält natürlich keinen self modifying code. Auf die Nase flog
er trotzdem. Am GCC lag es nicht, es lag am Prozessor. Das stand auch
schon vorher in den Erratas, allerdings ohne Hinweis auf die
unvollständige Erkennung. Kurz drauf stand auch die u.A. Note drin.
"Re-execution of Instructions Due to Self-Modifying Code
...
then: the long-decoded instruction, or the short-decoded instruction(s),
is executed twice.
Note: A potential self-modifying code condition means that the processor
detects all actual self-modifying code sequences, as well as some
sequences in which the processor "believes" that a self-modifying code
situation is occurring, but in reality is not (referred to as "false"
self-modifying code detection). The false detection occurs because the
processor does not check all 32 address bits when checking for
self-modifying code."
Billiger Kommentator schrieb:> Naja, ob die NSA wirklich in solch großem Stil operiert, halt ich auch> für fragwürdig.
Man erinnere sich an den NSAKey in Windows, der natürlich im Nachhinein
nur zufällig so hieß und rein gar nix mit der NSA zu tun hat… Ehrenwort!
> Fakt ist, es ist ein Stück Hardware, welche man nicht eben ändern kann.
Das ist doch gerade das Schöne aus Sicht von Geheimdiensten. Die Lücke
lässt sich nicht einfach mit einem Patch schließen. Deshalb kann man
Hardware-Verschlüsselung eigentlich auch nicht trauen.
> Eine Softwarelücke ist schnell gepatcht bzw. verschwunden und> hinterlässt dabei kaum Spuren. Die werden solch ein Risiko sicher nicht> eingehen. Von daher glaube ich Ausnahmsweise auch, was die NSA sagt :)
Und warum sollte das ein Vorteil für die NSA sein, wenn es besonders
leicht ist, ihnen ihren Zugang wieder zu schließen?
> Trotzdem kann man sich nicht sicher sein. Vielleicht hat Intel auch eine> entsprechend große Hand aufgehalten, für den Fall des Falles. Wer weiß.> Aber Spekulationen haben noch nie viel gebracht...
Seit Snowden sollte aber klar sein, dass da nicht weniger, sondern eher
deutlich mehr passiert, als man als nicht-Aluhutträger eigentlich
vermuten würde. Deshalb traue ich den USA in der Hinsicht alles zu und
halte jegliche in den USA entwickelte closed-source Computer-Hard- und
Software nicht für zweifelsfrei vertrauenswürdig.
Rolf M. schrieb:> und> halte jegliche in den USA entwickelte closed-source Computer-Hard- und> Software nicht für zweifelsfrei vertrauenswürdig.
Nach meiner bescheidenen Meinung lässt sich das beliebig ausdehnen.
Schon rein wirtschaftliche Interessen berechtigen zu dieser Annahme. Mit
der Auswahl des Produktes fällst du nur die Entscheidung in welcher
Krake Hände du dich begibst, nicht ob.
Herr schütze mich vor meinen Freunden, meiner Feinde will ich gewahr
sein.
Namaste
Das impliziert doch, dass der NSA die Möglichkeit zur Schnüffelei so
viel Wert sei, dass sie bereit sei, auch jedem potentiellen Gegner
freien Einblick in amerikanische Inhalte zu gewähren, ohne irgend etwas
dagegen tun zu können?
Wäre das nicht Hochverrat?
A. K. schrieb:> Das impliziert doch, dass der NSA die Möglichkeit zur Schnüffelei so> viel Wert sei, dass sie bereit sei, auch jedem potentiellen Gegner> freien Einblick in amerikanische Inhalte zu gewähren, ohne irgend etwas> dagegen tun zu können?>> Wäre das nicht Hochverrat?
Nein, die haben doch spezielle Prozessoren in Amerika. Die haben
Prozessoren ohne Sicherheitslücke extra in der Area51 produzieren
lassen, umgelabelt, heimlich ausgetauscht und dann nur in Amerika in den
Verkauf gebracht...
Ironie und Verschwörungstheorie aus
Daher sage ich bei deinem Beitrag nur: DITO!
WENN die Staatsorgane der USA wirklich die gleichen Intel Prozessoren
mit den Sicherheitslücken haben, sollte klar sein, dass die da nicht mit
drin stecken. Haben die andere Prozessoren, dann könnte man durchaus
hellhörig werden.
Billiger Kommentar schrieb:> Die haben Prozessoren ohne Sicherheitslücke extra in der Area51> produzieren lassen
So ist offensichtlich der 8051 entstanden. Und der ist ja tatsächlich
nicht betroffen, obwohl er von Intel ist.
Aber ob er noch den heutigen Ansprüchen genügt?
Ja für so opportunistisch muss man solche Org's halten.
Schon vergessen? Wer mit dem Teufel speist braucht einen langen Löffel.
Die Hybris des absoluten Wissens über die absolute Wahrheit zu
verfügen,und auf der Seite des Guten zu kämpfen und gegen das Böse, ist
essentieller Teil eines solchen Weltbildes. Das ist in allen
Staatsformen gleich weil zu tiefst menschlich. Es erleichtert das eigene
Handel als gerechtfertigt anzusehen auch in fragwürdiger Situation.
Ehrgeiz schützt vor Dummheit nicht.
Beitrag "Re: Schwere Sicherheitslücke in Intelprozessoren?"
Namaste
A. K. schrieb:> Wäre das nicht Hochverrat?
Nach Ockham genügt auch Mangel an Phantasie egal wie ausgeprägt und
bezogen auf welche Abstraktionsstufe.
Namaste
Winfried J. schrieb:> Schon vergessen? Wer mit dem Teufel speist braucht einen langen Löffel.
In der Betriebskantine der NSA muss es lustig aussehen. ;-)
und nun seid ihr doch alle fleissig am verschwörungstheoretisieren
und polemisieren. Genau das, was man mir vorgeworfen hat.
wer also im Glashaus sitzt, sollte aufpassen wohin man die Steine wirft.
Billiger Kommentar schrieb:> Nein, die haben doch spezielle Prozessoren in Amerika. Die haben> Prozessoren ohne Sicherheitslücke extra in der Area51 produzieren> lassen, umgelabelt, heimlich ausgetauscht und dann nur in Amerika in den> Verkauf gebracht...
und du glaubst wirklich der MIK leistet sich nicht teure Entwicklungen
von Costum Prozessoren? Dann sage dir was. Ander OHS in Stralsund war
ich 1985-86 persönlich am Brainstorming für ein während des Abschusses
programmierbaren Mikrocontrollers auf U8810 Basis zur Einstellung der
Zerlegergrenze von Luftabwehrgeschossen befasst.
Wir hatten Kopien von äquivalenten Erfindungen aus dem Bundesdeutschen
Patentamt, geheim gestempelt im Schnitt 2 Jahre alt. Unser Mc sollte im
HFO als Customchip mit OTP und wenigen Registern gefertigt werden. Haken
war das programmieren im stickstoffgekühlten Patronenlager bei 3000
Schuss pro Minute.
Alles war GVS.
Alle Aufzeichnungen waren nur in einer personengebundenen GVS Kladde zu
führen und wurden bei Verlassen des Gebäudes petchiert in der VS-Stelle
gegen Protokoll hinterlegt. Auch meine persönlichen Aufzeichnungen zum
Thema durfte ich nur dort führen und hinterlegen.
Glaub mir Die USA haben noch ganz andere Projekte.
Und wenn du das nicht glaubst beschäftige dich mit dem Kampf der Briten
gegen die Ubotflotte
Stichworte enigma--> the bomb ---> Ellen Turing--->Eniac
die Akten dazu waren bis vor wenigen Jahren Top Secret.
Namaste
Rolf M. schrieb:> Winfried J. schrieb:>> Costum Prozessoren>> Da hab ich doch eine Idee, als was ich mich dieses Jahr zu Fasching> verkleide.>> SCNR
S'il te plait bell.
Namaste
Rolf M. schrieb:> Da hab ich doch eine Idee, als was ich mich dieses Jahr zu Fasching> verkleide.
Manche könnten versucht sein, dich daran zu erinnern,
dass Halloween im Herbst ist.
Aber vielleicht gibts trotzdem ein paar Bonbons.
Andreas S. schrieb:> Sobald aber irgendein Fachmagazin dann aber> herausfindet, dass der neue Prozessor in irgendeinem synthetischen> Benchmark um 0,2% langsamer ist als die vorherige Generation, wird es> ein großes Geschrei geben, und die Erkenntnisse dieser Tage sind wieder> vergessen.
Berechtigt, berechtigt.
Ich warte ja jetzt schon immer dass dieser lahme Idle-process endlich
mal fertig wird ...
/regards
P.S:
Schöner, hochinformativer Fred :)
Baum schrieb:> Raspberry Pi sind nicht betroffen?> Alle modelle?
Alle. V1: ARM11, V2: Cortex A7, V3: Cortex A53. Alle haben eine in-order
Bauweise, arbeiten also nicht spekulativ.
Gut dran sind deshalb auch Freunde von Handys der Billig- und
gemässigten Mittelklasse. Die sind heute praktisch immer mit Cortex A53
bestückt. Also wer Futter braucht, um einen stolzen iPhone-Besitzer zu
ärgern ...
A. K. schrieb:> Gut dran sind deshalb auch Freunde von Handys der Billig- und> gemässigten Mittelklasse. Die sind heute praktisch immer mit Cortex A53> bestückt. Also wer Futter braucht, um einen stolzen iPhone-Besitzer zu> ärgern ...
Kennst du zufällig ein paar modelle?
Ich habe (nach meinem Beitrag... ) selbst mal die glaskugel angeworfen.
Clevere idee einen (ein Zyklus, ein Befehl) prozessor so zu nutzen.
Ich gebe zu, ich hab es erst halbwegs begriffen als ich diesen link
gefunden habe.
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
In allen fällen wird die ausgabe der 'pages' verhindert da die operation
so oder so ungültig ist... (?!) Also ich hoffe ich hab es grob
verstanden.
A. K. schrieb:> Ist nicht vollständig, weil einem Qualcomm die Arbeit erschwert.
Ja die Snapdragon sollen auch betroffen sein.
Vielen dank für die Links.
O.T
Mir kam gerade eine saublöde idee.
Aber ich versuch mal mein glück damit. ;)
Baum schrieb:>> Ist nicht vollständig, weil einem Qualcomm die Arbeit erschwert.>> Ja die Snapdragon sollen auch betroffen sein.
Qualcomm nennt alles Snapdragon, egal was drinsteckt. Das können auch
A53er sein, oder leicht veränderte Varianten davon. Bei den 8xx darf man
davon ausgehen, betroffen zu sein, während man bei den 4xx auf der
sicheren Seite sein sollte.
A. K. schrieb:> Baum schrieb:>> Kennst du zufällig ein paar modelle?>> Handys ab 2017 mit A53 drin:> https://www.heise.de/preisvergleich/?cat=umtsover&xf=3229_2017~5827_Cortex-A53>> Davon alle abziehen, die verschiedene Cores enthalten, z.B. 4xA53 und> 4xMongoose wie das S8. Diese anderen Cores sind dann dann spekulativ,> und nur bei ausreichend Last aktiv.
Oder alle mit https://en.wikipedia.org/wiki/MediaTek#Octa-_and_deca-core
außer Helio X. Nur sollte dazugesagt werden das wohl die meisten der
Handys mit so einem SoC nicht von LineageOS unterstützt werden (es gibt
aber einige auf Lineage-basierte Custom-ROMs). Zur Patchversorgung bei
Android: Kein Kommentar, da braucht's weder Meltdown noch Spectre
Arc N. schrieb:> . Zur Patchversorgung bei Android: Kein Kommentar, da braucht's weder> Meltdown noch SpectreSeuftz ... und noch schlimmer ist es wenn die leute tausende von
spielen installieren die zugriff auf alles haben was die kiste hergibt.
A. K. schrieb:> Qualcomm nennt alles Snapdragon, egal was drinsteckt. Das können auch> A53er sein, oder leicht veränderte Varianten davon. Bei den 8xx darf man> davon ausgehen, betroffen zu sein, während man bei den 4xx auf der> sicheren Seite sein sollte.
Ich muss mal schauen was on meinem J5 (Samsung) steckt... ich ahne aber
nichts gutes....
Baum schrieb:> Ich muss mal schauen was on meinem J5 (Samsung) steckt... ich ahne aber> nichts gutes....
Bei der J5-Serie? 2015/16/17 soweit ich sehe alles nur A53. Mehr hätte
mich in dieser Klasse auch gewundert.
Winfried J. schrieb:> Mal sehen was passiert.
Nix. A7 ist sauber. Also was das Thema angeht. Löcher hat das Handy
garantiert trotzdem, aber nicht diese.
A. K. schrieb:>>>> Bei der J5-Serie? 2015/16/17 soweit ich sehe alles nur A53. Mehr hätte> mich in dieser Klasse auch gewundert.
Stimmt. Naja für 200€ ... immerhin ist mein Telefon scheinbar nicht
betroffen.
Ja von 2017. :)
Tjaja die Sicherheitslücken. Da oute ich mich mal als "Schuster mit den
schlechtesten Schuhen" und teile mit das auf meinen Rechnern weder
updates noch Virenscanner aktiv sind.
Lediglich ein NAS internes hidden backup läuft da mit.
Bisher alles super. Das sagt nix aus, weiß ich selber.
Aber hier mal ein Beitrag abseits des hirnverblödenden Medienrummels:
...
Seite 11: "On such systems, an attacker can use Meltdown to dump the
entire physical memory, simply by reading from virtual addresses
starting at 0xffff 8800 0000 0000."
Alle existierenden PoCs, sowie meine Tests und auch Google kommen
allerdings zu einem anderen Ergebnis:
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.htmlhttp://blog.fefe.de/?ts=a4ad9f54
Achso, vielleicht trenne ich mal wieder internes Netz und Internet über
einen Rechner ohne Freigaben mit dem ich per mstsc im internet surfe.
Scheint mir sicher genug.
Jörg W. schrieb:> F. F. schrieb:>> Mein Gott, wie borniert du doch bist.>> Ähem, Foldi, das hat sich A.K. bestimmt nicht verdient. Er gehört> zu denen, die hier allemal am ausgewogensten daherkommen.
Nein, im weiteren Verlauf hat er das näher geschildert und deswegen,
mein lieber A.K., nehme ich das "borniert" auch gerne wieder zurück.
Ich hatte ganz vergessen, dass man hier immer sehr genau sein muss und
Mutmaßungen in einem Fachforum nicht unbedingt angebracht sind.
Danke Jörg, für den Hinweis!
Kaj G. schrieb:> Intel-Sicherheitslücke> Wichtiges Update könnte Millionen Computer extrem
Ob ein simples MS/Intel-Update überhaupt WIRKSAM genug ist, wenn das
Übel schon über das BIOS eingeschleppt werden könnte?
oszi40 schrieb:> Ob ein simples MS/Intel-Update überhaupt WIRKSAM genug ist, wenn das> Übel schon über das BIOS eingeschleppt werden könnte?
Meinst du mit "BIOS" Intels ME? Das sind zwei sehr verschiedene
Angriffs-Szenarien.
In ME kommst du über das lokale Netz rein. Sitzt zwischen den Angreifer
und dem Zielsystem eine entsprechend arbeitende Firewall, dann geht
nichts. Das ME Loch kann man stopfen, wenn der Hersteller des
Rechners/Mainboards das bietet.
Meltdown/Spectre setzt voraus, dass auf dem betreffenden Rechner
Schadcode läuft, der diese Lücken ausnutzt. Egal ob der selbst
installiert wurde, über Browser (JS) reinkam oder über Buffer Overflow.
Du kannst natürlich auch resignieren und von nun an konsequent darauf
verzichten, irgendwelche Löcher auch nur versuchen zu stopfen. Weils ja
doch immer wieder neue gibt. Das erspart dir manche Arbeit.
A. K. schrieb:> Meltdown/Spectre setzt voraus, dass auf dem betreffenden Rechner> Schadcode läuft, der diese Lücken ausnutzt. Egal ob der selbst> installiert wurde, über Browser (JS) reinkam oder über Buffer Overflow.
Achtung! Auf dem (virtualisierten) Rechner selbst muss nicht zwingend
der Schadcode laufen, es reicht wenn der auf einer anderen (virtuellen)
Maschine am selben Host läuft! Das ist ein kleiner, aber extrem
signifikanter Unterschied! (Gilt offensichtlich aber nur für Spectre)
Michael R. schrieb:> Achtung! Auf dem (virtualisierten) Rechner selbst muss nicht zwingend> der Schadcode laufen, es reicht wenn der auf einer anderen (virtuellen)> Maschine am selben Host läuft!
Wobei die Ausnutzung von Spectre über VM-Grenzen hinaus ein ziemlich
krasses Szenario ist. Aber ja, das ist richtig. Weshalb auch die
Virtualisierungsumgebung nicht verschont bleibt. Für die Spectre
Mitigations kamen gestern von VMware Patches raus, um die entsprechenden
Patches von Intel und Microsoft wirksam werden zu lassen.
> (Gilt offensichtlich aber nur für Spectre)
Für Meltdown reicht es aus, das Gastbetriebssystem mit KPTI zu fahren.
Ab VMware Gast-Hardware 11 und mindestens Westmere Prozessor gibts dann
auch PCID (process-context identifiers), d.h. die Performance-Einbusse
ist geringer.
A. K. schrieb:> Für die Spectre> Mitigations kamen gestern von VMware Patches raus, um die entsprechenden> Patches von Intel und Microsoft wirksam werden zu lassen.
Wobei:
> VMware vSphere 5.5: apply patch ESXi550-201709101-SG (this patch has> remediation against CVE-2017-5715 but not against CVE-2017-5753)
CVE-2017-5753 ist "Bounds-Check Bypass"
CVE-2017-5715 ist "Branch Target Injection"
A. K. schrieb:> Meinst du mit "BIOS" Intels ME? Das sind zwei sehr verschiedene> Angriffs-Szenarien.
Meine ich nicht. Wenn ich mal von der einfachen Annahme ausgehe, daß im
fest eingebrannten BIOS auf den Board schon spekulative CPU-Befehle
ausgeführt werden könnten, dann ist schon dort ein Loch im Zaun, was
eigentlich nur durch dem Mainboardhersteller gefixt werden könnte (da
ein Betriebssystem erst später läuft).
oszi40 schrieb:> Meine ich nicht. Wenn ich mal von der einfachen Annahme ausgehe, daß im> fest eingebrannten BIOS auf den Board schon spekulative CPU-Befehle> ausgeführt werden könnten, dann ist schon dort ein Loch im Zaun,
Nein. Die Prozessoren rechnen im Sinn der x86 Instruction Set
Architecture mit und ohne spekulativer OOO-Architektur exakt richtig.
Die Szenarien dieses Threads sind auf das BIOS nicht anwendbar.
Die Aufgabe des Bios im PC kann höchstens darin bestehen, aktuelle
Microcodeupdates in die CPU zu laden. Dazu muss man mal schauen, ob sich
bei den BIOS Updates für den eigenen Rechner was tut.
Matthias S. schrieb:> Die Aufgabe des Bios im PC kann höchstens darin bestehen, aktuelle> Microcodeupdates in die CPU zu laden. Dazu muss man mal schauen, ob sich> bei den BIOS Updates für den eigenen Rechner was tut.
Wobei mindestens Linux in der Lage ist, CPU-Microcode beim Start auch
selbst zu aktualisieren. Inwieweit das hier genutzt werden kann bleibt
abzuwarten.
die ganze Geschichte könnte eine schöne Neuaufbereitung der damaligen
Lisp-Maschinen sein
http://www.cse.unsw.edu.au/~chak/papers/PLKC08.html bzw.
http://www.cse.unsw.edu.au/~chak/papers/fsttcs2008.pdfhttps://de.wikipedia.org/wiki/Lisp-Maschine
"könnte" weil der ghc ja hauptsächlich mit C Grundlage daherkommt, der
gelinkte Artikel sich nicht wirklich mit Strategien rund um - und mit
Interlocks auf Hardwareebene beschäftigt, und der ghc selbst zumindest
zuletzt recht häufig abstruse fehlerhafte Ausgaben (Windows)
produzierte.
Als Programmierer kann man notfalls immer noch an einer der wenigen
Faustregeln halten, die da empfiehlt: nicht soviel bzw. ganz oft/viel
springen.
Da auch Artikel im Spiegel und in der NYT auftauchen fühlt man sich an
typische Agenda 10 Projekte mit Bürgermeisterfotos und Zeitungsartikeln
erinnert, die zwar nett in der Überschrift und schön nachzulesen sind,
aber schnell vergessen werden und die Projekte verstauben oder
verfallen.
(u.a. auch weil POC sch.. ist und (Dos-) .com Dateien angeblich nur 64k
groß sein dürfen (war wohl der RealMode für viele schon zu hoch?)).
Wie darf man sich die so schnellen Patches auf Softwareebene vorstellen,
wo doch das Hauptproblem recht tief in Hardware (+ Paralleltheorie usw.)
(ver-)steckt?
A. K. schrieb:> Wobei mindestens Linux in der Lage ist, CPU-Microcode beim Start auch> selbst zu aktualisieren. Inwieweit das hier genutzt werden kann bleibt> abzuwarten.
Einige Distributionen haben jetzt schon Kernel-Patches und installieren
auch gleich Microcode-Updates :)
Mampf F. schrieb:> und installieren> auch gleich Microcode-Updates :)
Den link auf die aktuellen Microcodes für Intel hatte ich oben ja mal
gepostet. Der kleine Server hier mit jessie und Atom 220 hat sie
jedenfalls erstmal geschluckt. Bei jessie selber hatte sich gestern auch
was getan.
Matthias S. schrieb:> Der kleine Server hier mit jessie und Atom 220 hat sie> jedenfalls erstmal geschluckt.
Einen Atom 220 gibts bei Intel m.W. nicht. Und ein Atom 230 braucht
keinen Fix, weil von den Problemen nicht betroffen. Alle Atoms vor dem
Silvermont Core arbeiten nicht-spekulativ.
A. K. schrieb:> Einen Atom 220 gibts bei Intel m.W. nicht.
Das Dings hier heisst wohl Celeron 220. Ich wollte da auch keinen Fix
reinpatchen, sondern den normalerweise brachliegenden Mechanismus für
Microcode ausprobieren. Das scheint zu klappen, aber man sollte es z.B.
in rc.local zünden.
A. K. schrieb:> F. F. schrieb:>> 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.>> Gibts zu dem Thema tatsächlich Radio mit Fachkenntnis?
Hast recht, eher nicht.
Von Spectre habe ich auch eher zufällig und erst vor kurzem gelesen.
Die letzte Zeit war ich selten hier und habe auch nur notwendige
Reparaturen gemacht und ansonsten habe ich mich in meinem Kummer und in
Trauer ertränkt.
rbx schrieb:> Wie darf man sich die so schnellen Patches auf Softwareebene vorstellen,> wo doch das Hauptproblem recht tief in Hardware (+ Paralleltheorie usw.)> (ver-)steckt?
Das Thema war über Monate unter Verschluss. Ganz so schnell ging das
also nicht, Intel hatte schon etwas Zeit.
An der grundlegenden Arbeitsweise kann nicht viel gedreht werden. Aber
erstens kann man versuchen, die konkreten Angriffe zu erschweren.
Zweitens gibt es mindestens bei Intel im Rahmen der Microcode Patches
neue Prozessorbefehle (und ein neues CPUID Bit), die dabei helfen
können, Programme gegen Spectre sicherer zu machen. Hab grad keine
Details.
So kann man neue Befehle einführen, oder bestehende ohnehin schon per
Microcode implementierte Befehle so erweitern, dass sie für Spekulation
an kritischer Stelle eine Barriere bilden. Das hilft bestehenden
Programmen nicht, lässt sich aber einbauen. Man könnte auch dafür
sorgen, dass zumindest in Kontextwechseln die Sprungvorhersage etwas auf
die Mütze kriegt, um Spectre über Threadgrenzen zu erschweren. Evtl.
lässt sich das auch in Browsern nutzen um getrennten Code auch wirklich
zu trennen. Bremst natürlich.
Programmiertechnisch kann man auch ohne Microcode Patches dagegen
angehen, indem man beispielsweise Bereichsüberprüfungen nicht per Sprung
erledig. Wenn man Bereiche per
if (index >= min && index <= max)
... = array[index];
else
panic();
absichert und das mit bedingten Sprüngen abwickelt, ist man der
Spekulation ausgeliefert. Ersetzt man das durch Code, der nicht springt,
sondern Daten abhängig von der Bereichsüberprüfung durchreicht, wie etwa
temp = (index >= min && index <= max) ? index : 0;
... = array[temp];
und dieser ?: Datenmultiplexer arbeitet rein über ALU-Operationen, dann
ist man sicher. Auch das ist natürlich etwas Arbeit.
Kaj G. schrieb:> Oder man laesst es einfach den Bootloader machen:> https://wiki.archlinux.org/index.php/Microcode#Installation
Ehrlich gesagt, klingt das viel komplizierter als die andere Methode,
die ich nach Intels Anleitung implementiert habe und für die Debian die
richtigen Mechanismen schon hat. Also Microcode Verzeichnis in
/lib/firmware kopieren und dann in der rc.local
'echo 1 > /sys/devices/system/cpu/microcode/reload'
Fertig.
Matthias S. schrieb:> Kaj G. schrieb:>> Oder man laesst es einfach den Bootloader machen:>> https://wiki.archlinux.org/index.php/Microcode#Installation>> Ehrlich gesagt, klingt das viel komplizierter als die andere Methode,> die ich nach Intels Anleitung implementiert habe und für die Debian die> richtigen Mechanismen schon hat. Also Microcode Verzeichnis in> /lib/firmware kopieren und dann in der rc.local> 'echo 1 > /sys/devices/system/cpu/microcode/reload'>> Fertig.
Ist der Microcode eigentlich persistent? Haben die ein Flash eingebaut?
Ist in den CPUs noch ein Controller eingebaut, der das Flash
aktualisiert? :)
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.
A. K. schrieb:> 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
Hmm schaut nicht so aus ... Hab gelesen, mit dem Microcode-Update für
Intel-CPUs würden auch noch 3 weitere neue Befehle dazu kommen.
Mampf F. schrieb:> Hmm schaut nicht so aus ... Hab gelesen, mit dem Microcode-Update für> Intel-CPUs würden auch noch 3 weitere neue Befehle dazu kommen.
Das ist kein Widerspruch.
Mampf F. schrieb:> Ist der Microcode eigentlich persistent?
Das Update ist es bei mir nicht. Auf meinem Desktop (AMD FX-8350) faellt
mir das aber nicht auf, weil:
1
For AMD processors the microcode updates are available in linux-firmware,
2
which is installed as part of the base system. No further action is needed.
[ 6.085810] microcode: CPU0: new patch_level=0x0600084f
12
[ 6.096507] microcode: CPU2: new patch_level=0x0600084f
13
[ 6.112628] microcode: CPU4: new patch_level=0x0600084f
14
[ 6.128558] microcode: CPU6: new patch_level=0x0600084f
sieht man, dass der Patch erst geladen wird. Der eigentliche Microcode
ist aber persistent.
Ich habe mein Notebook (Intel i7-irgendwas) vor ein paar Wochen neu
aufgesetzt, da musste ich das Microcodeupdate erst neu einrichten. Auch
dort ist das Update also nicht persistent.
Ist ja aber in 15 Sekunden fertig, also kein wirklicher aufwand.
https://wiki.archlinux.org/index.php/Microcode#Verifying_that_microcode_got_updated_on_bootMampf F. schrieb:> Haben die ein Flash eingebaut?
Natuerlich enthalten die CPUs auch speicher. Irgendwo muss ja das OS
(Minix/Linux) fuer die Intel ME liegen ;)
Ja, das liegt in der CPU.
Matthias S. schrieb:> Kaj G. schrieb:>> Oder man laesst es einfach den Bootloader machen:>> https://wiki.archlinux.org/index.php/Microcode#Installation>> Ehrlich gesagt, klingt das viel komplizierter als die andere Methode
Versteh ich nicht... Unter Arch muss ich lediglich
1
...installing the intel-ucode package...
also einmalig ein
1
pacman -S intel-ucode
machen und dann ein
1
grub-mkconfig -o /boot/grub/grub.cfg
ausfuehren. Fertig. Keine Ahnung was daran jetzt soooo kompliziert sein
soll. :-|
Und das betrifft auch nur Intel CPUs. Und abgesehen von diesem
einmaligen Schritt muss ich da nie wieder was machen. Microcodeupdates
kommen ab da ganz normal mit dem Systemupdate (mach ich jeden Tag) mit.
Wenn ich da also nicht aktiv drauf achte bekomme ich nicht mal mit, das
es ein Microcodeupdate gibt. Wird eingespielt und fertig. Will man kein
automatisches Update des Microcodes kann man das Paket einfach in die
pacman.conf eintragen. Dann wird das Paket vom Update ausgenommen und es
gibt eine Warnung, das es eine neue Version des Pakets gibt, dieses aber
nicht automatisch installiert wird.
Matthias S. schrieb:> Also Microcode Verzeichnis in /lib/firmware kopieren
Das entfaellt bei mir ja schon.
Matthias S. schrieb:> und dann in der rc.local> 'echo 1 > /sys/devices/system/cpu/microcode/reload'
Da fuehre ich lieber ein einziges mal grub-mkconfig aus.
Fuer mich klingt ja das eintragen in ein Scripte viel komplizierter und
vorallem fehleranfaelliger. :)
Ausserdem kommt das Script erst nach dem Bootloader. Ich befuerworte bei
dieser Sache dann doch eher das frueh moeglichste laden des Updates.
Und ich vertraue an der Stelle auch eher den Anleitungen meiner Distri,
als irgendwelchen Herstellern die, pauschal gesagt, womoeglich noch
nichtmal die Mechanismen meiner Distri ausreichend kennen.
Aber das ist am Ende ja geschmackssache, wie so vieles bei Linux :)
Lasst uns jetzt nicht streiten, was jetzt wirklich 'besser' oder
'schlechter' ist.
Kaj G. schrieb:> Natuerlich enthalten die CPUs auch speicher. Irgendwo muss ja das OS> (Minix/Linux) fuer die Intel ME liegen ;)
Code und Daten der ME liegen nicht in der CPU. Der Code liegt im
gleichen ROM wie das BIOS und die Daten liegen in einem reservierten und
für die x86 CPU geblockten Bereich vom DRAM.
Ursprünglich lag auch die ME-CPU extern, im Grafik/Memory-Hub. Nur ist
der mittlerweile Teil des Prozessorchips, also wohl auch die ME-CPU.
https://de.slideshare.net/codeblue_jp/igor-skochinsky-enpub
A. K. schrieb:> Kaj G. schrieb:>> Natuerlich enthalten die CPUs auch speicher. Irgendwo muss ja das OS>> (Minix/Linux) fuer die Intel ME liegen ;)>> Code und Daten der ME liegen nicht in der CPU. Der Code liegt im> gleichen ROM wie das BIOS und die Daten liegen in einem reservierten und> für die x86 CPU geblockten Bereich vom DRAM.
Ja, da hab ich mist geschrieben. Asche auf mein Haupt :(
Hier stehts ja auch:
https://www.heise.de/newsticker/meldung/Hacker-dringt-weiter-in-Intels-Management-Engine-vor-3884928.html
1
Er kündigte auf dem Open Source Summit beziehungsweise der
2
Linuxcon 2017 eine Non-Extensible Reduced Firmware (NERF)
3
als Kontrast zum Unified Extensible Firmware Interface (UEFI) an.
4
5
NERF ersetzt das komplette UEFI-BIOS inklusive der meisten
Kaj G. schrieb:> Ausserdem kommt das Script erst nach dem Bootloader. Ich befuerworte bei> dieser Sache dann doch eher das frueh moeglichste laden des Updates.
In dem Fall wäre der Weg über ein BIOS-Update der richtige. Dann ist da
alles schon erledigt, bevor grub oder sonstwas des OS überhaupt loslegt.
Oliver
A. K. schrieb:> erstens kann man versuchen, die konkreten Angriffe zu erschweren.> Zweitens gibt es mindestens bei Intel im Rahmen der Microcode Patches> neue Prozessorbefehle (und ein neues CPUID Bit), die dabei helfen> können, Programme gegen Spectre sicherer zu machen. Hab grad keine> Details.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.
Kaj G. schrieb:> NERF ersetzt das komplette UEFI-BIOS inklusive der meisten> ME-Funktionen durch einen Linux-Kernel.
Und wo liegt der Code dieses Linux? Auch im BIOS-ROM?
Oliver S. schrieb:> In dem Fall wäre der Weg über ein BIOS-Update der richtige.
Klar. Nur muss man erst einmal ein entsprechendes BIOS für ein nicht
mehr frisches Board kriegen.
A. K. schrieb:> Alles Humbug schrieb:>> https://www.amd.com/en/corporate/speculative-execution>> Es geht momentan wohl eher um das, was Intel tut. Wenn AMD nicht> betroffen ist, müssen sie auch nichts tun. Intel ist aber betroffen und> da wird etwas getan.
Ich weiß. Ich wollte ja nur mal dezent und in voller Hochachtung vor dem
Marktführer INTEL aufzeigen wie es aktuell um die AMD Prozzen steht bzw.
was AMD dazu so vermeldet.
Man könnte dazu natürlich auch einen neuen Thread aufmachen, aber wozu
eigentlich?
In deutsch steht's auch hier nochmals:
http://www.planet3dnow.de/cms/36069-amd-stellt-klar-ms-patch-nur-gegen-spectre-auf-amd-hardware/
Aber die Dinge können sich natürlich auch jederzeit ändern ..
A. K. schrieb:> Kaj G. schrieb:>> NERF ersetzt das komplette UEFI-BIOS inklusive der meisten>> ME-Funktionen durch einen Linux-Kernel.>> Und wo liegt der Code dieses Linux? Auch im BIOS-ROM?
So liest sich das fuer mich. In dem PDF gibt es mehr Informationen dazu,
wobei ich jetzt beim Ueberfliegen nicht gesehen habe, wo der Code
letztlich liegt. Interessant finde ich aber:
Kaj G. schrieb:>> Und wo liegt der Code dieses Linux? Auch im BIOS-ROM?> So liest sich das fuer mich.
Erinnert mich an Skylla vs Charybdis. Linux wird zwar sicherer sein als
Minix, aber auch Linux erwischt es immer wieder mal. Irgendwie finde ich
es doof, wenn ich mehrmals im Jahr bei jedem Rechner BIOS-Updates machen
muss. Die Hersteller vom BIOS finden das vermutlich auch.
A. K. schrieb:> Irgendwie finde ich> es doof, wenn ich mehrmals im Jahr bei jedem Rechner BIOS-Updates machen> muss. Die Hersteller vom BIOS finden das vermutlich auch.
Der Update-Spaß funktioniert nur WENN dafür noch ausreichend Speicher
verfügbar ist. Außerdem wäre noch zu untersuchen, wieviel faule Eier im
CMOS/EEPROMs versteckt sind. Mancher Virus/Kopierschutz hat das schon
ausgenutzt.
Kaj G. schrieb:> A. K. schrieb:>> Winfried, das ist was für dich. ;-)> Er koennte auch AMD nehmen>> AMD Secure Processor PSP wohl bei einigen Ryzen-Mainboards abschaltbar
Mal vorab als Info auch für Leute die sich nicht jeden Tag mit Innereien
auf dem Mainboard befassen:
Zitat sinngemäß:
"Intels Pendant zu AMDs Platform Security Processor PSP ist die Intel
Management Engine (IME) oder kurz ME, welche sich in den letzten Tagen
als Sicherheitslücke herausstellte."
http://www.pcgameshardware.de/AMD-Zen-Codename-261795/News/AMD-Platform-Security-Processor-per-BIOS-Update-deaktivierbar-1245467/
War es nicht so als dieses undurchsichtige Chip HW-BIOS-Addon mal
andedacht wurde, dass nach Abschaltung dessen geradezu geschrien wurde,
weil man dadurch zuviel Kontrolle von außen befürchtete? Und nun, da
der Kram sich auch per BIOS Schalter deaktivieren lässt, wird wieder das
schlimmste befürchtet?
https://www.heise.de/security/meldung/Intel-Management-Engine-ME-weitgehend-abschaltbar-3814631.html
Zitat:
"Russische Sicherheitsexperten haben große Teile des Codes von Intels
Management Engine ME 11 entschlüsselt und eine Möglichkeit gefunden,
wesentliche Teile abzuschalten.
Kurioserweise ermöglicht eine Funktion, die Intel eigens für den
US-Geheimdienst NSA in die ME-Firmware eingebaut hat, nun die
Abschaltung dieser viel kritisierten Management Engine (ME). Denn die
NSA selbst wünschte sich Intel-Computer ohne riskante Firmware, die
Hintertüren aufreißen könnte – etwa durch Sicherheitslücken."
Was will man denn nun? Eine Schnüffelschnittstelle mit BIOS
Abschaltmöglichkeit oder eine ohne?
Alles Humbug schrieb:> Was will man denn nun? Eine Schnüffelschnittstelle mit BIOS> Abschaltmöglichkeit oder eine ohne?
Die NSA will natürlich eine mit Abschaltmöglichkeit, nur sollte das
nicht jeder wissen. Damit man es zumindest in kritischen Rechnern
abschalten kann. Oder wenn es die "bösen Russen" irgendwann auszunutzen
wissen.
A. K. schrieb:> Erinnert mich an Skylla vs Charybdis. Linux wird zwar sicherer sein als> Minix, aber auch Linux erwischt es immer wieder mal.
Klar. Ich denke, das wird auch keiner abstreiten. Nicht mal Google. Das
trifft aber auf alle Betriebssysteme zu. Und da bin ich dann doch
"froh", wenn es ein Linux ist, das besser durchleuchtet ist, als
irgendein anderes OS, wie z.B. das Dingens das Samsung auf seinen
Geraeten einsetzt (Tizen), oder irgendwas anderes, das von den
Herstellern unter verschluss gehalten wird und man Luecken nur
aufwaendig per reverseengineering finden kann.
https://www.hackread.com/samsung-tizen-os-contains-tons-of-critical-security-flaws/
1
“Everything you can do wrong there, they do it. You can see that nobody
2
with any understanding of security looked at this code or wrote it. It’s
3
like taking an undergraduate and letting him program your software.”
Natuerlich, auch Linux ist voll mit Luecken. Aber an der Stelle haben
wir leider nur noch die Wahl zwischen Pest, Cholera und einem Pickel am
Hintern. Und da sehe ich Linux mehr als den Pickel am Hintern. Ist nicht
schoen, ist aber immernoch das kleinere Uebel.
Man kann von Google halten was man will, und auch ich bin kein Freund
von dieser Datenkrake. Trotzdem bin ich froh, das Google NERF ins leben
ruft. Denn so hat es erheblich hoeres Potenzial, als wenn es irgend
jemand in seiner Freizeit macht. Google hat einfach das Geld, das
Personal, das Know-How und auch ein eigenes, berechtigtes, interesse
diesen Rotz von Intel ME loszuwerden.
Mal abwarten was da noch kommt. :)
A. K. schrieb:> Irgendwie finde ich> es doof, wenn ich mehrmals im Jahr bei jedem Rechner BIOS-Updates machen> muss.
Ich sehe das tatsaechlich nicht sooo kritisch. Denn im Gegensatz zu
einem PC wird im BIOS ja nichts nachinstalliert -> Das System aendert
sich nicht. Man nimmt also einen Kernel X zum Zeitpunkt T und braucht
"nur noch" diesen pflegen. Man muss sich nicht um Luecken in Programmen
kuemmern. Die Anzahl an Luecken ist also (mehr oder minder) fest auf die
vorhandenen Luecken zum Zeitpunkt T beschraenkt. Es kommen keine Luecke
durch andere Programme hinzu. Natuerlich, wird eine Luecke gefunden und
gefixt, koennen sich dadurch, moeglicherweise, neue Luecken ergeben. Die
Anzahl der Luecken ist damit also relativ "ueberschaubar".
Nicht falsch verstehen:
Ich will hier nichts klein reden. Aber ich denke, dass es nicht wirklich
schlimmer wird, als es eh schon ist.
Alles Humbug schrieb:> Was will man denn nun? Eine Schnüffelschnittstelle mit BIOS> Abschaltmöglichkeit oder eine ohne?
Ich formuliere das mal so:
"Wir wollen eine Schnittstelle, mit der wir alles und jeden
ausschnueffeln koennen. Diese Schnittstelle muss aber bei unserer
Hardware abschaltbar sein, weil WIR wollen unter gar keinen Umstaenden
niemals nie nicht darueber ausschnueffelbar sein. Das waere ein viel zu
grosses Risikio fuer die nationale Sicherheit!!1elf"
Erinnert mich an eine Aussage eines deutschen Politikers (ich weiss
leider nicht mehr welcher Vollhorst das war... ist vielleicht auch
bessor so), als es um die VDS ging (sinngemaess):
"VDS und Massenueberwachung muss sein! Wir muessen alles und jeden,
immer und ueberall Ueberwachen! Terror, Kipo, etc. Aber Politiker muesse
davon ausgenommen werden! Das wuerde ja die Demokratie untergraben!"
Regeln die fuer alle gelten, ausser fuer einen selbst.
Alle sind gleich und manche sind gleicher...
Keine weiteren Fragen euer Ehren...
Kaj G. schrieb:> Besonders betroffen: SSD-Systeme.
Was nicht heisst, dass man mit HDDs besser dran wäre. Die
Transaktionsrate von SSDs ist auch hinterher viel höher als die von
HDDs. Es ist einfach so, dass es von der Anzahl System-APIs pro Sekunde
abhängt, wie stark ein System betroffen ist.
A. K. schrieb:> Kaj G. schrieb:>> Besonders betroffen: SSD-Systeme.>> Was nicht heisst, dass man mit HDDs besser dran wäre. Die> Transaktionsrate von SSDs ist auch hinterher viel höher als die von> HDDs.
Ich hab nie gesagt, das man SSDs jetzt wegschmeissen kann. Ich zitiere
nur die Artikel :)
Aus dem Artikel:
1
c't hat ebenfalls bereits starke Einbrüche bei der SSD-Leistung nach dem
2
Einspielen von BIOS- und Sicherheits-Updates feststellen können (Core
3
i7-8700K, Asus Maximus X Hero, Samsung 960 Pro). Die Samsung-SSD erreichte
4
nur noch 105.986 I/Ops beim Lesen und 79.313 I/Ops beim Schreiben im
5
Vergleich zu 197.525/185.620 I/OPs (vorheriges BIOS, Windows mit KB4054517).
6
Weitergehende Analysen, Benchmarks zu den Auswirkungen der Patches und
7
Untersuchungen der Updates finden Sie in der kommenden c't-Ausgabe 3/18.
Kaj G. schrieb:> Ich hab nie gesagt, das man SSDs jetzt wegschmeissen kann. Ich zitiere> nur die Artikel :)
Und ich habe nie angenommen, dass dir das nicht klar wäre. ;-)
Kaj G. schrieb:> "VDS und Massenueberwachung muss sein! .."> Keine weiteren Fragen euer Ehren...
Hohes Gerücht, sehr verkehrte Damen und Herren, Angesagter:
Geben Sie hier offen zu, sich der Mittäterschaft der allumfassenden
privaten Datenverschleuderung Schuldig gemacht zu haben, in dem Sie
tagtäglich ihr Leben, ihre Aktivitäten, ihre Vorlieben, ihr Bildmaterial
mit ihrem Smartphone in sog. sozialen Netzwerken verstreuten?
War Ihnen zu diesem Zeitpunkt denn nicht bewusst wie viele Dienste,
Geheimdienste, Werbefirmen, Versicherungen, Hacker und all die anderen,
die hier im Prozess aus Zeitgründen nicht genannt werden sollen, Sie
Teilnehmen ließen an ihrem Leben, an ihrem privatesten Aktivitäten?
Angesagter, gestehen Sie!
Alles Humbug schrieb:> Hohes Gerücht, sehr verkehrte Damen und Herren, Angesagter:> Geben Sie hier offen zu, sich der Mittäterschaft der allumfassenden> privaten Datenverschleuderung Schuldig gemacht zu haben, in dem Sie> tagtäglich ihr Leben, ihre Aktivitäten, ihre Vorlieben, ihr Bildmaterial> mit ihrem Smartphone in sog. sozialen Netzwerken verstreuten?>> War Ihnen zu diesem Zeitpunkt denn nicht bewusst wie viele Dienste,> Geheimdienste, Werbefirmen, Versicherungen, Hacker und all die anderen,> die hier im Prozess aus Zeitgründen nicht genannt werden sollen, Sie> Teilnehmen ließen an ihrem Leben, an ihrem privatesten Aktivitäten?>> Angesagter, gestehen Sie!
:)))
Einspruch, Euer Merkwürden!
Du passt in die Welt!
MfG Paul
Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von
diesem Problem betroffen ist? Sage jetzt aber niemand: "Auf der
Intel-Webseite" -da komme ich nämlich nach 1-stündiger Suche gerade her.
Die Windows 7-Updates sind fehlerfrei gelaugfen, wahrscheinlich, weil
ich vorsichtshalber noch einen Plattenabzug gemacht habe.
:)
MfG Paul
Paul B. schrieb:> Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von> diesem Problem betroffen ist?
Ich würde mich da zu einem Glas klarem JAIN hinreißen lassen.
The following Intel-based platforms are impacted by this issue. Intel
may modify this list at a later time.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr
"2nd generation Intel® Core™ processors"
https://de.wikipedia.org/wiki/Intel_Core_2
"Die Bezeichnung Intel Core 2 .. steht .. für die zweite Generation ..
nicht jedoch für die zweite Generation der Core-Mikroarchitektur, da der
Intel Core auf einer stark abgewandelten Version der P6-Architektur
basiert und daher lediglich einen Vorläufer der neuen Mikroarchitektur
darstellt."
Die Aufdröselung scheint dem geneigten (verunsicherten) Leser und
INTEL-Anwender im Kleingedruckten noch reichlich
Interpretationsspielraum zu belassen. Ungefähr ähnlich wie bei der
Einschätzung ob ein Gefährder nun wirklich zur Gefahr wird oder auch
nicht.
Gefährdungstechnisch ausgedrückt trägt deine CPU ein gewisses
Gefahrenpotential in sich und könnte somit mit zur Zielgruppe der
Auserwählten gehören.
Paul B. schrieb:> Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von> diesem Problem betroffen ist?
Liste von Intel:
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
Nachdem der aktuelle Firefox gepatched wurde, gibt es zum
Firefox 52 ESR auch was:
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
"Update [January 4, 2018]: We have released the two timing-related
mitigations described above with Firefox 57.0.4, Beta and Developers
Edition 58.0b14, and Nightly 59.0a1 dated “2018-01-04” and later.
Firefox 52 ESR does not support SharedArrayBuffer and is less at risk;
the performance.now() mitigations will be included in the regularly
scheduled Firefox 52.6 ESR release on January 23, 2018."
Der FF 52 ESR ist wohl aufgrund seiner relativen Lahmheit deutlich
weniger betroffen als sein schneller Nachfolger.
Alles Humbug schrieb:> Paul B. schrieb:>> Wo kann ich erfahren, ob der Prozessortyp "Core 2 Duo E8400" auch von>> diesem Problem betroffen ist?>> Ich würde mich da zu einem Glas klarem JAIN hinreißen lassen.
Danke für Deine Antwort.
Tja -dann mal abwarten.
Die Liste von A.K. hatte ich schon vorher gefunden -nur anfangen kann
ich damit nichts.
MfG Paul
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.
A. K. schrieb:> Kann ich nachvollziehen, die ist wirklich schwer zu interpretieren. Aber> dein Prozessor steht da tatsächlich nicht drauf.
Ja, danke. Die o.g. Bezeichnung habe ich mit dem Programm "Everest"
auslesen lassen, da geht eben die Nomenklatur von der Intel-Webseite
nicht
konform.
MfG Paul
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