Mit Verlaub, es kann doch nicht sein, dass Intel keinen Masterplan hat, aus dem hervorgeht, wann man gedenkt die aktuelle Core-Architektur hinsichtlich, der bekannten Sicherheitslöcher zu überarbeiten!?
Doch kann es... Denn es gibt für Teile der gefundenen Themen keine technisch mögliche Lösung. Etwas, was by Design Probleme macht ist nicht technisch verhinderbar.
Da sind Sachen bei, wo Software Laufzeiten ermittelt und dadurch Cache-Inhalte rekonstruiert, weil ein Cachehit weniger Zeit kostet als die Daten aus dem lahmen RAM zu holen. Das kann man nicht verhindern. Nur hat bis dato keiner soweit gedacht. Die Konsequenz wäre, jegliche Parallel-Ausführung von irgendwelchen Teile des Programmcodes aktiv zu unterbinden. DAS wiederum kann man machen, aber der Speednachteil wäre aus meiner Sicht nicht mehr mit dem heutigen Leistungsanforderungen unter einen Hut zu bringen. Steht auch im völligen Gegenteil zum Multithreading bisher. Heist, 1T CPUs und alles schön eins nach dem anderen in einer zu 100% fix vorgegebenen Reihenfolge.
Wenn Kritik Deiner Meinung nach nicht angebracht ist, soll man sich denn hinstellen und sagen: Shit happens. Weiter so! Als ob sich damit jemals irgendein Problem hätte lösen lassen.
Kritik ist wichtig und auch notwendig... Aber man sollte einerseits die Kirche im Dorf lassen und andererseits nicht den Fehler begehen, so stark auf diese Umstände schauen, dass man auf dem anderen Auge völlig erblindet.
Genau das wird hier aber permament gemacht. Wenn man das zugrundeliegende Problem versteht (und das schaffen schon nicht viele hier) dann versteht man auch, dass Teile der Lücke schlicht bei Design so sind. Es gibt keine Lösung für diese Themen. Egal wie sehr man das fordert.
Am Ende über bleibt irgend so ne Stammtisch-Debatte über "meine Firma ist aber besser als deine" - kein Schwein interessiert sich dafür. Nur die Laberbacken heizen das Thema immer wieder an. Würde es den Leuten um Security gehen, würde man an den großen Baustellen ansetzen, die CPU Thematik ist vergleichsweise überschaubar, weil extremst spezifisch.
1) Doch, die Frage stellt sich
2) Wenn die Mathematik nicht gerade von dir neu erfunden wird, ist die Differenz zwischen mitigierter und unmitigierter Testsituation weiterhin eine Differenz. Exakt aus diesem Grund kann gemessen werden und deshalb wird auch gemessen - denn die Differenz ist kausal.
3) Nach Adam Ries sind 100% - 10% = 90%. Um von 90% wieder auf 100% zu kommen, musst du: 1/0,9 = x also x=11% wieder draufpacken. Setzt du die 0,9 als 100%, wäre der "Gewinn" aus der unmitigierten Testsituation 11%. Wir lernen: Je nachdem was du als Referenz auswählst, haben wir unterschiedliche Relationen: 10% Verlust oder 11% Gewinn. (Exakte Durchschnittwerte können in den Reviews erlesen werden)
Und was möchtest du jetzt mit dieser Zahl bezwecken?
Du bekommst dadurch den relativen Anteil an Leistungsverlust durch die Mitigation. Nur nach diesem hat keiner gefragt... java4ever fragte sich, ob Intel nur schneller war, weil die Architektur löchrig ist/war. Und genau diese Frage stellt sich nicht, weil bisherige Hardware-Mitigations ohne Leistungsverlust ggü. den anfälligen CPUs gleicher Grundarchitektur einher gehen. Und selbst das ist nur die halbe Wahrheit, weil Intel in dem Fall reagierte und nicht proaktiv eine Lösung erschaffen hat um etwas sicherzustellen. Die Proaktive Lösung hätte womöglich sogar Leistung gekostet ggü. der nachträglich eingebauten Hardwarelösung.
Ich stelle mir gerade vor, dass ich ein Zertifizierer wäre und es um Sachen Sicherheit geht: Ich finde in einer kritischen Umgebung (Krankenhaus) mehrere Rechner, welche während einer OP theoretisch geknackt werden können. Diese vom Netzt zu nehmen geht leider nicht, weil einige Operationen mit Assistenz durchgeführt werden müssen (per Videokonferenz). Da müsste ich jetzt knallhart sagen: Kein Fix innerhalb von 4 Wochen, raus mit dem Mist.
Dir kanns egal sein, du liegst ja nicht auf dem Tisch und musst beten, dass alles glatt läuft. Hauptsache Intel gut, Lücken egal, Patient Banane - dafür aber in Gaming-Benches den längeren Balken. Die Operateure sind btw keine Technik-Cracks, die wollen einfach nur in Ruhe ihre Arbeit machen und hätten am liebsten GAR NIX mit irgendwelchen Nebenproblemen während einer OP zu tun. Das muss laufen. Schnell, sicher, robust und wenn möglich mit Backup.
Da liegt halt dein Problem - nicht versuchen sich was vorzustellen, beschäftige dich doch mit der Materie anstatt nur irgendwelche Gedankenexperimente anzustellen... Das bringt dich mittel- bis langfristig viel weiter das Problem einschätzen zu können. Dein ausgedachter Kaffee hingegen bringt keinem was.
Kleiner Exkurs wie sowas praktisch laufen würde. Es wird eine Sicherheitsproblematik zur Kenntnis genommen. Auf Basis der Zusammenhänge werden Risikoanalysen durchgeführt, am Ende dieser Analysen wird man eine Feststellung treffen (müssen), ob der Einsatz dieser Technik tragbar ist oder nicht. Thats it. Ganz ohne diesen Markenaffinen Unsinn.
In der Praxis (in deinem Krankenhaus) wird kein Angreifer auch nur in die Nähe irgend eines PCs kommen, der für eine OP notwendig ist. Normalerweise! Denn WENN das der Fall ist, dann hat die gute Krankenhaus IT ganz andere Probleme als eine CPU Sicherheitslücke. Es ist die gleiche Geschichte wie oben erwähnt, es gibt (viel) unmittelbarere Gefahren, für diese ebenso die benannte Risikoanalyse erfolgen wird. Auch dort werden Erkenntnisse raus fallen und irgendwo am Ende werden dann Maßnahmen ergriffen um die Risiken zu minimieren.
Jeder (Betreiber) derartiger Systeme weis, es gibt keine 100% Sicherheit. Ist nicht. Egal wie sehr die Profis in den Foren das fordern... Weswegen der wirksame Schutz NIEMALS auf nur einer einzigen Ebene erfolgen kann. Die sicherste CPU der Welt nutzt dir nix, wenn die Software versagt. Die löchrigste CPU der Welt trägt kein Stück mehr Risiko bei, wenn zuverlässig gewährleistet werden kann, dass da keiner Schaden anrichten kann. Um nichts anderes geht es bei IT Security. Es werden Maßnahmen definiert/durchgeführt, die das Risiko idealerweise eliminieren.
Um es dir bildlich zu erklären, wenn du verhindern willst, dass ein Angreifer Code auf deinem PC ausführt, dann zieht die INet Strippe und sorge dafür, dass Niemand in die Nähe des System kommt. Wenn die INet Strippe notwendig ist, sorge dafür, dass du ohne Rückkanal die notwendigen externen "Dienste" nutzen kannst usw.
Dein Krankenhaus PC, bei dem ein Angreifer ungehindert Code ausführen kann, ist unter ganz anderen Gesichtspunkten ein Risiko. Ganz ohne irgendwelche CPU Lücken, die praktisch eine offene Tür nicht weiter öffnen. Wer schon drin ist, ist drin. Der braucht keine zweite Tür...
Lieg du mal auf dem OP-Tisch und sag das nochmal. Daran ist nix böswillig. Wenn daran auch nur 1 Patient stirbt, kann das Krankenhaus dicht machen. Irgendwo, irgenwann kann das passieren - und da Krankenhäuser ja so eine tolle Update-Struktur ihrer Rechner haben, würde es mich nicht wundern, wenn die noch alte Software drauf haben, die genau das Einfallstor für Specter&Meltdown bietet. Für einen neuen Rechner haben die Krankenhäuser kein Geld, da die Dinger immer 5x so teuer sind wie die, die du im Laden kaufen kannst. Und die Lizenzen für die Medizinsoftware sind auch gerne mal an den Rechner gebunden.
Du unterstellst Böswilligkeit, wo Sicherheit notwendig ist. Ich dreh den Schuh einfach mal um: Du bist böswillig, ein offenes Tor zu verteidigen.
Hä? Was willst du bitte jetzt von mir?
Es gibt die "guten" - das sind die Sicherheitsforscher, teils bezahlt durch die Hersteller, gezielt Lücken zu finden, zu reporten und idealerweise bevor die Infos public werden, gibt es einen Fix. Und es gibt die Böswilligen Angreifer, dass was die Allgemeinheit mit dem Darknet in Verbindung bringt. Das sind die Leute, die eben eine gefundene Lücke nicht reporten sondern zu teils horenden Preise in eben jenem Darknet ZDEs verticken und sich eine goldene Nase verdienen.
Zum Rest, bitte erspare mir und den Lesern diese Text-Zerhackstücklung! Das braucht hier Keiner.