Login
Newsletter
Werbung

Thema: Red Hat zieht Microcode gegen Spectre 2 zurück

24 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Potz Blitz am Mo, 22. Januar 2018 um 14:26 #

... oder spielt das nächste dnf update die Firmware von alleine wieder zurück? Wahrscheinlich doch letzteres, oder?

0
Von schmidicom am Mo, 22. Januar 2018 um 14:46 #

Die Rücknahme von Intels Microcode begründet Red Hat damit, dass mit diesem Microcode Rechner von Kunden sich nicht mehr starten ließen oder spontane Neustarts durchführten.
Als akzeptable Erklärung geht das zwar gerade noch so durch, aber nicht wenn dann gleich folgendes kommt:
Red Hat bittet Kunden, die nun keinen Schutz gegen Spectre in Variante 2 mehr haben, sich »an ihren Erstausrüster zu wenden, um die aktuelle Version Microcode/Firmware für ihren Prozessor herunterzuladen«.
Mal davon abgesehen das viele Hersteller sowieso keinen Bock haben Microcode-Updates auszuliefern, worin genau liegt jetzt bitte der Unterschied darin ob der Rechner wegen einem Microcode-Update vom OS- oder Hardware-Hersteller spontan rebootet?

EDIT:
Der einzige Unterschied den ich erkennen kann liegt darin das bei einem durch die spontanen reboots verursachten Daten/Zeit/Geld-Verlust RedHat rechtlich gesehen jegliche Verantwortung zurückweisen kann...

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Jan 2018 um 15:06.
  • 1
    Von jpsh am Mo, 22. Januar 2018 um 14:57 #

    Steht doch da?!

    "Da man im Moment über kein komplettes Repositorium aller aktuellen Microcodes verfüge, sei es für Kunden einfacher, sich an die OEM-Partner zu wenden um dort die aktuellste Version zu erhalten. Robinson fuhr fort, Red Hat habe nicht für alle bei den Kunden verwendeten Prozessoren aktuelle Microcode-Versionen erhalten."

    1
    Von Micha244 am Mo, 22. Januar 2018 um 14:58 #

    Der Kunde weiss, wer den Schaden verbrochen hat.
    Hersteller / Projekte von Distributionen sind immer in einer blöden Lage, wenn die Primär-Hersteller nur Datenhaufen liefern.
    Vielleicht ein Anlass, dass Grosskunden den Primär-Lieferanten mal richtig auf die Füsse steigen. In keiner anderen Branche würde man so ein "Garantie"-Verhalten durchgehen lassen.

    • 1
      Von Kenner der Szene am Di, 23. Januar 2018 um 10:01 #

      "Der kunde weiß wer den Schaden verbrochen hat"

      Jop, und die Zahlen nichts - auch keinen Arbeitsausgleich. Na ja, wer den Schaden hat muss für den Spott nicht sorgen: After you have spend nights of installing patches against spectre and then they are revoked by Intel

      0
      Von scholle2 am So, 28. Januar 2018 um 17:55 #

      "In keiner anderen Branche würde man so ein "Garantie"-Verhalten durchgehen lassen."

      Da irrst du gewaltig, oder wie ist das mit den Stickoxiden bei den Diesel-PKW?
      Hier wurde und wird sogar vorsätzlich betrogen !!!

      • 0
        Von DieGesellschaftDerArkanoiden am Do, 1. Februar 2018 um 22:15 #

        Da irrst du gewaltig, oder wie ist das mit den Stickoxiden bei den Diesel-PKW?
        Mit dem zentralen Unterschied, dass das Produkt in einem Kernleistungsmerkmal teilweise stark entwertet wird: Geschwindigkeitseinbußen bis zu 30% wurden gesichtet.

        Der Manipulationsskandal in der Autobranche betrifft nicht ein Kernleistungsmerkmal, sondern die Schadwirkung auf Tier und Umwelt. Was im Zweifel sicher noch schlimmer ist, aber nicht zentral in Bezug auf den Produkteigentümer.

        Hier wurde und wird sogar vorsätzlich betrogen !!!

        Meine Arbeitshypothese setzt beim Prozessorschmied mit dem I im Namen an: immerhin haben sie gegenüber dem A-Prozessorschmied Geschwindigkeit rausschlagen können wegen fehlender Prüfungen.

1
Von tom2 am Mo, 22. Januar 2018 um 15:11 #

Warum rauscht der Kurs der Intel-Aktie eigentlich nicht in den Keller (plus die der Intel verbauenden Hersteller)? All diese Firmen müsste doch komplett ruiniert sein (egal, ob die Enesa etwas damit zu tun hat)? Entschuldigt bitte meine naiven Fragen, aber ich bin Informatiker und kein BWLer. Intel hat doch den absoluten Super-GAU abgeliefert, oder?

Wie geht es jetzt weiter? Eigentlich müsste man doch sämtliche Rechner mit den betroffenen CPUs auf den Schrott werfen. Was bleibt da noch? Die Chinesen haben MIPS und mit Zhaoxin ein eigenes x86-Design. Aber da weiß auch keiner, was wirklich drin steckt. Eigentlich müsste das jetzt die Stunde der freien und offenen Designs sein. Man hört aber nichts. Was tun?

  • 1
    Von Potz Blitz am Mo, 22. Januar 2018 um 15:36 #

    Warum rauscht der Kurs der Intel-Aktie eigentlich nicht in den Keller?
    Etwas nachgegeben hat er nach Bekanntwerden der Lücken schon. Allerdings ist fraglich, ob Schadensersatzansprüche gegen Intel geltend gemacht werden können. Gegen diese Schadensansprüche spricht, dass
    1. die Prozessoren ja weiterhin funktionieren, nur eben weniger sicher;
    2. andere Hersteller auch betroffen sind, die Fehler also "State of the Art" sind;
    3. Intel die Fehler vermutlich nicht fahrlässig oder gar absichtlich verursacht hat.

    Intel könnte sogar profitieren, nämlich dann wenn schnell fehlerkorrigierte Produkte verfügbar sind und sich der Imageverlust in Grenzen hält.

    Viele Betreiber und Nutzer (besonders von Cloudservern) suchen jetzt bestimmt händeringend neue Hardware. Das muss für die Branche nicht unbedingt schlecht sein.

    2
    Von Felix Schwarz am Mo, 22. Januar 2018 um 15:38 #

    Technisch: Gerade meltdown ist zwar schwerwiegend und praktisch Intel-only (+ ein paar high-end ARM-Chips), aber relativ leicht zu fixen. Die Geschwindigkeitseinbußen sind bei den meisten Anwendern (inkl. Rechenzentren) relativ gering.

    spectre betrifft aber fast alle, auch wenn mir die Schwere der Auswirkungen bei AMD nicht ganz klar ist. Spectre ist aber letztlich ein Architekturproblem, Angriffe müssen gegen konkrete Applikationen geschrieben werden und Applikationen müssen einzeln abgesichert werden.
    Auch hier gibt es aber Compiler-Patches usw. und Google wähnt sich auch hier schon sicher (ohne großen Performance-Einbruch!).

    Last but not least: In vielen Rechenzentren sind die Bugs gar nicht relevant, weil kein externer Code läuft - ich glaube kaum, dass z.B. Facebook sich mit irgendjemandem ihre Server teilt.

    Insofern sieht es im Moment nicht nach einer dauerhaften "Intelpocalypse" aus.


    Ökonomisch: Ein Umstieg auf eine andere Architektur ist illusorisch, auf dem Desktop wie im Rechenzentrum. Dafür gibt es zu viel bestehende Software, die nicht einfach kompiliert werden kann bzw. die dann auch noch fehlerfrei auf den anderen Architekturen funktioniert. Ein Architekturwechsel ist extrem langfristig zu machen, eher etabliert sich eine Architektur für neue Nischen (z.B. ARM -> Mobilgeräte).

    Es bleibt realistisch also nur x86/AMD. Aber selbst so ein Wechsel ist nicht einfach: Erst mal müsste AMD überhaupt entsprechende Volumina liefern können (können sie aber nicht, kurzfristig Produktion erhöhen ist auch nicht, siehe Grafikkarten).

    Zum anderen hängt bei den großen Kistenschiebern recht viel an einem System dran. Einen neuen Prozessor von AMD aufzunehmen, bedeutet viel Arbeit im Bereich der Validierung, Treiberbereitstellung, Tests usw. Dort sind auch viele low-level Werkzeuge im Einsatz, die im Moment nur mit Intel-System funktionieren. Oftmals werden auch ähnliche/gleiche Boards mit unterschiedlichen CPU-Varianten bestückt. => Mehraufwand für die ersten AMD-Systeme.

    Die Epyc-Systeme werden natürlich vorbereitet, weil es wohl viel Kundennachfrage gibt und sie verkaufen sich offenbar auch sehr gut, aber Rechenzentren kaufen ja idR gut validierte Hardware und Validierung/Tests dauern halt.

    Insofern sieht es gut aus für AMD, aber Intel wird schon noch seinen Quartalsgewinn machen...

    1
    Von Anonymous am Mo, 22. Januar 2018 um 15:43 #

    Börsenheinis interessieren sich nicht für Vergangenheit oder Gegenwart, sondern für die (nahe) Zukunft. Da sie wissen, dass die Intel-Konkurrenz gar nicht in der Lage ist, eine sprunghaft steigende Nachfrage zu befriedigen (auch die Boardhersteller und Chipsatzhersteller können ja nicht einfach so auf einen anderen Pozessoranbieter umschwenken) gehen die wohl zu recht davon aus, dass die Kunden auf kurze Sicht weiterhin Intel kaufen MÜSSEN.

    Vermutlich sogar ohne nennenswerten Peisnachlass wegen der kaputten Prozessoren.

    Intel wird zwar mindestens ein Jahr brauchen, um gegen Meltdown und Spectre abgesicherte Prozessordesigns in grösseren Stückzahlen auf den Markt zu bringen, aber "freie und offene Designs" werden in ein oder zwei Jahren kein Bein an die Erde bekommen.

    Was die meisten Kunden also tun werden: erneut "Intel inside" kaufen.

    1
    Von Felix Schwarz am Di, 23. Januar 2018 um 09:44 #

    PS:

    Die Chinesen haben MIPS und mit Zhaoxin ein eigenes x86-Design. Aber da weiß auch keiner, was wirklich drin steckt.

    Wie Golem gerade berichtet, sind die CPUs von Zhaoxin ebenfalls von Spectre betroffen.

    Das bestärkt mich noch mal in meiner Einschätzung: Ein Wechsel auf irgendetwas anderes als x86_64 ist unrealistisch und alle x86-Hersteller sind von Spectre betroffen, insofern kein dramatisches Problem für Intel.

1
Von Condor am Mo, 22. Januar 2018 um 16:08 #

Ich selbst habe das mit den reboots ja hier erleben dürfen, schön geht anders. Aber mal ehrlich, jetzt soll doch nicht etwa Dell den Microcode liefern. Das wird niemals geschehen. Mir reicht schon das Thema ME und die nicht einspielbaren Biosupdates. Zumal sich Redhat nicht dazu äußert wie es um den Support steht, da steht was in der Subskription drin. Wer haftet?

  • 1
    Von Anonymous am Mo, 22. Januar 2018 um 18:34 #

    Nun ja, Vertragspartner des (End-) Kunden ist Dell. Wenn Dell von vielen Kunden Druck bekommt (die Kunden also Ansprüche bei Dell anmelden), kann Dell versuchen, den Druck an seinen Lieferanten/Vertragspartner Intel weiterzugeben.

    Insofern ist das schon der formal richtige Weg, denn RedHat ist ja nur Mittler, wenn es Intel-Patches weiterreicht.

1
Von Namenlos am Mo, 22. Januar 2018 um 16:51 #

openSUSE hat für Leap 42.2 & 42.3 das Paket ucode-intel-20180108-7.12.1.x86_64 sowie ucode-intel-20170707-7.9.1.x86_64 ebenfalls zurückgezogen.

Aktuell ist jetzt: ucode-intel-20170707-7.6.1.x86_64

0
Von Atalanttore am Fr, 26. Januar 2018 um 15:50 #

Welche Prozessoren benötigen zur Funktion keine verschlüsselte und signierte Firmware vom Hersteller?

0
Von Bruddelsuppp am So, 28. Januar 2018 um 10:19 #

Man kann als ein solches Unternehmen fast nur verlieren.

Ein Fazit könnte sein, sich beim Patchen doch mehr Zeit zu nehmen und irgenwann andere Architekturen zu unterstützen.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung