mikrocontroller.net

Forum: PC Hard- und Software Schwere Sicherheitslücke in Intelprozessoren?


Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Mal sehen was da noch kommt...


Intel-Sicherheitslücke
Wichtiges Update könnte Millionen Computer extrem verlangsamen
http://www.spiegel.de/netzwelt/gadgets/intel-proze...


The mysterious case of the Linux Page Table Isolation patches
http://pythonsweetness.tumblr.com/post/16916698042...


'Kernel memory leaking' Intel processor design flaw forces Linux, 
Windows redesign
https://www.theregister.co.uk/2018/01/02/intel_cpu...
...
Details of the vulnerability within Intel's silicon are under wraps: an 
embargo on the specifics is due to lift early this month, perhaps in time 
for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux 
kernel are available for all to see but comments in the source code have 
been redacted to obfuscate the issue.

However, some details of the flaw have surfaced, and so this is what we 
know.


Impact

It is understood the bug is present in modern Intel processors produced in 
the past decade. It allows normal user programs – from database 
applications to JavaScript in web browsers – to discern to some extent the 
layout or contents of protected kernel memory areas.

The fix is to separate the kernel's memory completely from user processes 
using what's called Kernel Page Table Isolation, or KPTI. At one point, 
Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, 
was mulled by the Linux kernel team, giving you an idea of how annoying 
this has been for the developers.
...

Autor: sfgdgs (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Well Done! Intel hat es wieder mal geschafft.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
-17 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Wichtiges Update könnte Millionen Computer extrem verlangsamen
> 
http://www.spiegel.de/netzwelt/gadgets/intel-proze...

"Genaue Informationen zur Natur der Sicherheitslücke gibt es im Moment 
noch nicht."

Also alles nur heiße Luft. Schade um die mit Lesen vergeudete Zeit.

Autor: Joachim Drechsel (Firma: JDCC) (scheppertreiber)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.
Da ist nix

Autor: Markus M. (adrock)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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).

Autor: A. K. (prx)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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. ;-)

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Fra Nk (korax)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Der Kunde ist immer der Dumme. Siehe VW.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Fefe steht früher auf.

covfefe?

Autor: Joachim S. (oyo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-c...

Autor: Sebastian V. O. (sebi_s)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Joachim D. schrieb:
> Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.

https://www.heise.de/security/meldung/Massive-Luec...

Autor: Thomas (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Sven D. (sven_la)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Thomas schrieb:
> Ob es wohl auch einen Patch für Intel-Prozessoren in XP-Systemen geben
> wird?

https://support.microsoft.com/de-de/help/14223/win...

Autor: kr (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Thomas schrieb:
> "XP-Systemen" [...] "praktisch neuwertiges Notebook"

Finde den Fehler!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Kann es sein dass der high sierra bug auch schon darin seine Ursache 
hatte? Zeitlich käme das hin.
Namaste

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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 ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: ● J-A VdH ● (Firma: FULL PALATINSK) (desinfector) Benutzerseite
Datum:

Bewertung
-11 lesenswert
nicht lesenswert
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.

Autor: Harkan der Dritte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Beim 32MB Bug von AMDs K5 lief das etwas holpriger.
Was war das für ein bug?

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
● 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. ;-)

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder jemand hat eine backdoor offengelegt,welche jetzt kompromittiert 
ist?
Namaste

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
https://lkml.org/lkml/2017/10/31/884
KAISER will affect performance for anything that does system calls or
interrupts: everything.  Just the new instructions (CR3 manipulation)
add a few hundred cycles to a syscall or interrupt.  Most workloads
that we have run show single-digit regressions.  5% is a good round
number for what is typical.  The worst we have seen is a roughly 30%
regression on a loopback networking test that did a ton of syscalls
and context switches.  More details about possible performance
impacts are in the new Documentation/ file.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: korax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
● J-A V. schrieb:
> "Plötzlich" wollen die Hersteller ihre Geräte verlangsamen.
>
> erst der Apfel, jetzt Intel.

Wer hat denn beim Apfel was verlangsamt?

Autor: Toxic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> https://lkml.org/lkml/2017/10/31/884


-->> 38 files changed, 1565 insertions(+), 149 deletions(-)

na da war schon jemand gut beschäftigt scheint es?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ben W. (ben_w)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
>> Die Akku-Affäre.
>
> Sagt mir gerade nix.

https://www.heise.de/mac-and-i/meldung/Akkutausch-...

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> A. K. schrieb:
>>> Wer hat denn beim Apfel was verlangsamt?
>>
>> Die Akku-Affäre.
>
> Sagt mir gerade nix.

https://heise.de/-3931113

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> A. K. schrieb:
>>> Wer hat denn beim Apfel was verlangsamt?
>>
>> Die Akku-Affäre.
>
> Sagt mir gerade nix.
https://www.heise.de/mac-and-i/meldung/Apple-zu-la...

Autor: Der Andere (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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"

Autor: ● J-A VdH ● (Firma: FULL PALATINSK) (desinfector) Benutzerseite
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
Jörg W. schrieb:
> A. K. schrieb:
>>> Wer hat denn beim Apfel was verlangsamt?
>>
>> Die Akku-Affäre.
>
> Sagt mir gerade nix.

aller lebst Du hinterm Mond?

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
...the flaw is in the Intel x86-64 hardware...

...

However, it may be that the vulnerability in Intel's chips is worse than the
above mitigation bypass. In an email to the Linux kernel mailing list over 
Christmas, AMD said it is not affected. The wording of that message, though,
rather gives the game away as to what the underlying cockup is:

AMD processors are not subject to the types of attacks that the kernel page 
table isolation feature protects against. The AMD microarchitecture does not 
allow memory references, including speculative references, that access 
higher privileged data when running in a lesser privileged mode when that 
access would result in a page fault.
Kurz: Es sind ganzbesonders die 64 Bit Systeme betroffen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Clemens L. (c_l)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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):
if (a == 42) {
    b = *zeiger;
    c = tabelle[b];
}

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.

Autor: Joachim S. (oyo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mike B. (Firma: Buchhaltung+Controlling) (mike_b97) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
"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...

Autor: meckerziege (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Li...

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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

: Bearbeitet durch User
Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven D. schrieb:
> Thomas schrieb:
>> Ob es wohl auch einen Patch für Intel-Prozessoren in XP-Systemen geben
>> wird?
>
> https://support.microsoft.com/de-de/help/14223/win...

Der Link lässt sich nicht öffnen.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
:-)

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Similar operating systems, such as Apple's 64-bit macOS, will also need to
be updated – the flaw is in the Intel x86-64 hardware, and it appears a
microcode update can't address it.
Also nichts mit beheben durch Microcode.

Autor: Mike B. (Firma: Buchhaltung+Controlling) (mike_b97) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: ;o) (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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"

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ;o) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
;o) schrieb:
> Aber so ist das doch ein mieses Vorgehen

Immerhin gibts eine nette Entschuldigung:
https://www.apple.com/de/iphone-battery-and-performance/

: Bearbeitet durch User
Autor: ;o) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c.m. (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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?

Autor: meckerziege (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Mike B. (Firma: Buchhaltung+Controlling) (mike_b97) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Marc Horby (marchorby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Naja: im Thread nicht.  Oder kennst du ein Smartphone mit einem
> x86-Prozessor? ;-)

Nokia Lumia mit WindowsPhone

Autor: Holm Tiffe (holm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: OS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
@ 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Toxic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c.m. schrieb:
> wer hat den bug eigentlich gefunden?

Keiner vom Forum soviel ich weiss.....

Beitrag #5265031 wurde vom Autor gelöscht.
Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Hier noch ein (sehr ausfuehrlicher) Beitrag von Googles Project Zero

Reading privileged memory with a side-channel
https://googleprojectzero.blogspot.de/2018/01/read...
We have discovered that CPU data cache timing can be abused to efficiently 
leak information out of mis-speculated execution, leading to (at worst) 
arbitrary virtual memory read vulnerabilities across local security 
boundaries in various contexts.

Variants of this issue are known to affect many modern processors, 
including certain processors by Intel, AMD and ARM. For a few Intel and AMD 
CPU models, we have exploits that work against real software. We reported 
this issue to Intel, AMD and ARM on 2017-06-01 [1].

So far, there are three known variants of the issue:

    Variant 1: bounds check bypass (CVE-2017-5753)
    Variant 2: branch target injection (CVE-2017-5715)
    Variant 3: rogue data cache load (CVE-2017-5754)


Before the issues described here were publicly disclosed, Daniel Gruss, 
Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, 
Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also 
reported them;

Und die Links zu den Artikeln der genannten Personen:
https://spectreattack.com/spectre.pdf
https://meltdownattack.com/meltdown.pdf

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Und die Links zu den Artikeln der genannten Personen:

Danke.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
}

: Bearbeitet durch User
Autor: Javascript (Gast)
Datum:
Angehängte Dateien:

Bewertung
6 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: ;o) (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Redhat Enterprise Linux 7.4 auf ESXi,
der bereits beschrieben krasse Fall von "du":
bisher:         60ms real,  40ms sys
mit pti patch: 180ms real, 100ms sys

: Bearbeitet durch User
Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und python Scripte? Wahrscheinlich auch sehr schlimm, oder?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier nix Python, jedenfalls nicht von mir. Hängt unabhängig von der 
Sprache davon ab, wieviele Syscalls beteiligt sind.

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie in dem Project Zero Artikel schon angedeutet, auch AMD ist 
betroffen:
Variants of this issue are known to affect many modern processors, including 
certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU 
models, we have exploits that work against real software.

...

Tested Processors

Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document)
AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document)
AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document)
An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document)


Weitere Artikel dazu:


CPU-Sicherheitslücken - Stellungnahmen und Windows-Patch
http://www.gamestar.de/artikel/prozessor-sicherhei...
AMD nicht ganz immun

Dagegen hat AMD zunächst eine Stellungnahme herausgegeben, in der es 
heißt, dass drei mögliche Angriffe identifiziert wurden, die von 
Hersteller zu Hersteller variieren und AMD sei für keinen davon anfällig.
Da die AMD-Architektur so unterschiedlich sei, geht AMD davon aktuell aus,
 dass das Risiko für AMD-Prozessoren »nahe Null« liegt. Doch inzwischen 
hat AMD die Aussage geändert. Eine Variante der Angriffe namens "Bounds 
Check Bypass" werde durch Updates behoben und es seien nur 
vernachlässigbare Einflüsse auf die Leistung zu erwarten. Bei der zweiten 
Variante sieht AMD nun ein Risiko "nahe Null" und es sei auch noch keine 
entsprechende Lücke auf AMD-Prozessoren nachgewiesen worden. Variante 3 
betreffe AMD-CPUs wegen der anderen Architektur nicht.


Intel Responds to Security Research Findings
https://newsroom.intel.com/news/intel-responds-to-...

An Update on AMD Processor Security
https://www.amd.com/en/corporate/speculative-execution



Critical flaws revealed to affect most Intel chips since 1995
http://www.zdnet.com/article/security-flaws-affect...

Massive chip flaw not limited to Intel
https://www.axios.com/massive-chip-flaw-not-limite...

Degraded performance after forced reboot due to AWS instance maintenance
https://forums.aws.amazon.com/thread.jspa?threadID=269858


Ich lehne mich mal etwas aus dem Fenster und sage:
Die Kacke ist am dampfen... und zwar so richtig.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Joachim S. (oyo)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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_v...)

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?

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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-readi...

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von VMware gibt es auch ein Statement:
https://www.vmware.com/us/security/advisories/VMSA...

Allerdings geben die Beschreibungen zum jeweiligen Patchlevel nichts zum 
hier betrachteten Problem her.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hmm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Lars R. (lrs)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Daniel Gruss‏ @lavados

#FunFact: We submitted #KAISER to #bhusa17 and got it rejected.
We can just assume that it lacked practical relevance or had no
relevant security impact. #kpti #fuckwit #blackhat #bhusa

#KAISER is probably the most fundamental OS design change in many
years. Really enjoyed working on it with @mlqxyz @misc0110 Richard
Fellner @BloodyTangerine and Stefan Mangard + @anders_fogh when we
first proposed this technique in 2016.
#kpti #fuckwit

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

Stefano Zanero @raistolo
Antwort an @lavados

Daniel, setting aside that you are not listed as a speaker for that
submission, I just read it again, and frankly there was no way to guess
what you guys ACTUALLY had to present. Sorry, but next time give us some
more details to work on ;-)
--------------------------------
Daniel Gruss @lavados
Antwort an @raistolo

This is no complaint, it's a fun fact. We did not know of #meltdown back
then. But we thought #KAISER would be a good general improvement for
kernel security. A good defense mechanism covers yet unknown a attacks.
#KAISER did.

I'd bet the chances of the same talk with the same technical contribution
would have other chances now. Because now it's clear what it protects
against as well. That's a bit odd. And funny, therefore, fun fact ;)
--------------------------------
Stefano Zanero @raistolo
Antwort an @lavados

Fair. But we would probably have given the talk a chance even in August
if it was clearer what you had in your sleeves :)

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Eine Stellungnahme von Microsoft:

Important information regarding the Windows security updates released on 
January 3, 2018 and anti-virus software
https://support.microsoft.com/en-us/help/4072699/i...
Microsoft is only offering the Windows security updates released on January
3, 2018 to devices running anti-virus software from partners who have
confirmed their software is compatible with the January 2018 Windows
operating system security update.

Note:
Customers will not receive these security updates and will not be protected
from security vulnerabilities unless their anti-virus software vendor sets
the following registry key:

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”

Autor: A. K. (prx)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Lars R. (lrs)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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?

Autor: Lars R. (lrs)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

???

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Lars R. (lrs)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Beitrag #5265529 wurde von einem Moderator gelöscht.
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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 …

: Bearbeitet durch Moderator
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da sich hier ja der Ein oder Adnere fragt, wie sowas jahrelang 
unentdeckt bleiben konnte, hier mal ein Vortrag von der BlackHat 2015

Youtube-Video "The Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation"

A. 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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neue Sicherheitslücken - Chiphersteller arbeiten an Lösung
http://www.spiegel.de/netzwelt/netzpolitik/intel-a...
Der US-Chipkonzern Intel hat auf Berichte reagiert, wonach viele Millionen
Prozessoren weltweit anfällig für Angriffe sind. Die Attacken "Meltdown"
und "Spectre" betreffen noch weitere Hersteller.

Autor: Lars R. (lrs)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und hier noch was vom CERT:
Vulnerability Note VU#584653
CPU hardware vulnerable to side-channel attacks
http://www.kb.cert.org/vuls/id/584653
Solution

Replace CPU hardware

The underlying vulnerability is primarily caused by CPU architecture
design choices. Fully removing the vulnerability requires replacing
vulnerable CPU hardware.

Autor: Der Andere (Gast)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
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.

Autor: Joachim S. (oyo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-readi...

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". :)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lars R. schrieb:
> Bei Angriffen auf CPUs versucht man, Bits zu kippen.

Das betrifft DRAMs, nicht CPUs (Rowhammer).

: Bearbeitet durch User
Autor: Lars R. (lrs)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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

Autor: Lars R. (lrs)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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. ;-)

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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:
Für Meltdown haben die Forscher der TU Graz bereits einen Patch, also
eine wirksame Gegenmaßnahme, entwickelt. Der so genannte KAISER-Patch
wurde bereits vor einiger Zeit gegen eine andere Art von Cyberangriff
entwickelt.

Zu dem Zeitpunkt war noch nicht klar, dass sämtliche Prozessoren von
AMD, ARM und Intel von einer Lücke betroffen sind, die mit einem
solchen Patch zu schließen ist.

Anfang Dezember 2017 merkten die Forscher, dass dieser KAISER-Patch
im Kernel von Linux-Betriebssystemen auftauchte. "Wir haben uns gedacht
'Da muss etwas Größeres dahinter sein' und haben das untersucht", meint
Gruss. Sein Team nahm mit Intel Kontakt auf und erfuhr, dass auch andere
IT-Sicherheitsexperten bereits aufmerksam geworden waren.
TU Graz hat zentrale Rolle im Kampf gegen Sicherheitslücke
https://futurezone.at/produkte/tu-graz-hat-zentral...

Und so kommt es, das durch einen Patch ploetzlich viele Leute auf das 
Thema aufmerksam werden.

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Windows Server Guidance to protect against the speculative execution 
side-channel vulnerabilities
https://support.microsoft.com/en-us/help/4072698/w...

Windows Client Guidance for IT Pros to protect against speculative 
execution side-channel vulnerabilities
https://support.microsoft.com/en-us/help/4073119/w...

Autor: Arc Net (arc)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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... 
(System Z, Power8 und Power9)

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 im FPGA 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.

: Bearbeitet durch User
Autor: Toxic (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Lars R. schrieb:
> Nein. Eine von mehreren CPUs im FPGA 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?

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
8 lesenswert
nicht lesenswert
A. K. schrieb:
> Was unterscheidet dabei die FPGA-Lösung von einer Prozessorlösung?

Der Preis. :-)

Autor: Lars R. (lrs)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
A. K. schrieb:
> Lars R. schrieb:
>> Nein. Eine von mehreren CPUs im FPGA 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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc N. schrieb:
> Für Power ist die Lücke ebenfalls bestätigt worden:
> https://access.redhat.com/security/vulnerabilities...
> (System Z, Power8 und Power9)
Was ich hier interessant finde:
These include IBM System Z,  POWER8 (Big Endian and Little Endian),
and POWER9 (Little Endian).
Warum ist bei POWER9 nur Little Endian, bei POWER8 aber Big Endian und 
Little Endian betroffen?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Auch Linus Torvalds hat was zu sagen :D

https://lkml.org/lkml/2018/1/3/797
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
> This is a fix for Variant 2 in
> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ● J-A VdH ● (Firma: FULL PALATINSK) (desinfector) Benutzerseite
Datum:

Bewertung
-17 lesenswert
nicht lesenswert
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 :-)

Autor: Lars R. (lrs)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
● 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?

Autor: Lars R. (lrs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
7 lesenswert
nicht lesenswert
● 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?

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Lars R. (lrs)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Omi W. aus C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf den einschlägigen TV-Nachrichtenkanälen jagt schon ein News-Spezial 
das andere, zum Thema. Dort haben die "Experten" wieder allerhand zu 
tun.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Lars R. schrieb:
>> Ja. Aber: es gibt dort CPUs mit verschiedenen Cores.
>
> An welche dachtest du?

https://www.qualcomm.com/news/onq/2016/06/01/core-...

Etwas runter scrollen.

: Bearbeitet durch User
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Toxic (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Obiges Info nur fuer Windoofler(wie mich)- Profis bitte nur Heise 
lesen.....

:-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Beitrag #5265878 wurde von einem Moderator gelöscht.
Autor: Lars R. (lrs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mike B. (Firma: Buchhaltung+Controlling) (mike_b97) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: herbert (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Youtube-Video "Meltdown in Action: Dumping memory"


Jö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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.)

Beitrag #5265962 wurde vom Autor gelöscht.
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Winfried J. schrieb:
> High Sierra aber leise die eigentliche Lücke schließen sollte

Hmm, ziemlich viel Spekulatius …

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ockham

Namaste

Autor: Roland Franz (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Hans (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spectre und Meltdown: All unsere moderne Technik ist kaputt
https://www.golem.de/news/spectre-und-meltdown-all...

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Spectre und Meltdown: All unsere moderne Technik ist kaputt
> 
https://www.golem.de/news/spectre-und-meltdown-all...

Viel Spass beim autonomen Fahren via Cloud.
Namaste

: Bearbeitet durch User
Autor: herbert (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
verschenke alle meine Bitcoin

Namaste

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: F. Fo (foldi)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Hans (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: W.S. (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: FYI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauptsache Mr. Intel wird auf 'links' gezogen. Sein Aktien Deal ist ja 
die größte Frechheit als add on.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: F. Fo (foldi)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Michael Reinelt (fisa)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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?

Beitrag #5266513 wurde vom Autor gelöscht.
Autor: EinStudent (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wer es mal selbst ausprobieren möchte:

https://gist.github.com/ErikAugust/724d4a969fb2c6a...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael R. schrieb:
> Virtualisierung ist anfällig

Aus dieser Ecke fand bisher allenfalls heisse Luft. Hast du mehr dazu?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Beitrag #5266534 wurde vom Autor gelöscht.
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apple says Meltdown and Spectre flaws affect ‘all Mac systems and iOS 
devices,’ but not for long
https://techcrunch.com/2018/01/04/apple-says-meltd...

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Red Hat Security Advisory 2018-0013-01

The microcode_ctl packages provide microcode updates for Intel and AMD 
processors.
Security Fix: An industry-wide issue was found in the way many modern 
microprocessor designs have implemented speculative execution of 
instructions. There are three primary variants of the issue which differ in 
the way the speculative execution can be exploited. Variant CVE-2017-5715
triggers the speculative execution by utilizing branch target injection.

It relies on the presence of a precisely-defined instruction sequence in
the privileged code as well as the fact that memory accesses may cause 
allocation into the microprocessor's data cache even for speculatively 
executed instructions that never actually commit. As a result, an 
unprivileged attacker could use this flaw to cross the syscall and 
guest/host boundaries and read privileged memory by conducting targeted 
cache side-channel attacks. 

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Michael Reinelt (fisa)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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/r...

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?

Autor: herbert (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Sa Rox (sarox)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Reinelt (fisa)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Michael Reinelt (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Alles Humbug (Gast)
Datum:
Angehängte Dateien:

Bewertung
-3 lesenswert
nicht lesenswert
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).

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Alles Humbug (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> 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...

Ist vom seriösen Qualitätsjournalismus bereits angekündigt:

http://www.deutschlandfunk.de/sicherheitsluecken-i...

" .. Also, weitermachen, abwarten und hoffen - bis zum wirklichen Crash. 
Und der kommt - bei diesem Sicherheitsverständnis - todsicher."

Da hilft nur..

..warten auf den Untergang!

Autor: Sven D. (sven_la)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: F. Fo (foldi)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: F. Fo (foldi)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
13 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Alles Humbug (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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/46EE9...

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

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Whitepaper von ARM:
https://t.co/r6UCo3m0Cl
Introduction

This whitepaper looks at the susceptibility of Arm implementations
following recent research findings from security researchers at Google
on new potential cache timing side-channels exploiting processor
speculation. This paper also outlines possible mitigations that can be
employed for software designed to run on existing Arm processors.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
LLVM Weekly @llvmweekly

Patches posted for LLVM and Clang providing __builtin_load_no_speculate
and the llvm.nospeculateload intrinsic as a way of neutering potential
Spectre gadgets.
https://reviews.llvm.org/D41760
https://reviews.llvm.org/D41761

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Windows Meltdown patch: Find out if your PC is compatible

A list of which anti-virus products are incompatible with
the patch against the CPU flaws is now available.
https://www.techrepublic.com/article/windows-meltd...

Beitrag #5266965 wurde vom Autor gelöscht.
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal eine dumme Frage ... Wenn unter Linux der gesamte Physikalische 
Speicher ausgelesen werden kann, was bringt dann der KAISER-Patch 
überhaupt?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Mal eine dumme Frage ... Wenn unter Linux der gesamte Physikalische
> Speicher ausgelesen werden kann,

Wie? Also als normaler User.

: Bearbeitet durch User
Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spectre und Meltdown: 90 Prozent der aktuellen Intel-CPUs werden 
gepatcht
https://www.golem.de/news/spectre-und-meltdown-90-...