1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Intel - Hardwarebug

Dieses Thema im Forum "Geplauder, Fun und Chillzone" wurde erstellt von mogbo, 3 Januar 2018.

  1. mogbo

    mogbo Does it run under Windows? Who cares?

    Registriert seit:
    12 September 2016
    Beiträge:
    722
  2. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.163
    Vermutlich müssen die BSDs ebenfalls Kernel Page Isolation im Stil von Linux und Windows implementieren. Ansonsten kann man ja nicht viel dagegen tun. Da es aber im Zusammenhang mit (K)ASLR erwähnt wird, weiß ich nicht inwieweit das dann z.B. in FreeBSD möglich ist, da dort kein (K)ASLR in der Form enthalten ist.

    Dann werden halt in 2018 alle (sicheren) Intel Server demnächst etwas langsamer. Aber zumindest unter Linux hat AMD noch keine Ausnahme erhalten. Kernel 4.14.11 bremst auch AMD-CPUs.
     
    mogbo gefällt das.
  3. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    9.182
    Ort:
    Schleswig-Holstein
    Hier: https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068021.html

    Weiter unten in dem Thread sagt Warner Losh dann auch:
    Davon mal abgesehen sind 5% bis 30% Performance Hit hart. Da werden sich viele Nutzer 3x überlegen, ob sie den Work Around aktivieren oder nicht doch lieber mit dem Risiko leben.
     
    mogbo gefällt das.
  4. mogbo

    mogbo Does it run under Windows? Who cares?

    Registriert seit:
    12 September 2016
    Beiträge:
    722
    Verstehe die Angabe nicht wirklich, spricht das dann für einen Leistungsverlust von 5-30 % der gesamten CPU oder erhöht sich die Rechendauer der CPU um 5-30 %.

    Mit einem Gesamtleistungsverlust, der sich nicht auf die Dauer auswirkt könnte ich leben, jedoch mit einer höheren Rechenzeit von über 10 % könnte selbst ich als Privatperson an gewissen Ecken nicht leben.
     
  5. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.163
    Im Linux-Fall muss man den Work-Around deaktivieren, da er standardmäßig eingeschaltet wird.

    Anders ausgedrückt: Du verlierst 5-30% Leistung je nachdem was du tust. Die Angabe von den Linux-Kernel-Entwicklern ist "5% im Normalfall". In Micro-Benchmarks bis zu 50%, aber das sind halt Micro-Benchmarks.
     
  6. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    9.182
    Ort:
    Schleswig-Holstein
    So wie ich es verstehe wird jeder Sprung zwischen dem Userland und dem Kernel teurer, da ein Mapping eingefügt wird, um den Userland-Teil und den Kernel-Teil des Adressraums eines Prozesses komplett zu trennen. Das würde bedeuten, dass Syscalls und (Hardware) Interrupts teuerer werden. Wie sehr es ein Programm trifft hängt davon ab, wie viele Syscalls es nutzt. Grundsätzlich ist unixoide Software aber sehr syscalllastig, da fast alle durch das Betriebssystem bereitgestellte Funktionalität letztendlich durch Syscalls implementiert wird. Solange ein Programm nur rechnet, dürfte der Performanceverlust also eher gering sein. Sobald es aber zu Dingen wie IO kommt, dürfte der Performanceverlust relativ groß sein.

    Letztendlich hat AMD den Bug sozusagen geleakt, weil die Linux-Entwickler das für den Work Around genutzte "Kernel page-table isolation" (ehemals "KAISER") mit der Gießkanne für alle x86-CPUs aktiviert haben. Daraufhin hat AMD einen Patch eingericht, der es auf Intel-CPUs beschränkt und sehr deutlich darauf hingewiesen, dass man doch bitte nicht gar nicht betroffene CPUs verkrüppeln möchte. Das war schon eine recht deutliche Reaktion, die stark dafür spricht, dass die Auswirkungen nennenswert sind. Abschalten kann man es übrigens, indem man dem Linux-Kernel die Option "nopti" übergibt.

    Genau wissen wir es aber alles erst, wenn das Embargo gefallen ist. Dann kann man sicher auch besser einschätzen, wie groß das Risiko ist und eine fundierte Entscheidung treffen.

    EDIT: Missverständliche Formulierung geändert
     
    double-p gefällt das.
  7. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.163
  8. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    9.182
    Ort:
    Schleswig-Holstein
    PCID gibt's ja ab Westmere, also dürfte der Performance Hit sich dann in der Praxis doch in Grenzen halten.
     
  9. midnight

    midnight OpenBSD

    Registriert seit:
    1 Januar 2007
    Beiträge:
    376
    Noch nicht. Soweit ich gelesen habe, sind Details der Sicherheitslücke sind noch nicht veröffentlicht worden und werden unter Verschluss gehalten. Nur ein ausgewählter Kreis hat Zugang dazu. Dazu gehören die BSD's meines Wissens nach nicht. Korrigiert mich bitte, wenn ich falsch liege.
     
  10. mogbo

    mogbo Does it run under Windows? Who cares?

    Registriert seit:
    12 September 2016
    Beiträge:
    722
    Theo ist ja dafür bekannt Patches nicht zurückzuhalten und OpenBSD ist bekannt für schnelle Reaktionen auf Security-Probs. Denke sowas spricht schon alleine gegen die Infoweitergabe an OpenBSD.

    kA wies bei anderen *BSDs aussieht
     
  11. SolarCatcher

    SolarCatcher Active Member

    Registriert seit:
    24 August 2006
    Beiträge:
    754
    Nachdem die OpenBSD'ler die Embargo-Deadline für KRACK nicht eingehalten haben, werden sie vermutlich solche Infos nun später erhalten, wenn die anderen großen Häuser 'genügend' Zeit für ihre Patches hatten. Das war Theo und den anderen auch durchaus bewusst.

    Dass FreeBSD aber nicht frühzeitig einbezogen wird, kann ich mir kaum vorstellen. Intel ist gerade zu einem großen Sponsor der Foundation geworden und präsentiert sich als Freund von FreeBSD. Und mit einem Schwergewicht wie Netflix (was waren es: zu Stoßzeiten angeblich über 1/3 des Internet-Traffics in den USA) schiene es törricht, FreeBSD außen vorzulassen (jaja, Netflix macht auch ganz viel über AWS = Linux).

    Ich würde jedenfalls tippen, dass FreeBSD mit der Veröffentlichung der Details auch Patches bereit haben wird.
     
  12. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    9.182
    Ort:
    Schleswig-Holstein
    Unabhängig davon, ob FreeBSD Patches haben wird oder nicht, könnte dieser Bug aber wieder neuen Wind in die inzwischen sehr verhärtete Diskussion um (K)ASLR in FreeBSD bringen. Und das ist dann sogar ein positiver Nebeneffekt. :)
     
  13. mogbo

    mogbo Does it run under Windows? Who cares?

    Registriert seit:
    12 September 2016
    Beiträge:
    722
    Sollte man nicht hier eher nach KARL schreien?
     
    CrimsonKing gefällt das.
  14. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    9.182
    Ort:
    Schleswig-Holstein
    Ich weiß es nicht genau, da ich mich nicht im Detail mit KARL beschäftigt habe, aber es könnte gute mit FreeBSDs Policy stabile APIs anzubieten inkompatibel sein.
     
  15. mogbo

    mogbo Does it run under Windows? Who cares?

    Registriert seit:
    12 September 2016
    Beiträge:
    722
    KARL heißt der Kernel liegt in einer Randomanordnung immer an der gleichen Position im Speicher (macht wohl der Linker irgendwie)
    (K)ASLR heißt der gleiche Kernel liegt an einer Randomposition
    Kombination scheint mittlerweile ganz gut machbar

    Liegt eventuell auch daran, dass man ein System mit KARL leichter zu einem vollständigen Systemcrash bringen kann (ROB Attacks), was einen Neustart mit neuem Kernel zur Folge hat (gutes Sicherheitskonzept, kann aber in der Praxis sehr schädlich sein)

    (K)ASLR scheint wohl nicht so schwer auszuhebeln zu sein, aber definitiv besser als ohne und ein Schritt in die richtige Richtung

    Ob das zu instabilen APIs führt entzieht sich völlig meinem Halbwissen :)
     
  16. mogbo

    mogbo Does it run under Windows? Who cares?

    Registriert seit:
    12 September 2016
    Beiträge:
    722
  17. ralli

    ralli BSD Fanboy

    Registriert seit:
    1 Juni 2012
    Beiträge:
    2.339
    Die hier angesprochenen Performanceverluste scheinen eher hochspekulativ zu sein, sie werden von Intel vehement bestritten.
     
  18. mogbo

    mogbo Does it run under Windows? Who cares?

    Registriert seit:
    12 September 2016
    Beiträge:
    722
    Die Quelle ist ein Zitat aus einem gesperrten Forum ohne Quellangabe, also man kanns glauben oder nicht:

    "Raw numbers are hard to find due to the secretive nature of these patches, but here are some basic benchmark impacts we've seen so far:

    Linux, on an i7 6700, calling the getpid syscall 100,000,000 times:

    Before the patch: ~3.8 seconds.
    After the patch: ~15 seconds.
    PostgreSQL, a database application, i7-6820HQ, SELECT 1 benchmark:

    Before the patch: 420490.162391 transactions per second
    After the patch: 350746.065039 transactions per second"

    Intel geht wohl in Richtung:
    https://i.imgur.com/Ed2jtn2.jpg
     
  19. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    9.182
    Ort:
    Schleswig-Holstein
    Die Details finden sich her: https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

    Das ist schon sehr übel. Meltdown ist sicher deutlich akuter als Spectre, Spectre und Abwandlungen haben aber das Potential noch auf Jahre eine Dauerkatastrophe darzustellen. Ich könnte mir gut vorstellen, dass man in 20 Jahren zurückschaut und sagt, dass der 04. Januar 2018 für die IT-Branche das war, was der 26. April 1986 für die Nuklearindustrie war.

    Und Intel. Was sollen sie denn machen außer sich rausreden? Ihr offizielles Statement liest sich, als ob daran 30 Anwälte einen ganz Tag lang formuliert haben. Grundsätzlich zugeben, dass es ein Problem gibt, gefolgt von einer ganzen Reihe Relativierungen und Beschwichtigungen. Meltdown hat das Potential für Intel sehr, sehr teuer bis sogar existenzbedrohend zu werden. De facto alle Intel-CPUs werden durch das nun notwendige Mapping zwischen Kernel- und Userspace drastisch langsamer werden, sowas ist in den USA milliardenschwere Class Action Lawsuits wert. Großabnehmer wie Amazon oder Google werden sich das ebenfalls kaum gefallen lassen und es zum Anlass nehmen hohe Rabatte zu verlangen. Dazu kommt der Image-Schaden, der schnell gigantisch werden kann.

    Natürlich ist es unfair. CPUs sind hochkomplex, es hätte jeden anderen Hersteller in dem Maß wie Intel treffen können. Und wird es vielleicht noch. Aber das Leben ist nun mal nicht fair und genauso wie VW die Arschkarte in Sachen Diesel gezogen hat, hat Intel es für löchrige CPUs getan.
     
  20. CrimsonKing

    CrimsonKing Systemzerstörer

    Registriert seit:
    9 März 2012
    Beiträge:
    1.681
    Das wurde in OpenBSD ja inzwischen recht ausgiebig ausprobiert. Wie so oft. :)

    Plot Twist: Von wenigstens Teilen von Meltdown/Spectre sind nach jetzigem Stand Prozessoren von AMD und Intel ebenso betroffen wie ARM und POWER, außerdem wohl auch SPARC (letztere allerdings, wenn ich das richtig verstehe, "nur" Spectre, nicht Meltdown).

    Nicht betroffen: VAX. :D
     
  21. ralli

    ralli BSD Fanboy

    Registriert seit:
    1 Juni 2012
    Beiträge:
    2.339
    Ok, ich habe ja nicht abgestritten, das es ein Problem ist, dessen Ausmaß möglicherweise noch nicht vollumfänglich überblickt werden kann. Auch ist unstrittig, das es Leistungseinbußen geben wird. Ob das aber bis zu 35% sein dürften oder können, werden belastbare Benchmarks ergeben. Und das Großkonzerne gerne beschwichtigen und abwiegeln, dürfte auch der Normalfall sein. Erst wenn sie juristisch in die Enge getrieben werden und der Druck im Kessel zu hoch wird, wird man zu Zugeständnissen mit möglicherweise zweifelhaften Kompromissen bereit sein. Wie gut, das wir nicht alle Fehler kennen ..... wenn ich technisch versierter wäre, stände mir vielleicht auch der Angstschweiß auf der Stirne.;)
     
  22. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.163
    "SELECT 1" ist kein realistischer Benchmark. Bei realistischen Workloads ist der Performance-Verlust weit geringer.
     
  23. ralli

    ralli BSD Fanboy

    Registriert seit:
    1 Juni 2012
    Beiträge:
    2.339
    In meinem Rechner ist dieser Intel i7 4790k 4x4 GHz verbaut, ist der auch betroffen? Ich habe gegoogelt, aber nichts gefunden.
     
  24. -Nuke-

    -Nuke- Well-Known Member

    Registriert seit:
    25 Juli 2004
    Beiträge:
    1.163
    Alle Intel CPUs seit 1995 sind betroffen.
     
  25. ralli

    ralli BSD Fanboy

    Registriert seit:
    1 Juni 2012
    Beiträge:
    2.339
    Aha, danke @-Nuke- .