Das längste Thema

  • Guten Morgen,



    die hier geschilderten Szenarien betreffen eine gesamte Branche. Wie zu erwarten gehen Spekulationen los. Die Intel-Aktie ist direkt um 7% gefallen. Krass!


    In einer solchen Situation ist es wichtig sich an Fakten zu halten:


    Es wird Updates für die Kernel geben. Wie unsere Mitbewerber werden wir diese einspielen, sobald uns diese zur Verfügung stehen. Es deutet vieles darauf hin, dass dafür ein Reboot der Nodes erforderlich ist. Sobald wir hier einen Termin nennen können, werden wir diesen per E-Mail allen betroffenen Kundinnen und Kunden mitteilen.


    Hinsichtlich der Leistungseinbußen rechnen Experten bei neueren CPUs, so wie wir sie einsetzen, mit ca. 5% Leistungseinbußen. Die bis zu 30% gelten, laut Experten, für alte CPU-Modelle. Das sind allerdings auch alles Angaben, die spekulativ sind. netcup hat auf allen Nodes für Root-Server im Schnitt deutlich mehr als 5% freie CPU-Ressourcen. Kerne werden im Schnitt zu weniger als 60% ausgelastet. Bei Root-Servern wird der Patch sich also voraussichtlich nicht bemerkbar machen. Einzig bei den sehr günstigen VPS-Produkten kann es nach den Berechnungen weniger CPU-Leistung geben. Das ist übrigens bei vielen Mitbewerbern so, welche die gesamt verfügbare CPU-Leistung auf die VPS aufteilen und keinen großen Puffer eingerechnet haben.


    netcup wird alles dran setzen um die Auswirkungen für Sie als Kundinnen und Kunden so gering wie möglich zu halten. Sicherheit ist natürlich das A und O bei netcup. Wir tun sehr viel dafür.


    Updates werden wir zeitnah bekannt geben.



    Mit freundlichen Grüßen


    Felix Preuß

  • ein Reboot der Nodes erforderlich ist

    Ich denke eher, dass innerhalb von 72 Stunden über die Hälfte "des Internets" neu gestartet werden muss...


    Kann man nur hoffen das AWS und Co das ohne Downtime hinbekommen, ansonsten werden das spaßige Tage.

  • Und hier kurz zur vereinfachten technischen Erklärung:


    Es spielen hier drei Systeme moderner CPUs (auch AMD und ARM) eine Rolle:

    1. Virtueller Speicher: Jeder Speicherzugriff eines Prozesses wird von der CPU Memory Einheit (MMU) umgewandelt auf eine echte Adresse. Außerdem prüft die MMU auch ob der Speicherzugriff erlaubt ist.

    2. Cache: Jeder Prozessor hat einen sehr schnellen Speicher direkt neben dem Core - dieser puffert den Inhalt des Speichers, somit kann häufig gelesener Speicher schneller gelesen werden - sogar ohne Zugriff auf den Memory Bus.

    3. Out of Order Execution: Moderne CPUs führen mehrere Programmzeilen gleichzeitig aus, auch welche die eventuell garnicht dran kommen oder erlaubt sind.


    So, und nun zur Pseudo Erklärung:

    Mein Prozess hat seinen eigenen Speicher (fiktive Werte!!) der geht von 0x00000000 - 0x80000000 und gleichzeitig auch den kompletten (geheimen) Kernel Speicher von 0x80000001 - 0xFFFFFFF. Die MMU verbietet mir aber (als Userspace Prozess ohne Systemrechte) jeglichen Lesezugriff auf alle Speicherseiten ab 0x80000001. So muss das sein.

    Jetzt macht mein Programm folgendes:

    1. Leere den kompletten Prozessor-Speichercache.

    2. Erzeuge dir eine legalen Speicherbereich, z.B. von 0x10000000 und nenne diesen A.

    3. Lese von der verbotenen Adresse 0x80001000, das Ergebnis ist B. Nehmen wir an wir bekämen hier: 0x25

    -> ANMERKUNG: Der Schritt 3 wird ausgeführt werden (Out of Order Execution) aber das Ergebnis wird nicht zurückgegeben werden weil das lesen dieser Adresse ja verboten ist.

    4. Schreibe das Ergebnis an die Adresse A + B, also in unserem Fall 0x10000025. Auch diese Anweisung ist nicht erlaubt, wird aber (Out of Order Execution) ausgeführt werden.

    5. Nun lesen wir von Adresse 0x10000000 und schauen wir schnell die Antwort kommt - kommt sie sehr schnell so war B und damit der Inhalt der verbotenen Adresse 0x00.

    6. Jetzt fangen wir wieder bei 1 an, nur lesen wir diesmal im Punkt 5 nicht von 0x10000000 sondern von 0x10000001 und messen auch hier wieder die Zeit.

    7. Wir erhöhen jetzt jedesmal die Adresse um 1, bis wir irgendwann feststellen dass wir bei 0x10000025 plötzlich sehr schnell lesen können.

    Damit wissen wir also: B war 0x25 - weil die CPU die entsprechende Adresse des Speichers im Cache hat!


    In der Realität wird übrigens bei Punkt 4 nicht einfach A+B gerechnet sondern es wird multipliziert, also eher A+(B*4096) - weil die CPU immer Page weiße cacht, also 4096 Bytes auf einmal. Bei Punkt 6 wird dann entsprechend nicht um 1 erhöht sondern um 4096 - das Prinzip ist aber das gleiche.


    Die recht ähnliche Spectre Attacke läuft nach einem ähnlichen Schema ab, nur wird hier der Speicher eines anderen Prozesses ausgelesen indem man ihn dazu bringt von einer verbotenen Adresse mit Out of Order Execution zu lesen.


    Quelle Meltdown: https://meltdownattack.com/meltdown.pdf

    Quelle Spectre: https://spectreattack.com/spectre.pdf

  • Kann man nur hoffen das AWS und Co das ohne Downtime hinbekommen, ansonsten werden das spaßige Tage.

    Laut Chip eher nicht...

    Zitat

    Amazon und Microsoft haben für ihre großen Cloud-Plattformen Azure und AWS bereits Sicherheitsupdates angekündigt, die im Laufe dieser und der kommenden Woche auf allen Geräten mit einem Neustart aktiviert werden

  • moin moin,


    nachdem ich mich dann gestern auch n bisschen belesen habe, gehe ich gelassen mit der Sache um. Ich kann eh nichts anderes tun. Der Leistungsverlust wird nicht so dramatisch ausfallen, wie Felix ja schon schrieb. Irgendwo in diesem Internet hab ich da schon Benchmarks gesehen, die das unterstreichen (man testete mit schon gepatchtem Linux). Von daher: abwarten und Tee trinken. Und: Keine Panik! :)

  • Kann man nur hoffen das AWS und Co das ohne Downtime hinbekommen, ansonsten werden das spaßige Tage.

    Meine Kollegen meinten, sie bekommen in der AWS Konsole den Hinweis, dass wenn sie "jetzt" einen Neustart machen, die Instanzen auf eine gepatchte Umgebung geschoben werden. Ansonsten kommt ein Neustart, ausgeführt von AWS demnächst (die Details wie Uhrzeit sind uns bekannt).

  • Ich antworte einmal hier, sonst wird es drüben wirklich zu sehr Offtopic.

    wenn man "standardmäßig" darauf reagiert. Aber das deaktivieren des Standardverhaltens ist z.B. mit einer Zeile in der grub.conf erledigt. Zudem könnte man sich sicherlich auch ein Skript basteln was den Shutdown Prozess anhält/beendet und per E-Mail benachrichtigt.

    Das erfordert aber mindestens einen weiteren Neustart und ein wachsames Auge. Will man den Shutdown-Vorgang künstlich verzögern oder selbst auf die ACPI-Signale reagieren, wird es noch deutlich aufwändiger. Letzteres würde wieder aufwändige Tests benötigen, bevor man es auf ein Produktivsystem loslassen kann.


    So oder so ist das mit dieser kurzen Vorlaufzeit wahrscheinlich wenig praktikabel. Da kann man sich gleich zurücklehnen und auf das Beste hoffen… :D

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bei den derzeitigen Diskussion habe ich immer so ein wenig den Eindruck, dass sich viele nicht so richtig bewusst sind, was es heißt, seine Applikationen und Server in der Cloud zu betreiben. Meiner Meinung sollte bzw. müssen solche Systeme zu jedem Zeitpunkt einen automatischen Neustart verkraften können. Dies gilt (und meiner Meinung nach besonders) für produktive Umgebungen, da ein Ausfall ja grundsätzlich immer mal passieren kann. Ist Verfügbarkeit wichtig, so sollte man eben auch horizontal skalieren können.


    Aber vielleicht ist das ja mal ein guter Zeitpunkt seine Umgebungen so zu überarbeiten, dass es das nächste Mal weniger Sorgen gibt :-).

  • My 2 ¢: Es geht (mir) nicht um den automatischen Neustart, den überleben (meine) Systeme schon. Es geht mir rein darum, dass man bei manuellen "Wartungsarbeiten" am System nicht von einem extern ausgelösten Neustart überrascht werden möchte. Ein Absturz ist eine Sache, aber ein geplanter Neustart sollte dem Sysadmin schon bekannt sein, um während dieser Zeit nichts einzuplanen.


    Oh, jetzt hätte ich meinen 6000. Beitrag fast übersehen… 8|

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich kann für mich soviel sagen: jede Besonderheit, die meine Systeme beim Start haben, teste ich gründlich auf ihre Funktionstüchtigkeit, auch wenn ich diese 1:1 von funktionierenden Systemen kenne. Und das ist gut so, ich hab da schon spannende Effekte erlebt. Aber ja, ich möchte auch nicht gerade an ner Sache arbeiten und plötzlich rebootet der Server. Ihr habt BEIDE Recht. :)