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


von Kaj G. (Firma: RUB) (bloody)


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-prozessoren-sicherheitsluecke-koennte-pc-ausbremsen-a-1185969.html


The mysterious case of the Linux Page Table Isolation patches
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table


'Kernel memory leaking' Intel processor design flaw forces Linux, 
Windows redesign
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
1
...
2
Details of the vulnerability within Intel's silicon are under wraps: an 
3
embargo on the specifics is due to lift early this month, perhaps in time 
4
for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux 
5
kernel are available for all to see but comments in the source code have 
6
been redacted to obfuscate the issue.
7
8
However, some details of the flaw have surfaced, and so this is what we 
9
know.
10
11
12
Impact
13
14
It is understood the bug is present in modern Intel processors produced in 
15
the past decade. It allows normal user programs – from database 
16
applications to JavaScript in web browsers – to discern to some extent the 
17
layout or contents of protected kernel memory areas.
18
19
The fix is to separate the kernel's memory completely from user processes 
20
using what's called Kernel Page Table Isolation, or KPTI. At one point, 
21
Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, 
22
was mulled by the Linux kernel team, giving you an idea of how annoying 
23
this has been for the developers.
24
...

von sfgdgs (Gast)


Lesenswert?

Well Done! Intel hat es wieder mal geschafft.

von Peter D. (peda)


Lesenswert?

Kaj G. schrieb:
> Wichtiges Update könnte Millionen Computer extrem verlangsamen
> 
http://www.spiegel.de/netzwelt/gadgets/intel-prozessoren-sicherheitsluecke-koennte-pc-ausbremsen-a-1185969.html

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

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.
Da ist nix

von Markus M. (adrock)


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

von (prx) A. K. (prx)


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
von Kaj G. (Firma: RUB) (bloody)


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.

von Korax K. (korax)


Lesenswert?

Der Kunde ist immer der Dumme. Siehe VW.

von Bürovorsteher (Gast)


Lesenswert?

> Fefe steht früher auf.

covfefe?

von Joachim S. (oyo)


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-ceo-just-sold-a-lot-of-stock.aspx

von Sebastian V. (sebi_s)


Lesenswert?


von Thomas (Gast)


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.

von Sven D. (Gast)


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/windows-xp-end-of-support

von kr (Gast)


Lesenswert?

Thomas schrieb:
> "XP-Systemen" [...] "praktisch neuwertiges Notebook"

Finde den Fehler!

von (prx) A. K. (prx)


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
von (prx) A. K. (prx)


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.

von (prx) A. K. (prx)


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.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

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

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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 ?

von (prx) A. K. (prx)


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.

von (prx) A. K. (prx)


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
von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


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.

von Harkan der Dritte (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


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. ;-)

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Oder jemand hat eine backdoor offengelegt,welche jetzt kompromittiert 
ist?
Namaste

von (prx) A. K. (prx)


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.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

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

von (prx) A. K. (prx)


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
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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

von (prx) A. K. (prx)


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
von korax (Gast)


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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?

von Toxic (Gast)


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.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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?

von (prx) A. K. (prx)


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.

von (prx) A. K. (prx)


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.

von Ben W. (ben_w)


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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
von (prx) A. K. (prx)


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.

von (prx) A. K. (prx)


Lesenswert?


von guest (Gast)


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

von Kaj G. (Firma: RUB) (bloody)


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-langsamen-iPhones-Leistungsdrosselung-als-Feature-bei-schwachem-Akku-3925105.html

von Der Andere (Gast)


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"

von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


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?

von Kaj G. (Firma: RUB) (bloody)


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:
1
...the flaw is in the Intel x86-64 hardware...
2
3
...
4
5
However, it may be that the vulnerability in Intel's chips is worse than the
6
above mitigation bypass. In an email to the Linux kernel mailing list over 
7
Christmas, AMD said it is not affected. The wording of that message, though,
8
rather gives the game away as to what the underlying cockup is:
9
10
AMD processors are not subject to the types of attacks that the kernel page 
11
table isolation feature protects against. The AMD microarchitecture does not 
12
allow memory references, including speculative references, that access 
13
higher privileged data when running in a lesser privileged mode when that 
14
access would result in a page fault.
Kurz: Es sind ganzbesonders die 64 Bit Systeme betroffen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von (prx) A. K. (prx)


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?

von (prx) A. K. (prx)


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
von Clemens L. (c_l)


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

Wenn man
1. diesen Code mit a=42 und einem gültigen Zeiger ausführt, dann
2. alle Tabelleneinträge aus dem Cache schmeißt, und dann
3. "a" und den Zeiger ändert,
dann wird die Intel-CPU den Code spekulativ ausführen. Auch wenn die CPU 
dann die neuen Werte von b und c ignoriert, ist der entsprechende 
Tabelleneintrag trotzdem noch im Cache, was man messen kann.

> Das würde bedeuten, dass alle sicherheitsrelvanten Prozesse das Kernel
> exclusiv benötigen und am Ende alle Caches putzen müssen.

Nicht alle Caches; es genügt, die Page-Tabellen zu entfernen, so dass 
"b=*zeiger" überhaupt nicht mehr mit einer Kernel-Adresse ausgeführt 
werden kann.

von Joachim S. (oyo)


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.

von uwe (Gast)


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

von (prx) A. K. (prx)


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.

von (prx) A. K. (prx)


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.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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

von Mike B. (mike_b97) Benutzerseite


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

von meckerziege (Gast)


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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


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/Linux-Processor-Microcode-Data-File?v=t

Im TGZ sind Anleitungen und Dateien für alte Systeme (mit 
/dev/cpu/microcode Verzeichnis) und für neuere mit 
'/sys/devices/system/cpu/microcode/reload' Mechanismus.

Die Intel ME aber bleibt bestehen und ist vermutlich die 
undurchsichtigste Sicherheitslücke.

: Bearbeitet durch User
von (prx) A. K. (prx)


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
von Thomas (Gast)


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/windows-xp-end-of-support

Der Link lässt sich nicht öffnen.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


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
von (prx) A. K. (prx)


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.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

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

von Mike B. (mike_b97) Benutzerseite


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.

von Lars R. (lrs)


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.

von ;o) (Gast)


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"

von H.Joachim S. (crazyhorse)


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.

von Uhu U. (uhu)


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.

von Lars R. (lrs)


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.

von (prx) A. K. (prx)


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.

von ;o) (Gast)


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

von (prx) A. K. (prx)


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
von ;o) (Gast)


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.

von c.m. (Gast)


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?

von meckerziege (Gast)


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.

von Mike B. (mike_b97) Benutzerseite


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.

von (prx) A. K. (prx)


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. ;-)

von Marc H. (marchorby)


Lesenswert?

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

Nokia Lumia mit WindowsPhone

von Holm T. (Gast)


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

von (prx) A. K. (prx)


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.

von (prx) A. K. (prx)


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
von OS (Gast)


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.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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

von (prx) A. K. (prx)


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. ;-)

von Christian R. (supachris)


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

von (prx) A. K. (prx)


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
von Toxic (Gast)


Lesenswert?

c.m. schrieb:
> wer hat den bug eigentlich gefunden?

Keiner vom Forum soviel ich weiss.....

Beitrag #5265031 wurde vom Autor gelöscht.
von Rolf M. (rmagnus)


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.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Hier noch ein (sehr ausfuehrlicher) Beitrag von Googles Project Zero

Reading privileged memory with a side-channel
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
1
We have discovered that CPU data cache timing can be abused to efficiently 
2
leak information out of mis-speculated execution, leading to (at worst) 
3
arbitrary virtual memory read vulnerabilities across local security 
4
boundaries in various contexts.
5
6
Variants of this issue are known to affect many modern processors, 
7
including certain processors by Intel, AMD and ARM. For a few Intel and AMD 
8
CPU models, we have exploits that work against real software. We reported 
9
this issue to Intel, AMD and ARM on 2017-06-01 [1].
10
11
So far, there are three known variants of the issue:
12
13
    Variant 1: bounds check bypass (CVE-2017-5753)
14
    Variant 2: branch target injection (CVE-2017-5715)
15
    Variant 3: rogue data cache load (CVE-2017-5754)
16
17
18
Before the issues described here were publicly disclosed, Daniel Gruss, 
19
Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, 
20
Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also 
21
reported them;

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

von Sheeva P. (sheevaplug)


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?

von (prx) A. K. (prx)


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
von (prx) A. K. (prx)


Lesenswert?

Kaj G. schrieb:
> Und die Links zu den Artikeln der genannten Personen:

Danke.

: Bearbeitet durch User
von (prx) A. K. (prx)


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
von Javascript (Gast)


Angehängte Dateien:

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

von (prx) A. K. (prx)


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
von ;o) (Gast)


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.

von (prx) A. K. (prx)


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
von Lars R. (lrs)


Lesenswert?

Und python Scripte? Wahrscheinlich auch sehr schlimm, oder?

von (prx) A. K. (prx)


Lesenswert?

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

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


Lesenswert?

Wie in dem Project Zero Artikel schon angedeutet, auch AMD ist 
betroffen:
1
Variants of this issue are known to affect many modern processors, including 
2
certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU 
3
models, we have exploits that work against real software.
4
5
...
6
7
Tested Processors
8
9
Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document)
10
AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document)
11
AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document)
12
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-sicherheitsluecken-viele-stellungnahmen-windows-patch-amd-nicht-ganz-immun,3324252.html
1
AMD nicht ganz immun
2
3
Dagegen hat AMD zunächst eine Stellungnahme herausgegeben, in der es 
4
heißt, dass drei mögliche Angriffe identifiziert wurden, die von 
5
Hersteller zu Hersteller variieren und AMD sei für keinen davon anfällig.
6
Da die AMD-Architektur so unterschiedlich sei, geht AMD davon aktuell aus,
7
 dass das Risiko für AMD-Prozessoren »nahe Null« liegt. Doch inzwischen 
8
hat AMD die Aussage geändert. Eine Variante der Angriffe namens "Bounds 
9
Check Bypass" werde durch Updates behoben und es seien nur 
10
vernachlässigbare Einflüsse auf die Leistung zu erwarten. Bei der zweiten 
11
Variante sieht AMD nun ein Risiko "nahe Null" und es sei auch noch keine 
12
entsprechende Lücke auf AMD-Prozessoren nachgewiesen worden. Variante 3 
13
betreffe AMD-CPUs wegen der anderen Architektur nicht.


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

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-every-intel-chip-since-1995-arm-processors-vulnerable/

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

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
von (prx) A. K. (prx)


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
von Joachim S. (oyo)


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_vulnerability)#History)

Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem 
Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast 
gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen 
entdeckt wird?
Die einzige Erklärung, die mir auf Anhieb einfällt, ist, dass zu der 
Zeit mglw. bereits eine Schadsoftware im Umlauf war, die diese 
Sicherheitslücke ausgenutzt hat, und die dann fast gleichzeitig von 
mehreren Sicherheits-Teams untersucht wurde. Oder wie lässt sich das 
sonst erklären?

von (prx) A. K. (prx)


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-reading-kernel-memory-from-user-mode/

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Von VMware gibt es auch ein Statement:
https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

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

von Lars R. (lrs)


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.

von Hmm (Gast)


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?

von Lars R. (lrs)


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.

von Kaj G. (Firma: RUB) (bloody)


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
1
Daniel Gruss‏ @lavados
2
3
#FunFact: We submitted #KAISER to #bhusa17 and got it rejected.
4
We can just assume that it lacked practical relevance or had no
5
relevant security impact. #kpti #fuckwit #blackhat #bhusa
6
7
#KAISER is probably the most fundamental OS design change in many
8
years. Really enjoyed working on it with @mlqxyz @misc0110 Richard
9
Fellner @BloodyTangerine and Stefan Mangard + @anders_fogh when we
10
first proposed this technique in 2016.
11
#kpti #fuckwit
12
13
=================================
14
15
Stefano Zanero @raistolo
16
Antwort an @lavados
17
18
Daniel, setting aside that you are not listed as a speaker for that
19
submission, I just read it again, and frankly there was no way to guess
20
what you guys ACTUALLY had to present. Sorry, but next time give us some
21
more details to work on ;-)
22
--------------------------------
23
Daniel Gruss @lavados
24
Antwort an @raistolo
25
26
This is no complaint, it's a fun fact. We did not know of #meltdown back
27
then. But we thought #KAISER would be a good general improvement for
28
kernel security. A good defense mechanism covers yet unknown a attacks.
29
#KAISER did.
30
31
I'd bet the chances of the same talk with the same technical contribution
32
would have other chances now. Because now it's clear what it protects
33
against as well. That's a bit odd. And funny, therefore, fun fact ;)
34
--------------------------------
35
Stefano Zanero @raistolo
36
Antwort an @lavados
37
38
Fair. But we would probably have given the talk a chance even in August
39
if it was clearer what you had in your sleeves :)

von Kaj G. (Firma: RUB) (bloody)


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/important-information-regarding-the-windows-security-updates-released
1
Microsoft is only offering the Windows security updates released on January
2
3, 2018 to devices running anti-virus software from partners who have
3
confirmed their software is compatible with the January 2018 Windows
4
operating system security update.
5
6
Note:
7
Customers will not receive these security updates and will not be protected
8
from security vulnerabilities unless their anti-virus software vendor sets
9
the following registry key:
10
11
Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”

von (prx) A. K. (prx)


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
von Lars R. (lrs)


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?

von Lars R. (lrs)


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.

von (prx) A. K. (prx)


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.

???

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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
von Lars R. (lrs)


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.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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
von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

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

https://youtu.be/lR0nh-TdpVg

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.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Neue Sicherheitslücken - Chiphersteller arbeiten an Lösung
http://www.spiegel.de/netzwelt/netzpolitik/intel-arm-chip-hersteller-arbeiten-an-loesung-fuer-sicherheitsluecke-a-1186116.html
1
Der US-Chipkonzern Intel hat auf Berichte reagiert, wonach viele Millionen
2
Prozessoren weltweit anfällig für Angriffe sind. Die Attacken "Meltdown"
3
und "Spectre" betreffen noch weitere Hersteller.

von Lars R. (lrs)


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
von Kaj G. (Firma: RUB) (bloody)


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
1
Solution
2
3
Replace CPU hardware
4
5
The underlying vulnerability is primarily caused by CPU architecture
6
design choices. Fully removing the vulnerability requires replacing
7
vulnerable CPU hardware.

von Der Andere (Gast)


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.

von Joachim S. (oyo)


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-reading-kernel-memory-from-user-mode/

Danke, das ist in der Tat ebenfalls eine plausible Erklärung.
Wobei mir gerade nicht ganz klar ist, ob der verlinkte Artikel jetzt die 
"nicht fertig durcherforschte Idee" darstellen soll, oder ein Beispiel 
für einen "Habicht". :)

von (prx) A. K. (prx)


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.

von Lars R. (lrs)


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?

von (prx) A. K. (prx)


Lesenswert?

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

Das betrifft DRAMs, nicht CPUs (Rowhammer).

: Bearbeitet durch User
von Lars R. (lrs)


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.

von (prx) A. K. (prx)


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
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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

von Lars R. (lrs)


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
von (prx) A. K. (prx)


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
von Kaj G. (Firma: RUB) (bloody)


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:
1
Für Meltdown haben die Forscher der TU Graz bereits einen Patch, also
2
eine wirksame Gegenmaßnahme, entwickelt. Der so genannte KAISER-Patch
3
wurde bereits vor einiger Zeit gegen eine andere Art von Cyberangriff
4
entwickelt.
5
6
Zu dem Zeitpunkt war noch nicht klar, dass sämtliche Prozessoren von
7
AMD, ARM und Intel von einer Lücke betroffen sind, die mit einem
8
solchen Patch zu schließen ist.
9
10
Anfang Dezember 2017 merkten die Forscher, dass dieser KAISER-Patch
11
im Kernel von Linux-Betriebssystemen auftauchte. "Wir haben uns gedacht
12
'Da muss etwas Größeres dahinter sein' und haben das untersucht", meint
13
Gruss. Sein Team nahm mit Intel Kontakt auf und erfuhr, dass auch andere
14
IT-Sicherheitsexperten bereits aufmerksam geworden waren.
TU Graz hat zentrale Rolle im Kampf gegen Sicherheitslücke
https://futurezone.at/produkte/tu-graz-hat-zentrale-rolle-im-kampf-gegen-sicherheitsluecke/304.927.277

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

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


Lesenswert?

Windows Server Guidance to protect against the speculative execution 
side-channel vulnerabilities
https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution-s

Windows Client Guidance for IT Pros to protect against speculative 
execution side-channel vulnerabilities
https://support.microsoft.com/en-us/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe

von Arc N. (arc)


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/speculativeexecution 
(System Z, Power8 und Power9)

von Lars R. (lrs)


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
von Toxic (Gast)


Lesenswert?


von (prx) A. K. (prx)


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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

Der Preis. :-)

von Lars R. (lrs)


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.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

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

von (prx) A. K. (prx)


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
von (prx) A. K. (prx)


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.

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Auch Linus Torvalds hat was zu sagen :D

https://lkml.org/lkml/2018/1/3/797
1
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
2
> This is a fix for Variant 2 in
3
> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
4
>
5
> Any speculative indirect calls in the kernel can be tricked
6
> to execute any kernel code, which may allow side channel
7
> attacks that can leak arbitrary kernel data.
8
9
Why is this all done without any configuration options?
10
11
A *competent* CPU engineer would fix this by making sure speculation
12
doesn't happen across protection domains. Maybe even a L1 I$ that is
13
keyed by CPL.
14
15
I think somebody inside of Intel needs to really take a long hard look
16
at their CPU's, and actually admit that they have issues instead of
17
writing PR blurbs that say that everything works as designed.
18
19
.. and that really means that all these mitigation patches should be
20
written with "not all CPU's are crap" in mind.
21
22
Or is Intel basically saying "we are committed to selling you shit
23
forever and ever, and never fixing anything"?
24
25
Because if that's the case, maybe we should start looking towards the
26
ARM64 people more.
27
28
Please talk to management. Because I really see exactly two possibibilities:
29
30
 - Intel never intends to fix anything
31
32
OR
33
34
 - these workarounds should have a way to disable them.
35
36
Which of the two is it?
37
38
                   Linus

von (prx) A. K. (prx)


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.

von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


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

von Lars R. (lrs)


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
von (prx) A. K. (prx)


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?

von Lars R. (lrs)


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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?

von (prx) A. K. (prx)


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.

von (prx) A. K. (prx)


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.

von Lars R. (lrs)


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?

von (prx) A. K. (prx)


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

von Lars R. (lrs)


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?

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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

von (prx) A. K. (prx)


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.

von Lars R. (lrs)


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.

von (prx) A. K. (prx)


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.

von Lars R. (lrs)


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.

von (prx) A. K. (prx)


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
von Omi W. aus C. (Gast)


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.

von Lars R. (lrs)


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-matter-octa-always-better-quad

Etwas runter scrollen.

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


Lesenswert?


von Toxic (Gast)


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-meltdown-die-wichtigsten-antworten-zu-den-schwachstellen-in-prozessoren-a-1186193.html#ref=rss

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

:-)

von (prx) A. K. (prx)


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.
von Lars R. (lrs)


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.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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

von (prx) A. K. (prx)


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von Lars R. (lrs)


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.

von Mike B. (mike_b97) Benutzerseite


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

von herbert (Gast)


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.

von (prx) A. K. (prx)


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. ;-)

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

https://youtu.be/bReA1dvGJ6Y


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

Hmm, ziemlich viel Spekulatius …

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Ockham

Namaste

von Roland F. (rhf)


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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

von Arc N. (arc)


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

von (prx) A. K. (prx)


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
von Hans (Gast)


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

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?


von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Kaj G. schrieb:
> Spectre und Meltdown: All unsere moderne Technik ist kaputt
> 
https://www.golem.de/news/spectre-und-meltdown-all-unsere-moderne-technik-ist-kaputt-1801-131961.html

Viel Spass beim autonomen Fahren via Cloud.
Namaste

: Bearbeitet durch User
von herbert (Gast)


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.

von Paul B. (paul_baumann)


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

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

verschenke alle meine Bitcoin

Namaste

von (prx) A. K. (prx)


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
von F. F. (foldi)


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?

von (prx) A. K. (prx)


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
von Hans (Gast)


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

von (prx) A. K. (prx)


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
von W.S. (Gast)


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.

von FYI (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


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.

von F. F. (foldi)


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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.