Naja, nur aus Spaß werden sie bei Linux die kernel space address space
separation ja wohl nicht einbauen, zumal wenn es mit einem
entsprechenden Performanceverlust verbunden ist.
Da scheint ja jemand was richtig verbockt zu haben. Wenn z.B. bei der
spekulativen Ausführung das Verstecken der Kerneldaten nicht richtig
implementiert ist, könnte man schon mit einem einfachen "cmp"
herausfinden ob an einer bestimmten Stelle etwas steht (gut, SO EINFACH
wird es wohl nicht sein).
Joachim D. schrieb:> Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.> Da ist *nix*
Da ist was. Es ist nicht normal, wenn in Linux signifikante
Kernel-Patches ohne grösseren Vorlauf kommentarlos hektisch eingebaut
und sogar backported werden. Und Microsoft rein zufällig in einer Woche
einen Komplett-Reboot von Azure angekündig hat.
Heises sind nicht immer die schnellsten. Fefe steht früher auf. ;-)
Wie sieht es in diesem Falle eigentlich mit der
Haftung/Gewaehrleistung/(was auch immer) aus? Ich stelle mir gerade vor,
wie tausende ThinkPad-Nutzer gerne Geld von Lenovo wieder haben
moechten, da dieser Bug einen erheblichen Produktmangel darstellt. Er
kann zwar gefixt werden, aber dann sinkt moeglicherweise die Leistung
des Systems um einen signifikanten Wert. Aufjedenfall ist der Kunde in
beiden Faellen (fixen: Leistungseinbussen, nicht fixen:
Sicherheitsluecke) der Dumme.
A. K. schrieb:> Heises sind nicht immer die schnellsten. Fefe steht früher auf. ;-)
...und was Fefe meldet, lässt in der Tat Übles vermuten:
> Wie schlimm ist dieser Intel-CPU-Bug?> Der CEO von Intel hat Ende November alle Aktien verkauft,> die er verkaufen durfte.> Ein Schelm, wer einen Zusammenhang vermutet!1!!> https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
Ob es wohl auch einen Patch für Intel-Prozessoren in XP-Systemen geben
wird? Bin da echt in Sorge soweit es mein praktisch neuwertiges Notebook
angeht.
Fra N. schrieb:> Der Kunde ist immer der Dumme. Siehe VW.
Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden
Prozessor ausgetauscht.
Beim 32MB Bug von AMDs K5 lief das etwas holpriger.
Joachim S. schrieb:>> Der CEO von Intel hat Ende November alle Aktien verkauft,>> die er verkaufen durfte.>> Ein Schelm, wer einen Zusammenhang vermutet!1!!
Das wäre dann allerdings Insider-Handel und könnte ihn ggf. sogar hinter
Gitter bringen.
Kaj G. schrieb:> Wie sieht es in diesem Falle eigentlich mit der> Haftung/Gewaehrleistung/(was auch immer) aus?
Also für diese Diskussion ists derzeit wirklich etwas zu früh.
Ich tippe mal auf die Möglichkeit des unatorisierten Zugriffs auf
Fremdpages des L2 Cache durch aktuelle Prozesse.
Das würde bedeuten, dass alle sicherheitsrelvanten Prozesse das Kernel
exclusiv benötigen und am Ende alle Caches putzen müssen.
Das sieht nach viel Arbeit und neuer HW aus.
wer weis mehr darüber ?
A. K. schrieb:> Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden> Prozessor ausgetauscht.
PS: Die waren allerdings noch mehr oder weniger in Produktion und quasi
innerhalb der Garantiefrist (wenn man das so sagen kann). Also selbst
wenn Intel die aktuellen Prozessoren austauschen sollte, wird das bei
einem alten Sandy Bridge wohl nicht mehr passieren.
Winfried J. schrieb:> Ich tippe mal auf die Möglichkeit des unatorisierten Zugriffs auf> Fremdpages des L2 Cache durch aktuelle Prozesse.
Da der Kernel-Patch mit Adressräumen zu tun hat, wird es kaum der
L2-Cache sein. I/D-Caches sind physikalisch getagged. Das läuft eher in
Richtung TLB.
Eine Ring-Transition (Kernel-API) hatte bisher keinen Adressraumwechsel
zur Folge. Und genau das ist der Fix: Beim Kernel-Aufruf wird nun der
Adressraum gewechselt und damit werden automatisch die TLBs geputzt.
In neueren Prozessoren gibt es eine Art Adressraum-ID, um TLB-Flushes
bei Prozessumschaltung zu reduzieren. Die rettet das ein wenig.
> Das sieht nach viel Arbeit und neuer HW aus. wer weis mehr darüber ?
Abwarten und Tee trinken.
das klingt nach Absprachen.
"Plötzlich" wollen die Hersteller ihre Geräte verlangsamen.
erst der Apfel, jetzt Intel.
Wer ist wohl als nächstes dabei?
wer sagt dass man den "Fehler" nicht von langer Hand einplanen kann,
damit nach einer gewissen Zeit
die Leute neue CPUs (bis ganze Rechner) kaufen?
dafür hats in jedwedem Bereich zuviel Schindludwer gegeben,
als dass man noch irgendwas glauben kann.
● J-A V. schrieb:> das klingt nach Absprachen.
Wo Menschen sind, sind Verschwörungstheorien nicht weit. ;-)
> "Plötzlich" wollen die Hersteller ihre Geräte verlangsamen.
Nicht alle. AMD vermeldet, ihre Prozessoren seien nicht betroffen.
Kleine Nebenwirkung dieser Meldung war das so unterfähr einzige
technische Detail, das überhaupt bekannt ist. Nämlich der Zusammenhang
mit spekulativer Ausführung.
Insofern wäre das ein feiner Zug von Intel. Also zum genau richtigen
Zeitpunkt AMDs Umsatz ankurbeln zu wollen. Wo die jetzt nach langer Zeit
endlich wieder CPUs haben, die sich lohnen. ;-)
Harkan der Dritte schrieb:> A. K. schrieb:>> Beim 32MB Bug von AMDs K5 lief das etwas holpriger.> Was war das für ein bug?
Beim branch target cache konnte es vorkommen, dass bei erkanntem self
modifying code Befehle doppelt ausgeführt wurden. Da die Erkennung davon
allerdings nur einen Teil der Adressbits nutzte, erwischte das auch ganz
normale Programme gelegentlich. Abhängig von der RAM-Grösse. Gemerkt
haben es die GCC-Übersetzer. Dar flog bei Systemen mit mindestens 32MB
RAM oft auf die Nase.
Winfried J. schrieb:> Oder jemand hat eine backdoor offengelegt,welche jetzt kompromittiert> ist?
Vorsatz zu vermuten ist unnötig. Prozessoren dieser Klasse sind
dermassen komplex, dass keiner der Prozessoren der letzten Jahrzehnte
fehlerfrei ist. Die meisten Fehler sind relativ harmlos, oder per
Microcode-Patch behebbar. Manche nicht.
A. K. schrieb:> Nämlich der Zusammenhang> mit spekulativer Ausführung.
Das kommt hin. Das war damals vor ca. zehn Jahren ein Hype um Intels
Leistungszuwachs.
Dumm gelaufen. Wenn es aber eine bekannte Bd war, hat sie sicher viel
gebracht für Informierte. Für Intel sicher ein netter Seiteneffekt
sollange nicht öffentlich.
Namaste
Winfried J. schrieb:> Das kommt hin. Das war damals vor ca. zehn Jahren ein Hype um Intels> Leistungszuwachs.
Spekulative Ausführung gibts bei Intel seit dem Pentium Pro 1995 (AMD:
K5 1996). Seither hat sich Stück für Stück das Ausmass der Spekulation
erweitert und vertieft.
A. K. schrieb:> Fra N. schrieb:>> Der Kunde ist immer der Dumme. Siehe VW.>> Beim Divisionfehler des Pentium 60 und 100 hatte Intel auf Anfrage jeden> Prozessor ausgetauscht.
Aber nur auf Druck. Für Ottonormalo wollten die auch nicht tauschen.
Joachim D. schrieb:> Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.> Da ist nix
Die Sicherheitluecke ist seit November bekannt und sie ist auch
dokumentiert.
Meine Dell-Lappies sind nicht betroffen - woher die Info? Nun zumindest
nicht von heise.de sondern von Intel und einer von Dell gefuehrten
Auflistung.
korax schrieb:> Aber nur auf Druck. Für Ottonormalo wollten die auch nicht tauschen.
Die wollten das auch nicht aufdecken. Errata waren damals
Firmengeheimnis. Bis dann jemand zufällig auf ein Zahlenpaar mit
Divisionfehler stiess, es in CompuServe rausblies. Von da aus landete es
im Usenet, wo ich drauf stiess und die Nacht über Zufallszahlen
dividierte. Damit war die Häufigkeit ungefähr abgeschätzt.
Seither sind Errata öffentlich. Die sind aber teils von der Kunst
geprägt, es so geschickt zu formulieren, dass es harmlos aussieht. AMD
hatte beim 32MB Bug nur den Zusammenhang mit self modifying code
erwähnt. Und wer macht das schon. Dass der auch dann erkannt wird, wenn
es keinen gibt, liessen sie wohlweisslich weg. Da kam dann erst in der
nächsten Ausgabe der Erratas.
Jörg W. schrieb:> Wer hat denn beim Apfel was verlangsamt?
Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte
Akkus nicht überfordert werden.
da es in den meisten berichten von x86 architektur die rede ist aber
nicht von amd64, bleibt die Hoffnung das erstmal nur 32bit systeme aber
nicht die 64 bit systeme von den performance verlusten betroffen sind.
A. K. schrieb:>> Wer hat denn beim Apfel was verlangsamt?>> Die Akku-Affäre.
Sagt mir gerade nix.
Ein auf einem 7 Jahre alten Laptop frisch installiertes High Sierra
lässt ihn geschwindigkeitsmäßig erscheinen wie am ersten Tag. Da habe
ich schon gestaunt, das schafft Windows gleich gar nicht, und auch die
meisten Linux-Distros nicht.
Ben W. schrieb:> da es in den meisten berichten von x86 architektur die rede ist aber> nicht von amd64, bleibt die Hoffnung das erstmal nur 32bit systeme aber> nicht die 64 bit systeme von den performance verlusten betroffen sind.
Mach dir keine Hoffnung. Das hat mit der Codierung der Befehle
sicherlich nichts zu tun. Die Page-Tables sind zwar auch verschieden,
aber nicht das spekulative Verhalten des Cores im Umgang damit.
Wenn man nicht ausdrücklich auf 32- vs 64-Bit rauswill, impliziert x86
das gesamte Spektrum.
Jörg W. schrieb:> Ein auf einem 7 Jahre alten Laptop
Es geht um Smartphones.
hast du die letzten 7 Tage keine News gelesen? :-)
Auch wenn ich Apple wegen der überteuerten Preise, der Arroganz und der
Steuervermeidung nicht leiden kann, aber das war eigentlich gut gemacht.
Besser man bremst Stromspitzen aus, als daß das gerät plötzlich abstürzt
wegen eines zu hohen Akkuinnenwiderstand.
Nur hätte man das rechtzeitig öffentlich machen sollan, aber man macht
halt lieber erst mal wieder auf "information hiding" und "Consumer is an
idiot anyway"
Ben W. schrieb:> da es in den meisten berichten von x86 architektur die rede ist aber> nicht von amd64, bleibt die Hoffnung das erstmal nur 32bit systeme aber> nicht die 64 bit systeme von den performance verlusten betroffen sind.
Aus dem Artikel von The Register:
1
...the flaw is in the Intel x86-64 hardware...
2
3
...
4
5
However, it may be that the vulnerability in Intel's chips is worse than the
6
above mitigation bypass. In an email to the Linux kernel mailing list over
7
Christmas, AMD said it is not affected. The wording of that message, though,
8
rather gives the game away as to what the underlying cockup is:
9
10
AMD processors are not subject to the types of attacks that the kernel page
11
table isolation feature protects against. The AMD microarchitecture does not
12
allow memory references, including speculative references, that access
13
higher privileged data when running in a lesser privileged mode when that
14
access would result in a page fault.
Kurz: Es sind ganzbesonders die 64 Bit Systeme betroffen.
Der Andere schrieb:>> Ein auf einem 7 Jahre alten Laptop>> Es geht um Smartphones.
Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem
x86-Prozessor? ;-) Daher wäre ich jetzt nicht auf die Idee gekommen,
dass jemand hier einen Smartphone-Bug für seine Verschwörungstheorien
heranzieht …
Das mit den iPhones hatte ich wirklich noch nicht gelesen, interessiert
mich aber auch nicht so brennend.
Kaj G. schrieb:> Kurz: Es sind ganzbesonders die 64 Bit Systeme betroffen.
Der Zusammenhang zwischen dem Bug und 64 Bits erschliesst sich mir
allenfalls insofern, als es sicherlich Altsysteme ohne diesen Bug gibt.
Aber wird man deshalb seinen alten Pentium 4 entstauben wollen?
Jörg W. schrieb:> Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem> x86-Prozessor? ;-)
Insbesondere Asus hatte einige Androids auf Atom-Basis. Da Android Apps
nur sehr selten nativen Code enthalten, sondern erst auf dem Gerät
selbst übersetzt werden, war das technisch kein Problem. Intel hat
allerdings aufgrund hartnäckiger Erfolglosigkeit den Markt wieder
aufgegeben.
Winfried J. schrieb:> wer weis mehr darüber ?
AMD erwähnt "speculative references, that access higher privileged data
when running in a lesser privileged mode when that access would result
in a page fault".
Also so etwas (stark vereinfacht):
1
if(a==42){
2
b=*zeiger;
3
c=tabelle[b];
4
}
Wenn man
1. diesen Code mit a=42 und einem gültigen Zeiger ausführt, dann
2. alle Tabelleneinträge aus dem Cache schmeißt, und dann
3. "a" und den Zeiger ändert,
dann wird die Intel-CPU den Code spekulativ ausführen. Auch wenn die CPU
dann die neuen Werte von b und c ignoriert, ist der entsprechende
Tabelleneintrag trotzdem noch im Cache, was man messen kann.
> Das würde bedeuten, dass alle sicherheitsrelvanten Prozesse das Kernel> exclusiv benötigen und am Ende alle Caches putzen müssen.
Nicht alle Caches; es genügt, die Page-Tabellen zu entfernen, so dass
"b=*zeiger" überhaupt nicht mehr mit einer Kernel-Adresse ausgeführt
werden kann.
Jörg W. schrieb:> Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem> x86-Prozessor? ;-)
In irgendeinem Artikel zu diesem Intel-Bug wurde am Ende kurz erwähnt,
dass für ARM64 derzeit offenbar ganz ähnliche massive Patches
vorbereitet werden.
Ich weiss leider gerade nicht mehr, wo genau ich das gelesen habe, aber
auch einer der im OP verlinkten Artikel erwähnt bspw. am Ende:
> PS: It appears 64-bit ARM Linux kernels will also get a set of> KAISER patches, completely splitting the kernel and user spaces,> to block attempts to defeat KASLR. We'll be following up this week.
Also ich habe das so verstanden:
Die Intel CPUs führen Code schon vorher (spekulativ) aus, der COde wird
von der Spekulativer Verzweigungs Entscheidungs Einheit vorhergesagt und
wird im Voraus im Übersetzungs Vorhersage Puffer (TLB) schon in
ausführbare Micro Instruktionen übersetzt.
Der Fehler ist, daß bei diesem Prozess nicht vorher das Privilegien
Level geprüft wird.
Später wird natürlich festgestellt, daß das Privilegien Level nicht
ausreich und der Puffer wird nicht ausgeführt, wenn jedoch dieser
Prüfbefehl übergangen werden kann wird der Puffer fälschlicherweise
augeführt.
Wie der Prüfbefehl übergangen werden kann hab ich mich jetzt nicht
weiter beschäftigt...
Joachim S. schrieb:> In irgendeinem Artikel zu diesem Intel-Bug wurde am Ende kurz erwähnt,> dass für ARM64 derzeit offenbar ganz ähnliche massive Patches> vorbereitet werden.
Man scheint gleich zwei Probleme mit der Adressraumtrennung erschlagen
zu wollen. Eines davon ist der bereits erwähnte Bug bei Intel. Das
andere Problem ist den spärlichen Informationen zufolge eher
prinzipieller Natur und betrifft so ziemlich alles, was Pagetables
verwendet.
uwe schrieb:> wird im Voraus im Übersetzungs Vorhersage Puffer (TLB) schon in> ausführbare Micro Instruktionen übersetzt.
Der TLB übersetzt lediglich lineare in physikalische Adressen. Mit
Befehlen hat er nichts zu tun.
Clemens L. schrieb:> Nicht alle Caches; es genügt, die Page-Tabellen zu entfernen, so dass> "b=*zeiger" überhaupt nicht mehr mit einer Kernel-Adresse ausgeführt> werden kann.
Danke, so tief bin ich zuvor nicht eingetaucht. Seit den 586 bin ich
froh das Prinzip hinter den Neuerungen zu kennen, aber ich bin auch nur
User solcher Technologie.
Namaste
"sind mehr oder weniger alle im letzten Jahrzehnt ausgelieferten
Intel-Prozessoren von einem Problem getroffen, das die von ihnen
angetriebenen Computer angreifbar macht"
muahaha, Nachtigall ick hör dir trapsen
Das is wahrscheinlich eine/die absichtlich in Absprache mit dem
NSA/FBI/CIA eingebaute backdoor, wo bisher deren Schnüffel-Programme
drüber Zugriff auf die Rechner hatten.
Entweder hats jetzt einer verraten oder diese backdoor wurde durch was
moderneres ersetzt und wird nicht mehr gebraucht/benutzt.
Evtl. hab ich aber auch nur zuviel Tom Clancy gelesen...
Mike B. schrieb:> Das is wahrscheinlich eine/die absichtlich in Absprache mit dem> NSA/FBI/CIA eingebaute backdoor, wo bisher deren Schnüffel-Programme> drüber Zugriff auf die Rechner hatten.
Das als "wahrscheinlich" zu betrachten ist doch eher eine
Verschwörungstheorie. Gerade sieht es danach aus, als bräuchte man schon
mindestens Userspace-Zugriff um in die Kernelebene vorzudringen.
> Entweder hats jetzt einer verraten oder diese backdoor wurde durch was> moderneres ersetzt und wird nicht mehr gebraucht/benutzt.
Es gibt genügend Leute die gezielt nach so etwas suchen und dann
veröffentlichen werden. Also ist auch hier keine Verschwörungstheorie
angebracht.
Leider sind noch zu wenig Details bekannt um wirklich abschließend etwas
aussagen zu können. Diese Systeme sind hoch komplex. Da kommt es schon
mal vor, dass Implementierungsfehler gemacht werden.
Da Linux einen Update Mechanismus für Microcode besitzt, kann man,
sobald ein Patch bereitsteht, sein System damit updaten, sofern sich der
Bug überhaupt mit Microcode behandeln lässt:
https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t
Im TGZ sind Anleitungen und Dateien für alte Systeme (mit
/dev/cpu/microcode Verzeichnis) und für neuere mit
'/sys/devices/system/cpu/microcode/reload' Mechanismus.
Die Intel ME aber bleibt bestehen und ist vermutlich die
undurchsichtigste Sicherheitslücke.
Matthias S. schrieb:> sofern sich der Bug überhaupt mit Microcode behandeln lässt:
In diesem Fall ist das ziemlich unwahrscheinlich. Per Microcode lassen
sich komplexe Befehle reparieren und fehlerhafte Befehlsgruppen und
Beschleunigungsoptionen abschalten. Aber das grundsätzliche Verhalten
des OOO-Cores im Umgang mit Mikro-Ops wird damit kaum reparabel sein.
Zudem wär dann keine Hektik bei den Kernelbauern, sondern bei den
PC-Herstellern (wie etwa bei ME).
A. K. schrieb:> In diesem Fall ist das ziemlich unwahrscheinlich.
Ich habs jetzt trotzdem mal auf meine Box gespült, die gerade von wheezy
auf jessie hochgepeitscht wurde und schau dann ab und zu mal bei Intel
vorbei. Mal sehen, ob sich da in nächster Zeit was tut - der letzte
Update bei denen war vom 17. November 2017.
Thomas schrieb:> Der Link lässt sich nicht öffnen.
Da steht auch nur, das der Support von XP eingestellt wurde - hast nix
versäumt. Die absolut letzte Tat war das Wegpatchen der 'WannaCry'
Verletzlichkeit im Frühjahr.
Der Spass beim o.a. MS Link ist ja der Untertitel:
> Gilt für: Windows 10
:-)
A. K. schrieb:> Harkan der Dritte schrieb:>> A. K. schrieb:>>> Beim 32MB Bug von AMDs K5 lief das etwas holpriger.>> Was war das für ein bug?>> Beim branch target cache konnte es vorkommen, dass bei erkanntem self> modifying code Befehle doppelt ausgeführt wurden.
PS: Es war der K6, nicht der K5.
meckerziege schrieb:> Mike B. schrieb:>> Das is wahrscheinlich eine/die absichtlich in Absprache mit dem>> NSA/FBI/CIA eingebaute backdoor, wo bisher deren Schnüffel-Programme>> drüber Zugriff auf die Rechner hatten.> Das als "wahrscheinlich" zu betrachten ist doch eher eine> Verschwörungstheorie. Gerade sieht es danach aus, als bräuchte man schon> mindestens Userspace-Zugriff um in die Kernelebene vorzudringen.
"Was der Bauer nicht kennt, das gibt es auch nicht!"
und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung
die Wahrscheinlichkeit dass es solche backdoors gibt ist mindestens
genauso hoch wie die, das wir davon nix wissen.
Aus der Erkenntnis, dass zumindest die Russen und wahrscheinlich auch
die Chinesen eigene Chips und nicht INTEL in ihre Militärtechnik
einbauen, lassen sich evtl. doch gewisse Erkenntnisse derer
Entwicklungsabteilungen über die Intel-Chips ableiten.
Die Lösung ist, eine Abstraktionsebene hinzuzufügen. Die gibt sogar
bereits: FPGAs. Mit Softcores (beispielsweise RISC-V) auf FPGAs wird so
etwas beliebig schwierig. Denn die tatsächliche HW (beim FPGA die
SRAM-Zellen, die die Konfig halten), "verstehen" das Design nicht und
ein tatsächliches Flipflop des RISC-V kann nahezu beliebig im
FPGA-Fabric platziert werden.
Da gibts aber 3 Probleme:
1.: Viel teurer als die "harte Lösung"
2.: Energiehungriger als die "harte lösung"
3.: Braucht wesentlich mehr Silizium-Platz als die "harte Lösung"
Dem Aktienkurs von AMD scheint die Sache ganz gut zu bekommen.
Intel schien ja den Kampf um die lieben kleinen Prozessoren gewonnen zu
haben, aber AMD hat voriges Jahr doch wieder Bewegung reingebracht. Und
das hier dürfte gut für den Wettbewerb sein. Keine schöne Vorstellung,
wenn eine einzige Firma 90% des Marktes beherrscht.
A. K. schrieb:> Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte> Akkus nicht überfordert werden.
Was ja durchaus vernünftig ist... Hat aber einige Idioten nicht daran
gehindert, im Land der unbegrenzten Unmöglichkeiten gleich deswegen
gegen Appel zu klagen. Man darf gespannt sein, was dabei heraus kommt.
1., 2., 3. sind jeweils nur relativ. Zudem ergäben sich Vorteile durch
mehr Heterogenität. Eine Stelle, die Sound verarbeitet, muss nicht auch
Grafik verarbeiten können. Lediglich die "harte Lösung" erzwingt
derartige Universalität, auch aufgrund fehlender
Veränderbarkeit/Anpassbarkeit.
Uhu U. schrieb:> Man darf gespannt sein, was dabei heraus kommt.
Längst bekannt: Neue Akkus zum Spottpreis (für die Verhältnisse von
Apple). Bei den 6ern war der Akku noch einigermassen selbst tauschbar,
aber danach nicht mehr. Einziger Haken: Man lebt einige Tage ohne
iPhone, also vielleicht künstliches Koma oder so.
Wenn Bescheid gegeben worden währe das gedrosselt wird und wie es
behoben werden kann währe es schon in Ordnung gewesen.
Aber so ist das doch ein mieses Vorgehen
Das ist doch nur das übliche Marketing Blabla.
Wenn Batterien Verschleißteile sind.
Warum wird dann nicht gesagt wenn sie hinüber sind?
Warum ermöglicht man nicht das Tauschen?
So sagt man nur das Apple Geräte als ganzes Verschleißteile sind.
War da nicht eine Aussage von Apple bei einer Gerichtsverhandlung das
ihre Geräte nur für eine Lebensdauer von einem Jahr ausgelegt sind und
das der Kunde das auch von ihnen erwartet?
Und lese ich da richtig aus dem Text heraus das Apple auch bei den neuen
Geräten anstatt ordentlich dimensionierter Akkus lieber Schrott verbaut
und weiterhin fröhlich drosseln wird.
Der Lipo in meinem Nokia 3510 Monochrom Arbeits-Handy ist jetzt nach
über 10 Jahren noch einigermaßen fitt und hat eine längere Laufzeit als
ein neues Wischerhandy.
mich stört, dass der bug 10 jahre lang unentdeckt und damit ungepatcht
blieb.
einerseits. andererseits stützt das meine these, dass entwickler (egal
ob soft- oder hardware) ab einer bestimmten komplexität keinen überblick
mehr haben was die frameworks die sie benutzen eigentlich genau
machen.
das verhalten der verbuggten CPU's ist nicht nur den intel entwicklern
bei verschiedenen CPU versionen 10 jahre lang nicht aufgefallen, sondern
auch den kernelentwicklern von windows, linux...
wer hat den bug eigentlich gefunden?
Mike B. schrieb:> "Was der Bauer nicht kennt, das gibt es auch nicht!"> und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung
Erstens kann ich als nicht-angemeldeter Benutzer gar nicht bewerten...
Zweitens ist mir die Hardwaresicherheit nicht gerade fremd, da ich
selbst schon Schwachstellen in ICs aufgedeckt und darüber publiziert
habe. Damit sollte sich die Frage erübrigen, wer hier "der Bauer" ist
;-)
Es ist sehr schwierig, wenn nicht unmöglich, Hardware auf 100% zu
testen. Besonders Grenzfälle mit sehr knappem Timing führen immer mal
wieder zu Fehlern.
Schau einfach mal in die Errata von aktuellen Mikrocontrollern, das ist
oft überraschend viel.
> die Wahrscheinlichkeit dass es solche backdoors gibt ist mindestens> genauso hoch wie die, das wir davon nix wissen.
Wenn du dir Sorgen machen willst, dann schau dir die Intel Management
Engine an.
Einen Bug in Hardware fest einzubauen, mit dem vom Userspace Zugriff auf
den Kernelspace erlaubt wird, ist auch gar nicht notwendig => siehe
Intel ME. Ähnliches könnte man übrigens auch mit Microcode-Schadcode
erreichen.
> Aus der Erkenntnis, dass zumindest die Russen und wahrscheinlich auch> die Chinesen eigene Chips und nicht INTEL in ihre Militärtechnik> einbauen, lassen sich evtl. doch gewisse Erkenntnisse derer> Entwicklungsabteilungen über die Intel-Chips ableiten.
Militärtechnik ist nochmal ein ganz anderes Gebiet, da spielen viel mehr
Faktoren mit rein. Abhängigkeit von externen Lieferanten, spezifizierter
Temperaturbereich, Zuverlässigkeit, Fehlertoleranz,
Strahlungsempfindlichkeit, etc. => Sehr vieles was für den normalen
CPU-User gar nicht relevant ist.
meckerziege schrieb:> Mike B. schrieb:>> "Was der Bauer nicht kennt, das gibt es auch nicht!">> und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung>> Erstens kann ich als nicht-angemeldeter Benutzer gar nicht bewerten...
Ich meinte auch nicht dich persönlich, da ich eben nicht weiss von wem
die -1 kam. Es war allgemein an unbekannt adressiert.
c.m. schrieb:> mich stört, dass der bug 10 jahre lang unentdeckt und damit ungepatcht> blieb.
Der Bug wird bei korrekten Programmen nicht zu Fehlverhalten führen.
Sondern es ermöglichen, auf mehr der weniger komplizierte Art an
verborgene Informationen heranzukommen. Vor 10 Jahren gab es deutlich
weniger Leute, die ihre ganze Energie darauf konzentrieren, genau danach
zu suchen.
Im Zusammenhang mit den Kernel Patches wird ASLR erwähnt. Das ist eine
Massnahme, die Buffer Overflows schwerer ausnutzbar macht. So arg alt
ist die jedoch noch nicht. Erst "Seit Kernelversion 3.14 gibt es eine
vollständige Implementierung von ASLR. Ab Version 4.8 kollidiert die
Kernel Address Space Layout Randomization (KASLR) nicht mehr mit der
Hibernate-Funktion." (Wikipedia)
> wer hat den bug eigentlich gefunden?
Geduld ist eine seltene Tugend. ;-)
Uhu U. schrieb:> A. K. schrieb:>> Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte>> Akkus nicht überfordert werden.>> Was ja durchaus vernünftig ist... Hat aber einige Idioten nicht daran> gehindert, im Land der unbegrenzten Unmöglichkeiten gleich deswegen> gegen Appel zu klagen. Man darf gespannt sein, was dabei heraus kommt.
Ja, es ist vernünftig, unvernünftig und Ursache der Klagen ist das Apple
das nicht kommuniziert hat und den Akku auch fest eingebaut hat.
Gruß,
Holm
Mike B. schrieb:> "Was der Bauer nicht kennt, das gibt es auch nicht!"> und deswegen bekommt der Aluhut-Träger gleichmal 'ne negative Bewertung
Auch wenn wir in einer Zeit leben, in der paranoides Denken in
unangenehm hohem Umfang gerechtfertigt ist: Die meisten Fehler in
Produkten sind immer noch einfach nur Fehler. Kein böser Wille.
Wer genug um die Komplexität moderner Prozessoren weiss, der hat m.E.
kein Problem, sich das einfach nur als Fehler vorzustellen. Dein Bauer
jedoch, der erklärt sich ihm unverständliche Dinge gerne mit Gott oder
Teufel. Früher wie heute.
Marc H. schrieb:>> Naja: im Thread nicht. Oder kennst du ein Smartphone mit einem>> x86-Prozessor? ;-)>> Nokia Lumia mit WindowsPhone
Lumias hatten m.W. durchweg ARM Prozessoren drin. Nicht alles wo Windows
draufsteht hat x86 drin.
A. K. schrieb:> Lumias hatten m.W. durchweg ARM Prozessoren drin. Nicht alles wo Windows> draufsteht hat x86 drin.
Bei den Lumias , Nokia und Microsoft, gab es nur mit Qualcom SoC.
Die ja auf ARM basieren.
Prozessoren im Smartphone wie beim PC, werden nicht verwendet.
Da hat Intel aber Glück gehabt, dass Sie mit SoC für Smartphones nie in
den Markt gekommen sind.
@ A.K.
wer eine grobe Ahnung von der Komplexität sowohl der Prozessoren wie der
resultierenden Begehrlichkeiten hat, vermag auch mögliche Schnittmengen
zu überschlagen ohne zwangsläufig Kenntnis in allen Details zu
benötigen.
Das geht auch ohne Hinzuziehung extranatürlicher Entitäten.
Namaste
Winfried J. schrieb:> Das geht auch ohne Hinzuziehung extranatürlicher Entitäten.
Im Sinn meiner Aussage sind deine Begehrlichen die modernen Nachfolger
der extranatürlichen Entitäten. Insofern sehe ich deine Aussage eher als
Bestätigung von meiner. ;-)
OS schrieb:> A. K. schrieb:>> Lumias hatten m.W. durchweg ARM Prozessoren drin. Nicht alles wo Windows>> draufsteht hat x86 drin.>> Bei den Lumias , Nokia und Microsoft, gab es nur mit Qualcom SoC.> Die ja auf ARM basieren.> Prozessoren im Smartphone wie beim PC, werden nicht verwendet.
Nicht mehr wirklich, aber ich meine in letzter Zeit wieder mal was von
einem Atom basierten Phone gelesen zu haben.
> Da hat Intel aber Glück gehabt, dass Sie mit SoC für Smartphones nie in> den Markt gekommen sind.
Eigentlich schade, ich hatte mal ein Asus ME302C, das ist dank Atom
gerannt wie Sau unter Android x86, und das schon 2013. Leider sind die
bei Android 4.3 stehen geblieben...
Christian R. schrieb:> Eigentlich schade, ich hatte mal ein Asus ME302C, das ist dank Atom> gerannt wie Sau unter Android x86,
Intel war in Summe voll konkurrenzfähig, bei halb so viel Cores, hatte
also eine wesentlich bessere Leistung pro Core. Das ist für den Eindruck
der Geschwindigkeit klar im Vorteil.
Ist beim PC nicht anders, ein Dualcore bringt bei gleicher oder nur
unwesentlich geringerer Gesamtleistung subjektiv meist mehr als ein
Quadcore.
Uhu U. schrieb:> A. K. schrieb:>> Die Akku-Affäre. Die Performance alter Geräte ausbremsen, damit alte>> Akkus nicht überfordert werden.>> Was ja durchaus vernünftig ist... Hat aber einige Idioten nicht daran> gehindert, im Land der unbegrenzten Unmöglichkeiten gleich deswegen> gegen Appel zu klagen. Man darf gespannt sein, was dabei heraus kommt.
Ob es nun vernünftig ist, heimlich die Performance massiv auszubremsen,
damit der Benutzer nicht merkt, dass der Akku schon langsam nix mehr
taugt, ist wohl Ansichtssache.
A. K. schrieb:> Ist beim PC nicht anders, ein Dualcore bringt bei gleicher oder nur> unwesentlich geringerer Gesamtleistung subjektiv meist mehr als ein> Quadcore.
Bei welchem Anforderungsprofil?
Sheeva P. schrieb:> A. K. schrieb:>> Ist beim PC nicht anders, ein Dualcore bringt bei gleicher oder nur>> unwesentlich geringerer Gesamtleistung subjektiv meist mehr als ein>> Quadcore.>> Bei welchem Anforderungsprofil?
Normale Mail/Browser/Office Umgebung.
Die interaktiv spürbare Reaktionszeit von Programmen bestimmt sich aus
einem Mix aus parallelisierbaren Aufgaben (mehrere Threads teilen sich
die Arbeit gleichermassen) und rein sequentiellen Operationen (ein
Thread dominiert). Mehrere Cores verbessern die Laufzeit des
parallelisierbaren Teils, aber nicht die des sequentiellen Teils.
Ist nun der Anteil parallelisierten Codes recht überschaubar, wie das
bei obigem Profile weiterhin der Fall ist, wird die Reaktionszeit
wesentlich von der Zeit bestimmt, die sequentiellen Aufgaben zu
erledigen.
Wenn 2 CPUs in gut parallelisierbaren Benchmarks die gleiche
Summenleistung haben, ein Dualcore und ein Quadcore, dann hat beim
Dualcore der einzelne Core die doppelte Leistung gegenüber einem Core
des Quadcores. Folglich kann der Dualcore den sequentiellen Teil doppelt
so schnell ausführen wie der Quadcore. Und ist folglich spürbar
schneller.
Wenn man sich also nicht gezielt auf länger dauernde, stark
rechenintensive und gut parallelisierbare Aufgaben konzentriert, sondern
am PC/Handy mit Allerweltsaufgaben sitzt und die Performance daran
bemisst, wie flott die Kiste sich anfühlt, wird eine gute single thread
Performance weiterhin eine wesentliche Rolle spielen.
Im Grunde ist das nichts anderes als Amdahls Law.
Eine der Möglichkeiten, den Inhalt einer nicht direkt zugreifbaren
Speicherstelle *mem rauszufinden, sieht wohl sinngemäss ungefähr so aus.
Als Schema, nicht als Code zu verstehen:
for (uint8_t a = 0; a < 256; ++a) {
char b; // in vom Rest getrennter Cache Line
..b aus dem Cache werfen..
if (cond) { // als true vorhergesagt, spät als false erkannt
..auf b genau und nur dann zugreifen wenn *mem==a..
..nicht selbst über spekulativen Code, CMOV kann helfen..
}
..Laufzeit von Zugriff auf b messen..
if (b ist offensichtlich im Cache)
return a; // *mem==a trifft zu
}
Weil das einige hier unterschätzen:
Die Lücke lässt sich angeblich über Javascript ausnutzen.
Anbei ein Beispiel, wieviele Scripte SPON nachlädt. Das kann kein Mensch
mehr kontrollieren, insbesondere niemand bei SPON mehr. Und es gibt
Seiten, die treiben es deutlich bunter.
D.h. wenn das stimmt, ist die Gefahr riesig. Viele Webseiten verwenden
viele Skripte aus vielen Quelle, auch seriöse Webseiten. Es reicht ein
gehackter Adserver, um das breit zur Anwendung zu bringen.
Die Regel "Hirn an" funktioniert deswegen nicht mehr. Selbst bei
seriösesten Seiten muss man immer damit rechnen, dass ein Werbebanner
ein böses Skript mitbringt.
Mich stört die Skriptinflation schon länger, aber damit scheine ich zu
einer Minderheit zu gehören...
A. K. schrieb:> Eine der Möglichkeiten, den Inhalt einer nicht direkt zugreifbaren> Speicherstelle *mem rauszufinden, sieht wohl sinngemäss ungefähr so aus.
Der Unterschied zwischen Intel und AMD könnte in diesem Beispiel darin
bestehen, dass Intel im Load von *mem ein TRAP Flag setzt, die
Load-Operation unter bestimmten Randbedingungen bzgl TLB/Caches aber
trotzdem durchführt und das Ergebnis in noch spekulativen Folgebefehlen
genutzt werden kann. Wenn AMD demgegenüber nicht nur das TRAP Flag
setzt, sondern auch kein Ergebnis liefert, wäre dieser Angriff nicht
möglich.
Entspricht oben Variante 3, CVE-2017-5754.
Statement von AMD: http://www.amd.com/en/corporate/speculative-execution
Javascript schrieb:> Mich stört die Skriptinflation schon länger, aber damit scheine ich zu> einer Minderheit zu gehören...
Es stöhrt viele Menschen wenn man die Nutzerzahl von uMatrix, NoScript
usw. betrachtet.
Manche Seiten wie Netflix usw. haben mitunter >99 Scripte direkt auf der
Seite eingebunden.
Kaj G. schrieb:> Ich lehne mich mal etwas aus dem Fenster und sage:> Die Kacke ist am dampfen... und zwar so richtig.
Umso dampfender, je weniger Kontrolle man über den auf der Kiste
laufenden Code hat. Clients sind schon per Browser direkt betroffen,
ebenso natürlich die Hoster/Cloud-Provider. Installierte Programme
können Unfug treiben, aber das können sie oft sowieso schon.
Reine Web/DB/App-Server sind deutlich weniger betroffen, zumindest
solange sie keinen externen Code dynamisch nachladen und Updates
vertrauenswürdig sind. Die sind aber ebenso dran, wenn andere Bugs die
Ausführung von eingeschleustem Code ermöglichen, zumal die bisherige
Sicherheitsmassnahme KASLR nicht mehr viel Wert ist.
Wenn ich die neuesten Infos (Google Blog-Eintrag etc.) richtig verstehe,
dann ist es also ungefähr so:
- es gibt einen Hardware-Bug, dem man den Namen "Meltdown" gegeben hat.
Dieser Bug betrifft nur Intel-CPUs
- dieser Bug ist allerdings im Grunde nur eine besonders leicht
ausnutzbarer Spezialfall einer viel grösseren Sicherheitslücke, die
"Spectre" getauft wurde, und die alle drei grossen CPU-Hersteller
(Intel, ARM, AMD) und fast alle CPUs betrifft
Was ich übrigens merkwürdig finde: Laut Wikipedia wurde der
"Meltdown"-Bug der Intel-CPU quasi gleichzeitig, aber unabhängig
voneinander von drei verschiedenen Institutionen entdeckt:
- Google's Project Zero
- Cyberus Technology
- Graz University of Technology
(Quelle:
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)#History)
Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem
Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast
gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen
entdeckt wird?
Die einzige Erklärung, die mir auf Anhieb einfällt, ist, dass zu der
Zeit mglw. bereits eine Schadsoftware im Umlauf war, die diese
Sicherheitslücke ausgenutzt hat, und die dann fast gleichzeitig von
mehreren Sicherheits-Teams untersucht wurde. Oder wie lässt sich das
sonst erklären?
Joachim S. schrieb:> - dieser Bug ist allerdings im Grunde nur eine besonders leicht> ausnutzbarer Spezialfall einer viel grösseren Sicherheitslücke
Es sind 3 völlig verschiedene Szenarien, die aber alle vom gleichen Fix
behoben werden. Wenn man die fehlende Kernel-Isolation nicht schon
selbst als Sicherheitslücke sieht.
> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?
Weil einer eine noch nicht fertig durcherforschte Idee hat, diese im
Sommer 2017 öffentlich macht, und sich danach die Habichte darauf
stürzen. Beispielsweise
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
Joachim S. schrieb:> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?
Das Problem ist bereits seit langem bekannt, aber keiner der Wissenden
wollte ohne Anlass allein seinen Hals riskieren.
Lars R. schrieb:> Joachim S. schrieb:>> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem>> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast>> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen>> entdeckt wird?>> Das Problem ist bereits seit langem bekannt, aber keiner der Wissenden> wollte ohne Anlass allein seinen Hals riskieren.
Oder die Lücken waren gar keine Lücken.
Möglicherweise ist möglicherweise iregenwas über dieses schöne
Hintertürchen durchgesickert, und die "falschen" Stellen fangen an, das
auszunutzen. z.B. die falschen Geheimdienste oder Kriminelle, was ein
Schließen nötig macht.
Dann kann man das einfach ein paar Informationen durchsickern lassen
(indem man eine Idee äußert oder ähnliches) und die Lücke finden lassen.
Dann muss sie geschlossen werden.
Das ist natürlich reine Spekulation.
Auch denkbar:
Es reicht ja schon die Vermutung, dass das ein Hintertürchen ist, um die
viele Leute zum Schweigen zu bringen. Wer will schon für ein bischen
Ruhm die Aufmerksamkeit der falschen Leute erregen?
Hmm schrieb:> Oder die Lücken waren gar keine Lücken.
Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten
der Sicherheit. Ganz klassisch.
> Möglicherweise ist möglicherweise iregenwas über dieses schöne> Hintertürchen durchgesickert, ...
Du meinst, MIL macht seit Jahrzehnten für alle ihre PCs und Geräte,
sowie den Geräten der Vertragspartner mit den Kernelpatches rum? Für
Windows und Linux? Für jede Kernelversion? Glaube ich nicht. Oder meinst
Du, die setzen sich absichtlich ihrer eigenen Schwachstelle aus? Glaube
ich auch nicht.
Hmm schrieb:> Lars R. schrieb:>> Joachim S. schrieb:>>> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem>>> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast>>> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen>>> entdeckt wird?>>>> Das Problem ist bereits seit langem bekannt, aber keiner der Wissenden>> wollte ohne Anlass allein seinen Hals riskieren.>> Oder die Lücken waren gar keine Lücken.
Auf Twitter liest sich das eher so, als ob bestimmte Leute das nicht als
Sicherheitsluecke eingestuft haben, weil es kein PoC (Proof of Concept)
gab. KAISER sollte demnach wohl schon auf der Black Hat USA vorgestellt
werden, was aber abgelehnt wurde.
https://twitter.com/lavados/status/948536300830851072
1
Daniel Gruss @lavados
2
3
#FunFact: We submitted #KAISER to #bhusa17 and got it rejected.
4
We can just assume that it lacked practical relevance or had no
Lars R. schrieb:> Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten> der Sicherheit. Ganz klassisch.
Wobei das in den 90ern keine konkrete Alternative war, sondern höchstens
eine allgemeine. Klar war damals IMHO nur, dass mit der Komplexität der
Implementierung von CPUs, besonders bei OOO execution, ganz allgemein
das Risikoniveau steigt.
Und auf Ideen muss immer erst jemand kommen, die fallen nicht von allein
und sofort von den Bäumen. So lange niemand auf die Idee kam,
Laufzeiteffekte von Befehlsausführung in Abhängigkeit von spekulativer
Ausführung zu testen, tauchte das auf keinen Radar auf.
Dass viel sich nachher fragen, wieso sie nicht vorher drauf gekommen
sind, ist völlig normal. Das ist meistens so.
Kaj G. schrieb:> Auf Twitter liest sich das eher so, als ob bestimmte Leute das nicht als> Sicherheitsluecke eingestuft haben, weil es kein PoC (Proof of Concept)> gab. KAISER sollte demnach wohl schon auf der Black Hat USA vorgestellt> werden, was aber abgelehnt wurde.
Ach. Und wenn Sie einen Proof of Concept gehabt hätten, dann hätten sie
das so auf der Konferenz vorgestellt dürfen?
A. K. schrieb:> Lars R. schrieb:>> Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten>> der Sicherheit. Ganz klassisch.>> Wobei das in den 90ern keine konkrete Alternative war, sondern höchstens> eine allgemeine. [...]> Und auf Ideen muss immer erst jemand kommen, die fallen nicht von allein> und sofort von den Bäumen. So lange niemand auf die Idee kam,> Laufzeiteffekte von Befehlsausführung in Abhängigkeit von spekulativer> Ausführung zu testen, tauchte das auf keinen Radar auf.
Naja. Man kann keinen Weg gehen, der einem aus technologischen oder
wirtschaftlichen Gründen versperrt ist. Deshalb will ich niemanden aus
der Vergangenheit kritisieren.
Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in
dem Maße den Interessen des Anwenders dienen, wie dies technologisch und
auch wirtschaftlich möglich wäre.
Lars R. schrieb:> Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in> dem Maße den Interessen des Anwenders dienen, wie dies technologisch und> auch wirtschaftlich möglich wäre.
???
Lars R. schrieb:> Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in> dem Maße den Interessen des Anwenders dienen, wie dies technologisch und> auch wirtschaftlich möglich wäre.
Du schreibst in Rätseln.
Wem dienen denn die CPU-Architekturen sonst? Den Geheimdiensten?
Dem Satan™? Der Weltverschwörung?
Dass Intels Architektur nicht unbedingt der Stein der Weisen ist,
das zeigt letztlich der Siegeszug von ARM im Mobilbereich. Sie haben
damals wohl beim Aufkommen von RISC ihre Felle davon schwimmen sehen
und haben auf Teufel komm raus versucht, alles das, was man bei RISC
dem Compiler als Intelligenz überlassen wollte, stattdessen in die
CPU zu stopfen. Da das Silizium aufgrund kleiner werdender Strukturen
immer billiger wurde, ging diese Rechnung technologisch sogar
einigermaßen auf – wenn man davon absieht, dass ein riesiges, Strom
fressendes Gattergrab aus diesen CPUs geworden ist. Wie man nun sieht,
durchaus eins, das am Ende wohl auch keiner mehr überblickt.
Aber: sie haben mit dieser Strategie im Desktop- und Serverbereich RISC
tatsächlich nahezu verdrängt. CPUs mit deutlich schönerer Architektur
(wie UltraSPARC) sind auf der Strecke geblieben, übrig ist noch PowerPC
–
und ARM halt.
AMD hat weitgehend nur nachgezogen, mit einer Ausnahme: amd64. Da
hatten sie die Nase vorn, Intel hatte sich mit dem Itanium verrannt.
Da musste dann ein Windows-Release warten, bis Intel eiligst ihr
Pendant auch fertig hatte, und man hat die Architektur dann schnell
noch in "x86_64" umgetauft, um nicht so sehr an die große Glocke zu
hängen, dass hier AMD tatsächlich mal Innovation eingebracht hat.
Allerdings bewegte sich auch diese Innovation natürlich nach wie vor
in dem Gattergrab-CISC-Bereich, in dem auch Intel zu Hause ist.
Hmm schrieb:> Auch denkbar:> Es reicht ja schon die Vermutung, dass das ein Hintertürchen ist, um die> viele Leute zum Schweigen zu bringen. Wer will schon für ein bischen> Ruhm die Aufmerksamkeit der falschen Leute erregen?
Willkommen im Club,
hier dein ALU-Hut, trage ihn mit Stolz und Würde, denn die wirst du
brauchen.
Ockhams Messer ist scharf und wird besonders gern an den Hals derer
angesetzt, welche zu laut denken. Denk leise an Mrs. Chalsea Manning.
oh Lars,
du brauchst auch einen Bitte hier ist deiner.
Namaste
A. K. schrieb:> Lars R. schrieb:>> Es ist aber schon lang klar, dass aktuelle CPU-Architekturen nicht in>> dem Maße den Interessen des Anwenders dienen, wie dies technologisch und>> auch wirtschaftlich möglich wäre.>> ???
Wie ich oben schon schrieb: "Virtualisierung" der CPU-Architektur mit
FPGA. Natürlich haben kommerzielle IC-Entwickler und IC-Verkaufer kein
Interesse daran, sich selbst obsolet zu machen.
Hypothetisches Beispiel: RISC-V Multicore auf aktuellem FPGA. Dazu
Linux.
Aktuell sind die Softcores noch etwas zu langsam, aber viel fehlt nicht
mehr. Dann genügt das für Office und co. Ob der Rechner deshalb 50EUR
mehr kostet, spielt nur eine untergeordnete keine Rolle.
Ein Zwischenschritt ist die Verwendung von CPU hard macros (ab 1...2GHz)
und der Peripherie als "virtuelle" Realisierung.
Wenn wir so weit sind, wird vieles wieder aus der CPU "heraus wandern".
Das System wird dadurch konzeptionell bedingt leistungsfähiger und
sicherer (thematisch verwandt mit Microkernel).
Dateisystem, Sound, usw. läuft dann gar nicht mehr auf der "zentralen"
CPU.
Vielmehr läuft das Dateisystem dann auf einer CPU, die nur das macht und
nichts anderes. Alles wird auf dem Chip zusammengebunden, zB mittels NoC
(Network on Chip).
Jörg W. schrieb:> Du schreibst in Rätseln.>> Wem dienen denn die CPU-Architekturen sonst?
Hoffe, es war verständlich, sonst frag nach.
Lars R. schrieb:> "Virtualisierung" der CPU-Architektur mit FPGA.
Also Stromfresser ohne Ende.
Außerdem: wer soll das bezahlen?
Bei meinem vorigen Brötchengeber wurde ein FPGA gesucht, mit dem man
einen IC emulieren kann, der am Ende weniger als 10 Währungseinheiten
(EUR oder USD) im Verkauf kostet. Das Teil war so komplex, dass das
dafür nötige FPGA im fünfstelligen Bereich kostet.
Aktuelle CPUs sind nochmals deutlich komplexer als dieser Baustein …
Da sich hier ja der Ein oder Adnere fragt, wie sowas jahrelang
unentdeckt bleiben konnte, hier mal ein Vortrag von der BlackHat 2015
https://youtu.be/lR0nh-TdpVgA. K. schrieb:> Und auf Ideen muss immer erst jemand kommen, die fallen nicht von allein> und sofort von den Bäumen.
Genau so sieht es aus.
Jörg W. schrieb:> Lars R. schrieb:>> "Virtualisierung" der CPU-Architektur mit FPGA.>> Also Stromfresser ohne Ende.
Strombedarf ergibt sich vor allem beim Schaltvorgang. FPGAs befinden
sich in Smartphones.
> Außerdem: wer soll das bezahlen?
Das ist eine Frage der Stückzahlen und der Märkte.
> Bei meinem vorigen Brötchengeber [...]
Dazu kann ich mangels Information (noch) keine Bewertung abgeben.
Die Transistor-Zahl von FPGAs und CPUs ist prinzipiell ähnlich. Eine CPU
mit 1Mrd Transistoren passt natürlich nicht in einen FPGA mit 4 Mrd
Transistoren. Nur: Brauchst Du denn die neue top-of-the-edge CPU oder
genügt auch eine von vor 6 Jahren? Brauchst Du ständig
Befehlssatzerweiterung a,b,c,d,e,...?
Dafür herrschst Du über jedes einzelne Bit. Tendenziell komplett
open-source.
Lars R. schrieb:> Dafür herrschst Du über jedes> einzelne Bit. Tendenziell komplett open-source.
Du herrscht über gar nichts, weil so hochgezüchtete FPGAs noch mehr
Fehler und Angriffsmöglichkeiten hätten die der Entwickler nie für
möglich gehalten hätte.
Und da du dann durch die programmierbare Struktur der Hardware noch eine
Ebene mehr an Komplexität hast kann es endgültig keiner mehr überblicken
und schon gar nicht mehr flächendeckend bei Fehlern patchen.
A. K. schrieb:> Joachim S. schrieb:>> - dieser Bug ist allerdings im Grunde nur eine besonders leicht>> ausnutzbarer Spezialfall einer viel grösseren Sicherheitslücke>> Es sind 3 völlig verschiedene Szenarien, die aber alle vom gleichen Fix> behoben werden. Wenn man die fehlende Kernel-Isolation nicht schon> selbst als Sicherheitslücke sieht.
Der von Dir zitierte Teil meines Postings war im Grunde nur eine
Übersetzung aus dem Wikipedia-Artikel: "The Meltdown vulnerability can
be thought of as a particularly easy and efficient-to-implement special
case of Spectre."
Somit ist Dein Kommentar vermutlich inhaltlich zutreffend, aber auch
kein Widerspruch zu der von Dir zitierten Aussage.
>> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem>> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast>> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen>> entdeckt wird?>> Weil einer eine noch nicht fertig durcherforschte Idee hat, diese im> Sommer 2017 öffentlich macht, und sich danach die Habichte darauf> stürzen. Beispielsweise> https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
Danke, das ist in der Tat ebenfalls eine plausible Erklärung.
Wobei mir gerade nicht ganz klar ist, ob der verlinkte Artikel jetzt die
"nicht fertig durcherforschte Idee" darstellen soll, oder ein Beispiel
für einen "Habicht". :)
Der Andere schrieb:> und schon gar nicht mehr flächendeckend bei Fehlern patchen.
Immerhin könnte man Fehler wie hier patchen.
Hinsichtlich Stromeffizienz wird das nichts mit Softcores in FPGAs. Ich
denke nicht, dass deren Stromverbrauch auch nur annähernd die gleiche
Rechenleistung pro Watt abliefern kann, wenn man nicht nebenbei auch
anwendungsspezifische Befehle implementiert.
Man braucht viel mehr Aufwand für das gleiche Ergebnis und kann die
einzelnen Schaltelemente nicht auf die jeweils nötigen Parameter zu
Tempo und Leistung tunen. Auch die selektive Trennung ganzer
Funktionsbereiche vom Strom dürfte interessant werden.
Der Andere schrieb:> Lars R. schrieb:>> Dafür herrschst Du über jedes>> einzelne Bit. Tendenziell komplett open-source.>> Du herrscht über gar nichts, weil so hochgezüchtete FPGAs noch mehr> Fehler und Angriffsmöglichkeiten hätten die der Entwickler nie für> möglich gehalten hätte.
Eben nicht. Du verwechselt hier Angriffe auf FPGAs mit Angriffen auf
CPUs.
Bei Angriffen auf FPGAs versucht man insbesondere, an das Design heran
zu kommen.
Bei Angriffen auf CPUs versucht man, Bits zu kippen. Man weiß, dass
Millionen von Bausteinen das selbe machen, wenn Bit xy gekippt wird.
Das ist aber beim FPGA überhaupt nicht der Fall. Da müsstest Du schon
exakt zu 100% das selbe Design laden. Dazu gibt es natürlich keinen
Anlass. Auch bei gleicher Funktionalität kann man hinreichend
randomisieren, welches physikalische Bit des FPGAs welches Bit der CPU
Architektur repräsentiert.
> Und da du dann durch die programmierbare Struktur der Hardware noch eine> Ebene mehr an Komplexität hast kann es endgültig keiner mehr überblicken> und schon gar nicht mehr flächendeckend bei Fehlern patchen.
Der FPGA wird funktional unabhängig getestet. Natürlich, Du kannst
heutzutage ein Python-Script ausführen und es stürzt Dir wegen
CPU-Hardware-Bugs in Milliarden von Transistoren ab. Trotzdem
beherrschbar, nicht wahr?
A. K. schrieb:> Hinsichtlich Stromeffizienz wird das nichts mit Softcores in FPGAs. Ich> denke nicht, dass deren Stromverbrauch auch nur annähernd die gleiche> Rechenleistung pro Watt abliefern kann, wenn man nicht nebenbei auch> anwendungsspezifische Befehle implementiert.
Man macht einen ganzen CPU-Kern anwendungsspezifisch, bzw
Task-spezifisch.
Lars R. schrieb:> Man macht einen ganzen CPU-Kern anwendungsspezifisch, bzw> Task-spezifisch.
Wer ist "man" und weshalb macht "man" das perfekter als normale
Allerwelts-Programmierer? Deren Grad an Perfektion ist wohl hinlänglich
bekannt.
Wie wird darin verhindert, dass Anwendungslösungen (früher Programme
genannt) direkten Durchgriff auf alle Hardware-Ressourcen bekommen? Die
ja direkt dranhängen.
Wie wird erreicht, dass ein Gerät mehr als eine Aufgabe mehr oder
weniger gleichzeitig erledigt, wenn jede davon das gesamte FPGA
benötigt? Zeitmultiplex, d.h. alle Naselang bekommt das FPGA ein
komplett neues Programm rauf, zyklisch wechselnd? Oder geht nicht, muss
alles zusammen drauf passen?
Irgendwie erinnert mich das an DOS. Ohne Filesystem.
Also ich setz mir noch mal meinen AlCuHut, bessere Ableitung durch
Skineffekt, auf.
Für mich lautetet die Botschaft des konzertierten öffentlichen
SW-Patches folgendes:
1. Was dort Im Sommer endgültig öffentlich wurde wissen wir schon lange.
2. Wir wollten es aus verschiedenen Gründen nicht diskutieren. (mögliche
grüne selbst finden)
3. Jetzt nach dem es Anderen bekannt ist können wir es nicht länger
ignorieren.
4. Da wir es versäumten das Problem rechtzeitig ernst zu nehmen sind wir
nicht in der Lage ein sehr aufwendiges HW basiertes Äquivalent zu
bieten.
5. Deshalb liebe Softworker holt bitte schnell die Kohlen aus dem Feuer,
sonst haben wir die Scheiße am Schuh.
6. Wir wissen was zu tun ist. Hier unseren bisher Top Secret SW
Workarrounds
pflegt das mal schnell ein.
7. und an die ungewollt Informierten wir schlagen euch mal kurz die Tür
vor der Nase zu. Habt bitte Verständnis, dass wir wissen, dass Ihr wisst
was wir wussten. Leider ist es für uns nun nicht nur nutzlos, sondern zu
riskant.
Namaste
A. K. schrieb:> Lars R. schrieb:>> Man macht einen ganzen CPU-Kern anwendungsspezifisch, bzw>> Task-spezifisch.>> Wer ist "man" und weshalb macht "man" das perfekter als normale> Allerwelts-Programmierer? Deren Grad an Perfektion ist wohl hinlänglich> bekannt.
Kommt alles von der Stange. Oder schreibst Du heute jede Software-Lib
selbst und mit ASM.
> Wie wird darin verhindert, dass Anwendungslösungen (früher Programme> genannt) direkten Durchgriff auf alle Hardware-Ressourcen bekommen? Die> ja direkt dranhängen.
Wie man das halt in einem Netzwerk so macht. ;)
> Wie wird erreicht, dass ein Gerät mehr als eine Aufgabe gleichzeitig> erledigt, wenn jede davon das gesamte FPGA benötigt?
So, wie das heute jeder Server auch macht.
Das sind keine "fest verdrahteten" Komponenten. Das können dutzende CPUs
sein. Jedoch, die Festplatten hängen nur an einer ganz bestimmten CPU.
Selbiges für Sound, usw.
Du hast mehrere 64-Bit-CPUs in einem FPGA. Ja wenn's nicht reicht, dann
reicht's eben nicht. Dann muss eben Taskwechsel gemacht werden. Macht
man doch heute auch, wo ist das Problem?
Lars R. schrieb:> Das sind keine "fest verdrahteten" Komponenten. Das können dutzende CPUs> sein. Jedoch, die Festplatten hängen nur an einer ganz bestimmten CPU.> Selbiges für Sound, usw.
Also ein FPGA fürs Festplatteninterface, eines für den generischen
SCSI-Layer, eines für den Festplattencache des Systems, eines für das
Filesystem, eines für den Filesystem-Dispatcher, ... und all das nur, um
an Files ran zu kommen.
Und das war noch der einfache Fall. Ich will lieber nicht wissen,
welchen Zoo du für USB kriegst. ;-)
Joachim S. schrieb:> Wie erklärt sich das, dass so ein CPU-Bug offenbar seit mindestens einem> Jahrzehnt besteht, ohne dass es irgendwem auffällt - und dann fast> gleichzeitig von gleich drei voneinander völlig unabhängigen Stellen> entdeckt wird?> Die einzige Erklärung, die mir auf Anhieb einfällt, ist, dass zu der> Zeit mglw. bereits eine Schadsoftware im Umlauf war, die diese> Sicherheitslücke ausgenutzt hat, und die dann fast gleichzeitig von> mehreren Sicherheits-Teams untersucht wurde. Oder wie lässt sich das> sonst erklären?
Ganz einfach:
1
Für Meltdown haben die Forscher der TU Graz bereits einen Patch, also
2
eine wirksame Gegenmaßnahme, entwickelt. Der so genannte KAISER-Patch
3
wurde bereits vor einiger Zeit gegen eine andere Art von Cyberangriff
4
entwickelt.
5
6
Zu dem Zeitpunkt war noch nicht klar, dass sämtliche Prozessoren von
7
AMD, ARM und Intel von einer Lücke betroffen sind, die mit einem
8
solchen Patch zu schließen ist.
9
10
Anfang Dezember 2017 merkten die Forscher, dass dieser KAISER-Patch
11
im Kernel von Linux-Betriebssystemen auftauchte. "Wir haben uns gedacht
12
'Da muss etwas Größeres dahinter sein' und haben das untersucht", meint
13
Gruss. Sein Team nahm mit Intel Kontakt auf und erfuhr, dass auch andere
14
IT-Sicherheitsexperten bereits aufmerksam geworden waren.
Lars R. schrieb:> Wie ich oben schon schrieb: "Virtualisierung" der CPU-Architektur mit> FPGA. Natürlich haben kommerzielle IC-Entwickler und IC-Verkaufer kein> Interesse daran, sich selbst obsolet zu machen.
Was soll das bringen? Möglicherweise schnellere Patches. Ansonsten liegt
das Problem, falls ich die Angriffe richtig verstanden habe, schlicht an
der (fehlerhaften) spekulativen Ausführung von Befehlen (Spectre) bzw.
dem Ausführen von Befehlen Out-of-order (Meltdown) -> das machen alle
heutigen Hochleistungs-CPUs: RISC-V
https://github.com/ucb-bar/riscv-boom ebenso wie Power(PC) oder SPARC.
Für Power ist die Lücke ebenfalls bestätigt worden:
https://access.redhat.com/security/vulnerabilities/speculativeexecution
(System Z, Power8 und Power9)
A. K. schrieb:> Lars R. schrieb:>> Das sind keine "fest verdrahteten" Komponenten. Das können dutzende CPUs>> sein. Jedoch, die Festplatten hängen nur an einer ganz bestimmten CPU.>> Selbiges für Sound, usw.>> Also ein FPGA fürs Festplatteninterface, eines für den generischen> SCSI-Layer, eines für den Festplattencache des Systems, eines für das> Filesystem, eines für den Filesystem-Dispatcher, ... und all das nur, um> an Files ran zu kommen.>
Nein. Eine von mehreren CPUs imFPGA nur für Festplatten. Im FPGA gibt
es zB. Ethernet. Diese CPU dient als FileServer und wird logisch auch
genauso angesprochen. Nur, dass sich der Fileserver auf dem selben Chip
befindet.
Das spart schon mal einige Kontext-Switches und branches.
> Und das war noch der einfache Fall. Ich will lieber nicht wissen,> welchen Zoo du für USB kriegst. ;-)
Intel nimmt nun sogar die dedizierte Graphik von AMD mit auf das
Package, weil sie mit dem Silizium nichts besseres mehr anzufangen
wissen. Findest Du das auch amüsant?
> Was soll das bringen?
Es ermöglichst, dass sich Architekturen wieder in eine andere Richtung
(zB. multicore Mikrokernel) entwickeln. Ein Problem aktueller
Architekturen ist, dass sie alles können müssen und dabei schnell sein
müssen. Entsprechend komplex sind Kernel mitsamt Scheduling und
Architektur.
Ein erster Ansatz sind CPUs für Smartphones mit verschiedenen Cores.
Lars R. schrieb:> Nein. Eine von mehreren CPUs imFPGA nur für Festplatten. Im FPGA gibt> es zB. Ethernet. Diese CPU dient als FileServer und wird logisch auch> genauso angesprochen. Nur, dass sich der Fileserver auf dem selben Chip> befindet.
Also eine ganz gewöhnliches NAS mit ganz gewöhnlichen CPUs mit einem
eigenen Betriebssystem, nur als Softcore, damit die zig beteiligten
Module verschiedener Entwickler miteinander kooperieren? Was
unterscheidet dabei die FPGA-Lösung von einer Prozessorlösung?
> Intel nimmt nun sogar die dedizierte Graphik von AMD mit auf das> Package, weil sie mit dem Silizium nichts besseres mehr anzufangen> wissen.
Intel hatte schon bisher Grafik auf den meisten Desktop-Prozessoren
drauf, aber AMD hat die bessere. Was hat das mit FPGA zu tun?
A. K. schrieb:> Lars R. schrieb:>> Nein. Eine von mehreren CPUs imFPGA nur für Festplatten. Im FPGA gibt>> es zB. Ethernet. Diese CPU dient als FileServer und wird logisch auch>> genauso angesprochen. Nur, dass sich der Fileserver auf dem selben Chip>> befindet.>> Also eine ganz gewöhnliches NAS mit einer ganz gewöhnliches CPU drauf,> damit die zig beteiligten Module miteinander kooperieren? Was> unterscheidet dabei die FPGA-Lösung von einer Prozessorlösung?
Variante A: CPU mit verschiedenen Dateisystemen und Festplatten
Variante B: CPU ohne Festplatte. Alles über einen Fileserver.
Variante C: wie B, aber der Fileserver ist auf dem selben IC.
Für die Grafik machst Du das ähnlich, bzw gibt es schon.
Für die Verarbeitung von Druckaufträgen spendieren wir auch eine eigene
per "Ethernet" angebundene CPU, usw.
>> Intel nimmt nun sogar die dedizierte Graphik von AMD mit auf das>> Package, weil sie mit dem Silizium nichts besseres mehr anzufangen>> wissen.>> Intel hatte schon bisher Grafik auf den meisten Desktop-Prozessoren> drauf, aber AMD hat die bessere. Was hat das mit FPGA zu tun?
Es zeigt, dass genügend Silizium für den vorgeschlagenen Ansatz da ist.
Ob jemand die Intel HD-Grafik nutzt oder nicht, spielt preislich
praktisch keine Rolle.
Lars R. schrieb:> Variante A: CPU mit verschiedenen Dateisystemen und Festplatten
Worin besteht der Unterschied zu einem ganz gewöhnlichen NAS? Bitte dran
denken, dass du bei bereits dieser Aufgabe zig Entwickler
verschiedenster Firmen quer über die Welt kombinieren musst. Wenn du
nicht das Rad neu erfinden willst.
> Es zeigt, dass genügend Silizium für den vorgeschlagenen Ansatz da ist.> Ob jemand die Intel HD-Grafik nutzt oder nicht, spielt preislich> praktisch keine Rolle.
Die Idee, klassische CPUs mit einem FPGA zu verheiraten, wird immer
wieder mal ventiliert. Bislang allerdings nachhaltig erfolglos, auf
Stückzahlen bezogen. Grund: die Programmierung. Softcores sind in diesem
Zusammenhang nur für Kleinkram sinnvoll und spezifisch programmierte
Hardware ist schwer zu entwickeln.
Kaj G. schrieb:> Warum ist bei POWER9 nur Little Endian, bei POWER8 aber Big Endian und> Little Endian betroffen?
Das wird sich auf Redhats Linux-Distro beziehen. Vielleicht gibts die
nur so.
Lars R. schrieb:> Ein erster Ansatz sind CPUs für Smartphones mit verschiedenen Cores.
Also sowas wie Intels PCU? Ein Microcontroller für
Strom/Leistungsverwaltung. Ist seit knapp einem Jahrzehnt auf den CPUs
mit drauf.
warum muss man nun auch auf Linux basiertem Kram Patches rausgeben?
heisst es nicht immer, dass sich ein Linux keine Schadsoftware einfängt?
Ein linuxbasiertes OS ist doch sicher :-)
A. K. schrieb:> Lars R. schrieb:>> Variante A: CPU mit verschiedenen Dateisystemen und Festplatten>> Worin besteht der Unterschied zu einem ganz gewöhnlichen NAS?
Der Unterschied zum NAS ist, dass bei meinem Vorschlag das NAS auf dem
selben Silizium/Die sitzt.
>> Es zeigt, dass genügend Silizium für den vorgeschlagenen Ansatz da ist.>> Ob jemand die Intel HD-Grafik nutzt oder nicht, spielt preislich>> praktisch keine Rolle.>> Die Idee, klassische CPUs mit einem FPGA zu verheiraten, wird immer> wieder mal ventiliert. Bislang allerdings nachhaltig erfolglos, auf> Stückzahlen bezogen. Grund: die Programmierung.
Ja, aber mit unter an einer anderen Stelle als Du implizierst: Beim
letzten Ansatz war die Schnittstelle sowie die Konfiguration des
Hybriden viel zu kompliziert. Vielleicht ist/war dies auch der
Komplexität der CPU geschuldet.
Anders herum funktioniert es ganz gut: CPU ins FPGA. Da gibt es bereits
Linux mit GUI, usw.
● J-A V. schrieb:> warum muss man nun auch auf Linux basiertem Kram Patches rausgeben?> heisst es nicht immer, dass sich ein Linux keine Schadsoftware einfängt?
Ist dir langweilig? Willst du den Thread in ein Linux/Windows-Gefetze
abbiegen?
A. K. schrieb:> Lars R. schrieb:>> Ein erster Ansatz sind CPUs für Smartphones mit verschiedenen Cores.>> Also sowas wie Intels PCU? Ein Microcontroller für> Strom/Leistungsverwaltung. Ist seit knapp einem Jahrzehnt auf den CPUs> mit drauf.
Bei den Smartphones, auf die ich mich bezog, sind das eigenständige
Cores.
● J-A V. schrieb:> Ein linuxbasiertes OS ist doch sicher :-)
Lass doch deine <zensiert> Polemik bitte da, wo sie hin gehört: im
Mülleimer.
Es geht hier um Würgarounds für einen Hardwarebug, deren Implementierung
einfach (zwangsweise) auf die Performance schlägt, und die man daher
nicht freiwillig vorgenommen hätte, wenn einen die Hardware nicht dazu
verdammt.
So viel solltest du doch wohl aus dem bisherigen Thread mühelos
entnehmen können, oder?
Lars R. schrieb:> Anders herum funktioniert es ganz gut: CPU ins FPGA. Da gibt es bereits> Linux mit GUI, usw.
Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung
und Betriebszeit Akku und Wakü im Rucksack mitschleppst.
A. K. schrieb:> Lars R. schrieb:>> Anders herum funktioniert es ganz gut: CPU ins FPGA. Da gibt es bereits>> Linux mit GUI, usw.>> Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung> und Betriebszeit Akku und Wakü im Rucksack mitschleppst.
Welches?
Lars R. schrieb:>> Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung>> und Betriebszeit Akku und Wakü im Rucksack mitschleppst.>> Welches?
Korrektur: Das ergibt ein Handy, bei dem ...
A. K. schrieb:> Lars R. schrieb:>> Bei den Smartphones, auf die ich mich bezog, sind das eigenständige>> Cores.>> Bei Intel auch. Die PCU ist ein eigenständiger Core.
Auf der ich meine Software ausführe?
A. K. schrieb:> Lars R. schrieb:>>> Das hatten wir schon. Gibt ein Handy, bei den du für gleiche Leistung>>> und Betriebszeit Akku und Wakü im Rucksack mitschleppst.>>>> Welches?>> Korrektur: Das ergibt ein Handy, bei dem ...
Korrektur von Korrektur: "Das hatten wir schon" streichen?
Kaj G. schrieb:> Please talk to management. Because I really see exactly two> possibibilities:>> - Intel never intends to fix anything>> OR>> - these workarounds should have a way to disable them.>> Which of the two is it?>> Linus
both
Namaste
Lars R. schrieb:> Auf der ich meine Software ausführe?
Herzlichen Dank, aber an die Verwaltung von Strom, Takt und Wärme lasse
ich lieber ausschliesslich Intel ran.
A. K. schrieb:> Lars R. schrieb:>> Auf der ich meine Software ausführe?>> Herzlichen Dank, aber an die Verwaltung von Strom, Takt und Wärme lasse> ich lieber ausschliesslich Intel ran.
Mein Gott. Du hast doch davon angefangen und gemeint, mit der PCU gäbe
es so etwas wie meinen Vorschlag oder wie bei den Smartphones bereits.
Auf den Smartphones ist das nicht anders. Auch da ziehe ich es vor, den
Baseband-Prozessor nicht von den App-Programmierern füttern zu lassen.
Rest ähnlich.
A. K. schrieb:> Auf den Smartphones ist das nicht anders. Auch da ziehe ich es vor, den> Baseband-Prozessor nicht von den App-Programmierern füttern zu lassen.> Rest ähnlich.
Ja. Aber: es gibt dort CPUs mit verschiedenen Cores.
Lars R. schrieb:> Ja. Aber: es gibt dort CPUs mit verschiedenen Cores.
An welche dachtest du? Alle, die ich kenne, haben eine homogene Gruppe
generischer Cores, eine GPU, und ein paar spezialisierte Cores anderer
Bauart als die generischen Cores.
Hey
Windows besser als Linux.....
====================
Weil das Problem auf Prozessorebene liegt, betrifft es auch alle
gängigen Betriebssysteme. Laut Daniel Gruss ist es den Grazer Forschern
gelungen, unter Linux und macOS alles auszulesen, was im Arbeitsspeicher
der Rechner abgelegt war, unter Windows "das meiste".
====================
Die IT-Forscher, die das Problem nun bekannt machten, haben
Spectre-Angriffe auf Prozessoren von Intel, AMD sowie auf sogenannten
ARM-Prozessoren durchführen können. ARM-Prozessoren stecken in fast
allen Smartphones und Tablets.
http://www.spiegel.de/netzwelt/gadgets/spectre-und-meltdown-die-wichtigsten-antworten-zu-den-schwachstellen-in-prozessoren-a-1186193.html#ref=rss
Obiges Info nur fuer Windoofler(wie mich)- Profis bitte nur Heise
lesen.....
:-)
Lars R. schrieb:> Etwas runter scrollen.
Ach das meinst du. ARMs bigLITTLE. Ein paar Cores mit viel Leistung viel
Watt und ein paar mit wenig Leistung wenig Watt. Softwarseitig
identisch. Kann man machen um Strom zu sparen. Intels Handy/Table-SoCs
schafften das auch ohne.
Aber was hat das mit dem Thema hier zu tun?
A. K. schrieb:> Ach das meinst du.
Was sonst.
> Aber was hat das mit dem Thema hier zu tun?
Mit der Sicherheitslücke direkt gar nichts. Mit meinem Vorschlag
insofern, als dort eben auch verschiedene, jedoch prinzipiell
generische, Kerne zusammen betrieben werden und auf jedem Core bevorzugt
diejenigen Tasks laufen, für die dieser Core geeignet ist.
Ggf. ist beispielsweise auch die Sprungvorhersage unterschiedlich
implementiert. Dh, hinsichtlich meines Vorschlages ist das ein erster
Ansatz. Dies hatte ich mit einer Zeile erwähnt.
Winfried J. schrieb:> Kann es sein dass der high sierra bug auch schon darin seine Ursache> hatte? Zeitlich käme das hin.> Namaste
ts ts
> Apple-Rechner haben den notwendigen Schutz bereits mit Mac OS 10.13.2> erhalten, Chrome-OS-Systeme mit der Version 63, die Mitte Dezember an alle>ausgeliefert wurde. - derstandard.at/2000071445192/Kritische>Prozessorluecken-gefaehrden-fast-alle-Computer-und-Smartphones
Genau das War das Patch das den High Sierra Bug behoben hat.
Inzwischen ist auch klar, dass es den Cache betrifft aber eventuell eher
den L3 als den von mir vermuteten L2, den ja jeder CORE exklusive
besitzt aber ganz klar ist mir das noch nicht.
Ich sehe mehr Bestätigung als Widerlegung meiner "ALCUHut"Gedanken
sorry
Namaste
Lars R. schrieb:> auf jedem Core bevorzugt> diejenigen Tasks laufen, für die dieser Core geeignet ist.
Das wird vom Betriebssystem bedarfsgemäss entschieden, nach momentanem
Leistungsbedarf, ob interaktiv oder Hintergrund etc. Und kann sich
mittendrin ändern, d.h. ein Thread setzt die Arbeit plötzlich auf einem
anderen Core fort.
Winfried J. schrieb:> Genau das War das Patch das den High Sierra Bug behoben hat.
Meinst du damit den, dass man sich einfach als Root anmelden konnte?
Wenn, dann war das purer Zufall, dass beide mit dem gleichen Patch
behoben worden sind.
A. K. schrieb:> Lars R. schrieb:>> auf jedem Core bevorzugt>> diejenigen Tasks laufen, für die dieser Core geeignet ist.>> Das wird vom Betriebssystem bedarfsgemäss entschieden, nach momentanem> Leistungsbedarf, ob interaktiv oder Hintergrund etc. Und kann sich> mittendrin ändern, d.h. ein Thread setzt die Arbeit plötzlich auf einem> anderen Core fort.
Einverstanden. Man kann es auch so sehen, dass es mit meinem Vorschlag
nichts zu tun hat.
Javascript schrieb:> Weil das einige hier unterschätzen:> Die Lücke lässt sich angeblich über Javascript ausnutzen.>> Anbei ein Beispiel, wieviele Scripte SPON nachlädt. Das kann kein Mensch> mehr kontrollieren,
doch! nosript+adblock rein und wenn die Seite jammert man möge dies
ausstellen dann gibt es diesen hier .I.. und die Seite wird geschlossen
wenn mir das Angebot nicht gefällt dann muss ich es nicht konsumieren
so ne Zeitung aus Papier schnüffelt mich schliesslich auch nicht aus
während ich sie lese
Für W10 wird schon ein Patch angeboten. Ich erwarte allerdings für alle
noch im Einsatz befindlichen Betriebssysteme einen solchen. XP und Vista
dürfen da nicht außen vor bleiben ebenso nicht alte Smartphones.
Toxic schrieb:> ARM-Prozessoren stecken in fast allen Smartphones und Tablets.
Der Januar-Patch repariert das. Für jene, die ihn kriegen. Wer den nicht
mehr kriegt und trotzdem Sicherheit will, der darf ein neues Handy
kaufen.
Insofern reiht sich dieser Bug in die Liste der diversen Probleme ein,
die es bisher schon gab. Da waren diverse Bugs in der Multimedia-Engine,
der WLAN-Bug vor ein paar Monaten, ... Da steht man jedes Mal vor dem
Problem, ob alte Geräte noch einen Update kriegen.
Das wurde ganz bestimmt nur deshalb von der NSA gemacht, damit Huawei
wieder neue Handys verkauft. ;-)
https://youtu.be/bReA1dvGJ6YJörg W. schrieb:> Meinst du damit den, dass man sich einfach als Root anmelden konnte?
Ja ich hatte gerade High Sierra auf meinen Vorgängermodell des aktuellen
MC-BookPro installiert und musste noch mein Office patchen weil es nicht
mehr lief, 2 Tage später dann diese Meldung und dann der o.g. Patch
Namaste
herbert schrieb:> XP und Vista dürfen da nicht außen vor bleiben ebenso nicht alte> Smartphones.
MS-DOS auch? :-)
Träum mal weiter … der Würgaround ist so gravierend, dass du da
für nicht mehr supportete Systemversionen vergeblich warten darfst.
Dass sie Wannacry auf Windows XP noch repariert haben, lag doch nur
daran, dass es vergleichsweise einfach zu reparieren war.
Winfried J. schrieb:>> Meinst du damit den, dass man sich einfach als Root anmelden konnte?>> Ja
Naja, das mit dem Root-Nutzer war aber eine völlig andere Klasse von
Bug. Root hatte auf diesem System ja wohl tatsächlich kein (gesetztes)
Passwort, nur dass man es hätte als Benutzer gar nicht zulassen sollen.
Das ist ein (relativ einfacher) Programmierfehler, der keinen Workaround
für Hardwarebugs braucht.
A. K. schrieb:> Wer den nicht mehr kriegt und trotzdem Sicherheit will, der darf ein> neues Handy kaufen.
Das dürfte der Preis sein, denn man für billige Handys zahlt.
Großartige Softwarewartung ist da wohl nicht drin. (Leider.)
Jörg W. schrieb:> Naja, das mit dem Root-Nutzer war aber eine völlig andere Klasse von> Bug. Root hatte auf diesem System ja wohl tatsächlich kein (gesetztes)> Passwort, nur dass man es hätte als Benutzer gar nicht zulassen sollen.
Der Unterschied ist klar aber High Sierra kam relativ kurz nach Sierra
auf den Markt. Ich tippe mal das der "Root" bug eher der überhasteten
Auslieferung von High Sierra geschuldet war. High Sierra aber leise die
eigentliche Lücke schließen sollte, wobei man die Tür versehentlich ganz
offen stehen ließ. Im Stress geht sowas gern unter.
Namaste
Hallo,
Jörg W. schrieb:> Das dürfte der Preis sein, denn man für billige Handys zahlt.> Großartige Softwarewartung ist da wohl nicht drin. (Leider.)
Und was ist mit teuren, "alten", noch voll funktionsfähigen Handys?
rhf
Roland F. schrieb:> Und was ist mit teuren, "alten", noch voll funktionsfähigen Handys?
Musst du deren Hersteller fragen.
Von einem, welches 500 Euro kostet, würde ich zumindest einen besseren
Support erwarten als eins, was für einen Hunderter verscherbelt wird.
Allerdings wäre ich für erstere auch zu geizig. :)
Jörg W. schrieb:> A. K. schrieb:>> Wer den nicht mehr kriegt und trotzdem Sicherheit will, der darf ein>> neues Handy kaufen.>> Das dürfte der Preis sein, denn man für billige Handys zahlt.> Großartige Softwarewartung ist da wohl nicht drin. (Leider.)
Bei Linux und Windows geht's doch auch mit unterschiedlichsten
Konfigurationen vom Server bis zum Phone mit Updates... nur der G-Kram
hat ein Problem. Bei älteren und aktuellen Geräten sieht's zumindest mit
Qualcomm SoCs besser aus (Lineage), MediaTek bzw. deren Abnehmern müsste
mal mit etwas GPL-Enforcement auf die Sprünge geholfen werden. Bin mal
gespannt wie das bei Intels chinesischem Partner Spreadtrum aussieht,
der SoCs mit Intel-Kernen für Smartphones baut aktuell im Leagoo T5C
http://www.spreadtrum.com/en/SC9853I.html
Jörg W. schrieb:> Das dürfte der Preis sein, denn man für billige Handys zahlt.
Es ist ironischerweise geradewegs andersrum. In Handys der Unterklasse
und auch in vielen der Mittelklasse stecken meistens 4-8 Cortex A53
Cores drin, in älteren Unterklasse-Geräten auch Cortex A7.
Und diese Cores arbeiten nicht spekulativ, sind folglich von der
ganzen Geschichte überhaupt nicht betroffen! Daher auch nicht die
RasPis.
Gekniffen sind derzeit nur die schnelleren Geräte mit Cortex A57
aufwärts, wahrscheinlich auch jene mit Krait Cores und aus diesen ARM
Cores abgeleiteten eigenen Qualcomm Cores.
https://developer.arm.com/support/security-update
Wobei andererseits viele der doch betroffenen ARM Prozessoren auch für
Variante 3 empfänglich sind, das ist die mit Intels Hardware-Bug.
herbert schrieb:> Für W10 wird schon ein Patch angeboten. Ich erwarte allerdings für> alle> noch im Einsatz befindlichen Betriebssysteme einen solchen. XP und Vista> dürfen da nicht außen vor bleiben ebenso nicht alte Smartphones.
jaja, die jährliche Publikumsumfrage beim "security nightmares"-vortrag
am CCC-Congress lässt grüßen:
"wer von euch hat wieder ein XP wegmachen dürfen?" :)
im Ernst, wenn du einen alten Käfer fährst und nach einem Unfall dank
nicht vorhandener Nackenstütze einen Querschnitt hast, dann bist auch du
schuld da das Ding einfach nicht mehr "supported" wird.
XP hat so in etwa den selben Status.
Bei DOS ist patchen dagegen unnötig... kann ja ohnehin jeder auf alles
zugreifen wenn er möchte :)
73
Hans schrieb:> im Ernst, wenn du einen alten Käfer fährst und nach einem Unfall dank> nicht vorhandener Nackenstütze einen Querschnitt hast, dann bist auch du> schuld da das Ding einfach nicht mehr "supported" wird.
Mal im Ernst ... ich wäre froh wenn ich so einen alten Käfer hätte.
Hans schrieb:> XP hat so in etwa den selben Status.
Geh weida... wenn man diesen gefährlichen Fehler als "Teil" betrachtet
dann hat es beseitigt zu werden egal wo es verbaut worden ist. Gäbe es
die Betrugs-Software der Autohersteller schon fünfzehn Jahre , dann hat
auch ein Halter mit einem betagten Auto das recht,dass wie bei einem
Neuwagen nachgebessert wird.
Winfried J. schrieb:> Viel Spass beim autonomen Fahren via Cloud.
Ach was! Das wird dann, wie heute auch schon im Reisebüro zu buchen,
eine "Fahrt in's Blaue". Nur eben ohne Fahrer.
MfG Paul
OS schrieb:> Da hat Intel aber Glück gehabt, dass Sie mit SoC für Smartphones nie in> den Markt gekommen sind.
Wobei die Atom Prozessoren mit Bonell Mikroarchitektur, also alle Atoms
vor Silvermont, vom aktuellen Problem überhaupt nicht betroffen sein
dürften, weil nicht spekulativ arbeitend. Erst mit Silvermont 2013 hielt
auch in dieser Prozessorschiene spekulative Ausführung Einzug.
Joachim D. schrieb:> Wenn etwas dran wäre, wäre das zuerst bei heise.de aufgetaucht.> Da ist *nix*
Seit Jahren gehen die Verkaufszahlen zurück. Neue
Hochleistungsprozessoren werden wenig gekauft, weil die Leistung heute
nicht mehr so eine große Rolle spielt.
Kommt es da nicht gelegen, wenn man sagt, dass das Sicherheitsproblem
nur richtig zu beseitigen ist, wenn man einen neuen Prozessor nimmt?
F. F. schrieb:> Kommt es da nicht gelegen, wenn man sagt, dass das Sicherheitsproblem> nur richtig zu beseitigen ist, wenn man einen neuen Prozessor nimmt?
Wäre es bei dieser Strategie nicht sinnvoller, den Leuten dann aber auch
einen neuen Prozessor anbieten zu können? Also einen, der das
Sicherheitsproblem nicht hat. Denn "kauft sofort einen neuen Prozessor,
aber keinesfalls von uns" bringts irgendwie nicht, oder? ;-)
Es dürfte, vorsichtig ausgedrückt, nicht einfach sein, den aktuellen
Desktop/Server-Prozessoren von Intel und AMD die Spekulation
abzugewöhnen. Da wird eher eine Variante in der Implementierung vom
Paging kommen, die das Problem auch ohne teurem TLB-Flush löst.
herbert schrieb:> Geh weida... wenn man diesen gefährlichen Fehler als "Teil" betrachtet> dann hat es beseitigt zu werden egal wo es verbaut worden ist. Gäbe es> die Betrugs-Software der Autohersteller schon fünfzehn Jahre , dann hat> auch ein Halter mit einem betagten Auto das recht,dass wie bei einem> Neuwagen nachgebessert wird
Du siehst das falsch, per se hat xp (in diesem Fall) keinen Fehler!
Das ist ein workaround um einen Bug in der cpu!!
Ähnlich der Nackenstütze beim Käfer... das ist ein workaround für die
nicht unfehlbaren Menschen.
Wenn überhaupt müsste man Microcode Updates für die CPUs fordern falls
möglich.
73
Hans schrieb:> Das ist ein workaround um einen Bug in der cpu!!
Nur eine der 3 Varianten geht direkt auf einen Bug zurück, nämlich die
Variante 3, von der AMD wohl tatsächlich nicht betroffen ist. Die
anderen Varianten gehen IMHO eher auf zwei prinzipielle Schwachstellen
zurück. Die nicht so sehr Bugs sind, als vielmehr Konzeptprobleme:
-1- Kerneladressen im Userspace gemappt
-2- spekulative Ausführung von Befehlen
die jeweils deutlich die Performance steigern, aber zusammengenommen zu
den aktuellen side channel attacks einladen. Prozessorübergreifend, also
ganz offensichtlich kein einfacher Implementierungsfehler.
Problem 1 wird gerade gelöst. Das ist daher kein Workaround, sondern
tatsächlich eine Lösung des Konzeptproblems. Es gibt Betriebssysteme,
die schon länger oder vielleicht schon immer mit Adressraumtrennung
arbeiten. So wäre ich nicht erstaunt, wenn IBMs POWER Prozessoren nur
mit Linux betroffen sind, nicht aber mit AIX. Die jetzige
Implementierung der Adressraumtrennung könnte freilich einen gewissen
Quick-and-Dirty Charakter haben, über den man vielleicht demnächst reden
wird.
Problem 2 liesse sich lösen, indem man komplexe OOO Prozessoren durch
einfachere und langsamere nicht-spekulative Prozessoren ersetzt. Also
beispielsweise die 4-8 Cores eines Core i7 durch sowas wie die ~60 Cores
eines Xeon Phi der ersten Generation. Die mit aktualisierten Pentium
P54C Cores, die zweite nutzt Silvermont Cores und ist auch gekniffen.
Allerdings wären viele Anwender damit nicht wirklich glücklich, denn die
weitaus meisten PC-Anwendungen würden dadurch drastisch langsamer.
Grund: siehe oben unter Amdahls Law.
Ich gehe daher davon aus, dass zukünftige Prozessoren sich nicht sehr
von den aktuellen unterscheiden werden. Aber Mechanismen enthalten
werden, die den Performance-Einbruch der Adressraumtrennung abmildern
oder eliminieren.
c.m. schrieb:> das verhalten der verbuggten CPU's ist nicht nur den intel entwicklern> bei verschiedenen CPU versionen 10 jahre lang nicht aufgefallen, sondern> auch den kernelentwicklern von windows, linux...
Man sollte es nicht "verbuggt" nennen, wenn ein Stück Technik in dem
Bestreben aufgebaut wird, die technisch höchstmögliche Performance zu
erreichen. Ohne die Sparte der spekulativen Berechnungen wären die
heutigen PC's eben ein ganzes Stück langsamer. Willst du das als Preis
wirklich akzeptieren?
Kaj G. schrieb:> Ich lehne mich mal etwas aus dem Fenster und sage:> Die Kacke ist am dampfen... und zwar so richtig.
Ach nö. Sie hat bereits 10 Jahre des Dampfens hinter sich.
Lars R. schrieb:> Ja, es ist ein Feature. Es macht das Produkt leistungsfähiger auf Kosten> der Sicherheit. Ganz klassisch.
Eben - mal ganz ohne Ironie. Alle möglichen Autostart-Funktionalitäten
(gerade bei Windows) sind Features, die gedacht sind für die
Bequemlichkeit der Benutzer - insbesondere derjenigen Benutzer, die eben
keine Vorstellung von Begriffen wie "Datei", "Verzeichnis" und
dergleichen haben. Das ist übrigens die allergrößte Benutzergruppe - und
man sollte sie nicht schmähen, denn diese Leute haben schlichtweg ein
anderes Feld ihrer Kenntnisse. Wer von euch Programmierern kennt sich
denn z.B. in den Details internationalen Seerechts aus? oder in den
Details von Geologie und Bergbau oder den Details, die ein Zahnarzt
wissen muß? He?
Jörg W. schrieb:> Es geht hier um Würgarounds für einen Hardwarebug, deren Implementierung> einfach (zwangsweise) auf die Performance schlägt, und die man daher> nicht freiwillig vorgenommen hätte, wenn einen die Hardware nicht dazu> verdammt.
Nenne es nicht so. Nenne es lieber ein Schließen von Einfallslöchern,
die Spitzbuben für Übeltaten benutzen könnten.
Toxic schrieb:> Laut Daniel Gruss ist es den Grazer Forschern> gelungen, unter Linux und macOS alles auszulesen, was im Arbeitsspeicher> der Rechner abgelegt war,
Ja. Bei so rund 8 Gigabyte pro gehacktem PC hat man ne Menge zu tun, um
das alles auszuwerten oder über's Netz zur NSA zu schaufeln, damit die
dann die 8 GB durchsuchen können. Technisch einfacher wäre es, die
pagefile.sys oder hiberfile.sys zur NSA zu senden.
Ach Leute,
bleibt doch mal ein bissel auf dem Teppich. Das, was ihr alle jetzt
durchhechelt, ist kein BUG - in dem Sinne, daß darunter normale brave
anständige Programme zu leiden hätten.
Es ist lediglich eine Einfallstür für Leute, die ein ERHEBLICHES
Spitzbuben-Potential besitzen. Ob das in den letzten 10 Jahren nun
staatlich angestellte Spitzbuben waren und ab jetzt eben auch mit
privaten Spitzbuben zu rechnen ist, sei mal dahingestellt.
Aber wie sieht diese Einfallstür aus? Man kann eventuell all das
auslesen, was in als "geschützt" angenommenen RAM-Bereichen des BS so
herumsteht. Toll. Bis also jemand eure noch gültigen Transaktionscodes
für euer E-Banking zusammengekratzt hat, dürfte es noch ein Weilchen
dauern.
Abgesehen davon sehe ich mich mal wieder ein bissel bestätigt, ich hatte
vor Jahren schon mal hier gepostet, daß man Sicherheit eben nur mit
sicheren Strukturen hinkriegt und nicht mit Paßwortabfragen, "Trusted"
Speicherbereichen und dergleichen. Das Stichwort dazu lautet schlicht
und einfach: Nur das ans Netz dran, was wirklich dran muß - und sonst
nix. Also der Arbeitsplatz-PC, wo eure wichtigen Entwicklungsdaten
stecken, gehört eben NICHT an's Netz. Von wegen "bei uns steckt alles in
der Cloud..".
Ich bin ja mal gespannt, was man auf der diesjährigen Embedded zum Thema
erleben darf. Von wegen IOT und so.
W.S.
FYI schrieb:> Hauptsache Mr. Intel wird auf 'links' gezogen. Sein Aktien Deal ist ja> die größte Frechheit als add on.
Das könnte davon abhängen, ob dieses Verhalten für ihn normal war. Wenn
er das Jahr für Jahr als Gehaltsanteil versilberte, das also kein
besonderes Verhalten war, dann wird man ihm wohl keinen Strick draus
drehen können. Und wenn er das Geld nachvollziehbar für ein schon eine
Weile geplantes privates Projekt braucht evtl. auch nicht.
A. K. schrieb:> Denn "kauft sofort einen neuen Prozessor,> aber keinesfalls von uns" bringts irgendwie nicht, oder? ;-)
Ich habe das nur im Radio gehört und das sagten sie, dass Intel schon
neue Prozessoren hätte, die diese Sichereitslücke nicht hätten. Deshalb
schrieb ich das überhaupt.