News SWAPGSAttack: Neue Schwachstelle in Intel-Prozessoren ab Ivy Bridge

ZeroZerp schrieb:
Aber fang Du mal bitte an zu erklären, in welchem Szenario das für Betreiber von großen Rechenzentren, Serverfarmen & Co. sicherheitsrelevant werden sollte.
Nicht sicherheitsrelevant, kostenrelevant. Die Patches kosten Leistung, der Betreiber hat seinen Kunden aber Leistung zugesichert, also laufen die Server mit höherer Auslastung, das bedeutet, sie brauchen mehr Strom und sie müssen stärker gekühlt werden. Außerdem kann man nicht mehr so viele Workloads auf eine CPU packen und verkaufen.
 
  • Gefällt mir
Reaktionen: Heschel
@HerrRossi
Sie sind auch nicht kostenrelevant, wenn man die Mitigations, die ja wiederum auch keine Sicherheit versprechen (z.B. bei Spectre weder bei Intel noch bei AMD) einfach nicht aktiviert.

Zum verlinkten phoronix- Test - Man sieht hier sehr schön, wie die neuen Kernel trotz Mitigation immer weniger an Leistung verlieren.
Zudem sind das Torture Tests, die einseitig die durch die Mitigations zusätzlich entstehenden Zeiten/Lasten penetrieren.

Das heisst, dass von den Verlusten in Praxisszenarien mit Mischlasten (LAMP/SQL/TS) ein minimaler Bruchteil von den Geschwindigkeitseinbußen übrig bleibt.

Und nochmal- Nein- Es ist nicht schön.
Und ja- Man verliert Leistung, dies aber in immer engeren Grenzen, je fortgeschrittener die Mitigations "bearbeitet" werden.
Die Gefährdung ist zudem generell als extrem Gering einzuschätzen.

Deshalb mahne ich dazu, bei dem Thema hier mal vernünftige Relationen walten zu lassen und nicht plump dem Mainstream auf dem Leim zu gehen, der hier den Untergang der Menschheit vorhersieht.

LG
Zero
 
  • Gefällt mir
Reaktionen: Tronado
Klar, Serverbetreiber aktivieren die Patches nicht, da erübrigt sich jede weitere Diskussion.
 
  • Gefällt mir
Reaktionen: Rockstar85
@HerrRossi
So etwas wird nur unter Rücksprache mit dem Kunden und nach einer Risikoanalyse gemacht.
Wenn Du einen Serverblock angemietet hast, der keine für Direktzugriffe relevanten VMs hosted (z.B. Terminalserver), kannst Du Dir die Mitigations getrost sparen, da schlichtweg kein Einfallstor existiert.

In Mischumgebungen, wo man sich vereinzelt VMs mit anderen Firmen teilt, wird dies wahrscheinlich nicht der Fall sein - Dort wird gepatched werden.
Auch in Sachen Datenschutz darfst Du nicht jede x- Beliebige Maschine in einer mixed- Cloud betreiben.

Wenn Du wüstest, was für Haarsträubende Konfigurationen noch in der Cloud/bei Mischhostern laufen, dann würdest Du vielleicht viele Dinge von wegen Sicherheitsrelevanz zudem ganz anders sehen...

Es ist hier vieles einfach Praxisfern....



LG
Zero
 
Zuletzt bearbeitet:
Warum werden dann überhaupt Patches gebracht, wenn sie sowieso keiner aktiviert? Sobald mir mein Hoster mitteilt, dass er die Patches nicht aktiviert, dann bin ich da die längste Zeit Kunde gewesen, erst recht, wenn er das klammheimlich macht.
Woher beziehst du eigentlich dein intimes Wissen über Betriebsinterna solcher Anbieter und wie repräsentativ ist dein Wissen?
 
  • Gefällt mir
Reaktionen: Rockstar85
@HerrRossi
Ich gehe in großen Rechenzentren ein- und aus. Ist unter Anderem mein Tagesgeschäft.
Zudem betreiben wir in unserem Systemhaus selbst in kleinem Umfang Server- Housing/Hosting.
Und wie man sich denken kann (gesamtheitlicher Ansatz eines Systemhauses) führen wir für Fremdfirmen Pentests in Sachen IT- Sicherheit durch.
Unsere Expertise umfasst sowohl den Schulungsumfang der offiziellen Stellen für Sicherheit (Fortinet, Juniper, Cisco, BSI etc.), als auch Szene- Kontakte (sagt noch jemandem der Name Ice- Fortress was ;) ).
Wir generieren, nutzen und bewerten unter Anderem Sicherheitslücken/Eploits. Sowohl mit gängigen 08/15 Methoden (Metasploit+Repositories), als auch mit eigens entwickelten Tools.

Deshalb nochmals- Die Lücken, die sich hier massenhaft aufzutun scheinen, basieren immer auf den gleichen Prinzipien/Schwachstellen des Prozessors.
Wenige Einfallstore, die durch verschiedenste Methoden angegriffen werden. Es werden also nicht mehr Lücken, sondern man findet mehr/andere Wege um diese zu nutzen.

Und ohne kompromittiertem System, welches sich auch noch zufälliger Weise parallel auf der auszupähenden Maschine befinden muss und Nachlässigkeiten in allerlei anderen Belangen, besteht KEINE CHANCE dort von extern irgendwelche Daten abzugreifen.

Die Patches werden gebracht, weil so ein großes Buhei um diese Lücken gemacht wird und sich hier keiner Untätigkeit bzw. eine schlechte Presse erlauben will.

LG
Zero
 
Zuletzt bearbeitet:
ZeroZerp schrieb:
Und wie willst Du die Sicherheitlücken, auf welchen bei Intel rumgeritten wird bei einem nicht kompromittierten System ausnutzen? Wird hier der gleiche Umstand plötzlich mit zweierlei Maß bewertet?

Grüße
Zero

Da ich glaube, dass du IT Erfahrung hast, ganz einfach gesagt. Wenn ich einen Admin Zugriff habe, dann wäre das kompromitierende BIOS nicht notwendig, da ich ja schon Vollzugriff habe. (Es macht auch keinen Sinn, das Bios abzuändern, weil nach einem Sicherheitsleck, eh alle Systeme neu abgesichert werden, spätestens da fällt dann sowas auf).
Bei Intel kann ich über eine SideChannel Attacke Dinge auslesen (Quasi im laufenden Betrieb zB.), ohne dass es der Nutzer mitbekommt.
Nochmal: Es gibt einfachere Wege um mit Admin Zugriff Schaden anzurichten. Warum sollte ich, wenn ich Vollzugriff besitze, dann noch das BIOS ändern? Vor allem muss man dafür einen Server in Wartung setzen, spätestens DANN regt sich die IT Security (wenn vorher nicht alle anderen Maßnahmen abgeschaltet waren).
Ich bin nun mehr als 10 Jahre im Bereich IT-Security u.a. tätig und bewerte eine SideChannel Attacke, die ich schlimmstefalls via Container durch Mailsysteme in das Umfeld leite als schwerwiegender an, als wenn ich erstmal Admin Rechte brauche (und diese über Umwege holen muss, denn das AMD PSP lässt das ja auch nicht zu). Bei Golem sehen das viele IT Forensiker ähnlich, selbst die Sicherheitsforscher stufen solche "Lücken" nicht mal als Exploits ein, AMD selber Als Errata.. (sonst hätte sich sicher einer der Forscher kritisch zu Wort gemeldet). Gut und dann hats keine 3 Monate gedauert bis der Fix kam. Nochmal zum mitschreiben: Intel weiß! seit 2009 von einem möglichen Exploit mit SMT.. Die ersten Dokumente hierzu sind fast 10 Jahre alt. Und was hat man da nochmal gegen getan? Richtig! Todgeschwiegen und bagatellisiert. Du schießt hier massiv über das Ziel hinaus, außer aber du hast eine persönliche Fehde mit AMD.
Da ich nicht so gerne Autovergleiche nehme, nehme ich mal einen Flugzeugvergleich... Boeing hat ein Problem mit dem Stabilisieren des Flugzeuges, weswegen man 3 verloren hat. -> Grounding!
Airbus hat ein Problem mit dem Steuersystem bei einer bestimmten Gegebenheit in bestimmten Außnahmefällen zu einem Absinken der Landspeed kommen kann. -> Workaround weil nicht Existenzbedrohlich

Was wiegst du also schlimmer?
RyzenFall ist einer ein Fail seitens der IT Firma. Dass du diese Nebelkerze hier auch noch verteidigst, das ist schon niedlich. Und es ist mitnichten so, dass AMD keine Problematischen Fehler hat, Spectre V2 hat man in Hardware gefixed. zB. Wo bleibt der Fix gegen Meltdown und Spectre bei Intel nochmal?

Zu deiner Ausfürhung mit der Risikoanalyse sei dir nur geraten, du bist damit im strafrechtlichen Bereich unterwegs.. Finde ich Spannend, deinen Kunden nicht zu Patches zu raten, was übrigends auch nicht üblich ist. Aber Okay, ist nicht mein Kopf der rollt, wenn hier Dinge schief gehen..Ich sage dazu nur Wannacry zB.
Ich kann dir nur sagen, dass meine Kunden auf den Patch bestanden haben, selbst wenn das Risiko gering ist. Denn lieber nimmt man die Kröte in Kauf und rüstet die Server auf, als dass man auch nur eine Chance auf ein Sicherheitsleck hat. So gesehen möchte ich dir nicht die Expertise absprechen, aber du handelst in teilen grob fahrlässig.
Alternativ Herrn Stiller konsultieren: https://www.heise.de/security/meldu...ectre-sind-ein-Security-Supergau-3935124.html
 
Zuletzt bearbeitet:
Rockstar85 schrieb:
Wenn ich einen Admin Zugriff habe, dann wäre das kompromitierende BIOS nicht notwendig, da ich ja schon Vollzugriff habe. (Es macht auch keinen Sinn, das Bios abzuändern, weil nach einem Sicherheitsleck, eh alle Systeme neu abgesichert werden, spätestens da fällt dann sowas auf).
Genau das ist der Punkt. Es wäre völlig irrsinnig eine Payload bezüglich der Ausführung einer Spectre/Meltdown&Co Attacke zu injezieren.

Bei Intel kann ich über eine SideChannel Attacke Dinge auslesen (Quasi im laufenden Betrieb zB.), ohne dass es der Nutzer mitbekommt.
Das aber auch nur wieder mit Zugriff auf den Host. Und wie gesagt- Was glaubst Du, was z.B. im Cache an verwertbaren, seriell folgenden Werten ausgelesen werden kann, wenn die CPU 4 virtuelle Maschinen abfrühstücken muss. Bis da der Datenheader/das Offset online auf Konsistenz geprüft wurde ist der Inhalt schon wieder 20 mal verrauscht worden.
Du müsstest also "dumpen" und im Nachgang analysieren. Das wiederum würde eine Last erzeugen, die das ganze auffliegen lassen würde bzw. liesse sich sowas wieder mit der Verhaltensüberwachung eines Virenscanners prüfen.

Ich bin nun mehr als 10 Jahre im Bereich IT-Security u.a. tätig und bewerte eine SideChannel Attacke, die ich schlimmstefalls via Container durch Mailsysteme in das Umfeld leite als schwerwiegender an, als wenn ich erstmal Admin Rechte brauche (und diese über Umwege holen muss, denn das AMD PSP lässt das ja auch nicht zu).
Du kannst aber doch eine Sidechannel Attacke auch erst ausführen, wenn Du z.B. auf einer VM auf dem Physischen Host sitzt, der die anzugreifende VM berherrbergt. Und das auch wiederum mit Rechten zur Ausführung eines beliebigen Codes.
Du brauchst also erst ein Vehikel. Und auch hier gilt- Da würde ich ganz andere Dinge einschleusen, als diese völlig nichznutzigen und unpraktischen Spectre/Meltdown- Varianten, die eine sehr hohe Wahrscheinlichkeit haben nur Datenmüll zu liefern (gerade wenn bei den VMs durch Jitter des Timers noch eine zusätzliche Hürde besteht).

Bei Golem sehen das viele IT Forensiker ähnlich, selbst die Sicherheitsforscher stufen solche "Lücken" nicht mal als Exploits ein, AMD selber Als Errata.. (sonst hätte sich sicher einer der Forscher kritisch zu Wort gemeldet). Gut und dann hats keine 3 Monate gedauert bis der Fix kam. Nochmal zum mitschreiben: Intel weiß! seit 2009 von einem möglichen Exploit mit SMT.. Die ersten Dokumente hierzu sind fast 10 Jahre alt. Und was hat man da nochmal gegen getan? Richtig! Todgeschwiegen und bagatellisiert. Du schießt hier massiv über das Ziel hinaus, außer aber du hast eine persönliche Fehde mit AMD.
Ganz im Gegenteil- Ich bin ja derjenige, der hier ja die ganze Zeit behauptet, dass diese "Lücken" in der Praxis zu nichts zu gebrauchen sind. Genau unter Anderem aus den Gründen, die Du oben richtiger Weise anführst.
Und AMD ist bezüglich der speculative execution ja als vorerst "sicher" einzustufen.
Die ersten Hinweise auf Intels HT Implementation gab es übrigens schon 2005 (also noch schlimmer).

RyzenFall ist einer ein Fail seitens der IT Firma. Dass du diese Nebelkerze hier auch noch verteidigst, das ist schon niedlich. Und es ist mitnichten so, dass AMD keine Problematischen Fehler hat, Spectre V2 hat man in Hardware gefixed. zB. Wo bleibt der Fix gegen Meltdown und Spectre bei Intel nochmal?
Ich verteidige keine Nebelkerze- Im Gegenteil. Ich sage ja hier die ganze Zeit, dass es keinen sicherheitsrelevanten Charakter hat.
Ich bin zu 100% bei Dir mit allem was Du schreibst.

Intel ist aber auch nicht untätig...
808836


LG
Zero
 
Zuletzt bearbeitet:
Intel IST untätig, denn ein Softwarefix ist nichts anderes als die Vorraussetzung das Update zu installieren.. Bringt dir bei Systemen die unbemerkt komprommitiert wurde nur nichts. (Microcode bedeutet nicht immer Hardfix)
Spectre und Meltdown als unpraktisch und nichtsnutzig zu sehen, hat was. Das sehen die Fachleute, also Menschen die täglich nichts anderes machen, anders. Und wie du schon sagtest, wir reden hier von 2005, es ist noch schlimmer. Sämtliche Modelle vor der (ich meine es war ) 6er Gen sind de Facto unsicher.
Dagegen ist der Workaround mit namen Chimera ein Witz.. Deswegen haben auch weltweit die Sicherheitsforscher die CTS Labs mehr gestutzt, als wirklich ernste Aussagen gemacht. Intel Empfehle ich auch erst dann wieder, wenn man SMT gründlichst umgebaut hat (denn dieses ist der KERN des Problemes)

Ich finde es viel befremdlicher, wenn Laien, Aussagen zur IT Sicherheit machen. Und wenn andere Fachpersonen, auch das ganze herunterspielen..Zumal bei so einem Leck, die Firma dann quasi zumachen kann.
 
Rockstar85 schrieb:
Bringt dir bei Systemen die unbemerkt komprommitiert wurde nur nichts.
Das ist der springende Punkt. Wir haben hier diverse Tests mit Spectre, Meltdown und Derivaten, inkl. bekannter Angriffsvektoren durchgeführt.
Wie gesagt- Auch in Zusammenarbeit mit einschlägigen Leuten, die deutlich schlauer sind als der gelernte Sicherheitsfachmann (nichts gegen ausgebildete Sicherheitsfachmännder).

Ich wiederhole nochmal- Die Schwachstellen existieren.
Die Schwachstellen sind aber in ihrer ursprünglichen nicht abgeschwächten Form !in freier Wildbahn! <-Ganz wichtig! schon kaum verwertbar und mit den Mitigations (es ist da letztendlich egal ob Hard- oder Softwaregestützt), kriegst Du da in der Praxis einfach keine verwertbaren Informationen raus.
Auch in den Fachforen bleibt man mir, wenn ich unsere "Erfolge" diese Schwachstellen auf unterschiedlichen Wegen einzusetzen, nachwievor eine Antwort schuldig auf meine Frage, wie zur Hölle diese Sicherheitslücken in der Praxis relevant werden sollten.

Das heisst nicht, dass es nicht passieren kann oder unmöglich ist. Man kann aber ebenso im Lotto gewinnen.
Das ist der aktuelle Status quo.

Das ist alles.
So lange mir keiner logisch darlegen kann, wie er diese Sicherheitslücken nutzen will, ohne dass er gezielt einen singlethreaded code laufen lässt, von welchem er dann gleich wieder sequenziell ausliest, oder wie er das passende Offsett für die relevanten Daten identifizieren will, ohne den cache laufend zu analysieren/zu dumpen, was die Maschine in Grund und Boden zwingt, sehe ich einfach nach aktuellen Erkenntnissen keine wirkliche Bedrohung.

Ich sage ja auch nicht, dass das Abgreifen von Daten nicht unter Laborbedingungen funktionieren würde. Das klappt sogar hervorragend...

Was auch NICHT heisst, dass ein Schlauer Kopf nicht durch gezieltes Ausnutzen anderer Gegebenheiten, an die im Augenblick niemand denkt, daraus etwas gefährliches entwickeln könnte.

Aber wie schon weiter vorher ausgeführt.... Für solche Zwecke kann theoretisch jedes CPU Errata herhalten, was fehlerhafte Ergebnisse oder ein unvorhergesehenes Verhalten produziert.

Wenn ich also ein System angreife greife ich es an seiner schwächsten Flanke an (der Mensch, Plugins, Webcode) und nicht an einer leicht geschwächten.

Kannst Dir ja mal die öffentlichen "Beispiele" anschauen, wie man die Lücken möglicherweise ausnutzen könnte und dann siehst Du sofort, dass da Dinge im Code und den Abfragen vorausgesetzt werden, also Informationen als bekannt vorausgesetzt werden, die dem Standardhacker nicht zur Verfügung stehen.
Der müsste sich also um weit mehr kümmern...

Zudem ist von Intel AMD schon zu erwarten, dass sie zeitnah ihre Lücken schliessen.
Dass das innerhalb einer Architekturfamilie fast nicht zu bewerkstelligen ist und man sich mit Flickschustereien behilft, ist mir schon klar.

Und ja- Es wäre lächerlich, wenn die Architekturen Dinge wie Spectre und Derivate nun weiter über Jahre mitschleppen würden. Da gibt es doch garkeine Diskussion...
Andererseits würden wir auch kein Geld verdienen, wenn die Software- und Hardwareentwickler unfehlbar wären ;)


LG
Zero
 
Zuletzt bearbeitet:
ZeroZerp schrieb:
Zudem betreiben wir in unserem Systemhaus selbst in kleinem Umfang Server- Housing/Hosting.
Okay, das erklärt dein Wirken hier, ich hoffe nur für eure Kunden, dass ihr die Patches aktiviert habt und keine "Haarsträubende Konfigurationen" anbietet.
 
Dachte man bei Wannacry auch... wird spannend, wenn es erste trifft. Hatten heute wieder Schulung. Rechtlich ist deine Aussage halt strafrechtlich problematisch. Alleine deswegen werden wir angehalten zu Handeln, das wir keinen Schaden erleiden. Und Andreas Stiller schrieb es ja trefflich. Wo ein Wille, da ein Weg
 
HerrRossi schrieb:
Okay, das erklärt dein Wirken hier, ich hoffe nur für eure Kunden, dass ihr die Patches aktiviert habt und keine "Haarsträubende Konfigurationen" anbietet.
Bei dedizierten Single- Serversystemen z.B., die keine aktive Rolle Spielen, also keinen direkten Userzugriff zulassen, sind bei uns ein par wenige Systeme (i/o Schleudern) nicht gepatched.
In Mischumgebungen (ein physischer Host, der mehrere Kunden hält) ist zwangsläufig alles immer aktuell.

Beim Housing darf der Kunde selbst entscheiden, was er macht. Macht eine Maschine Ärger oder wird unser Firewallcluster getriggert, wird das fehlerhafte Gerät sofort vom Netz getrennt.

Aber wie gesagt- Einige Kunden fahren in Rechenzentren Systeme, wo es mir eiskalt den Rücken runterläuft.
Die sind auch völlig beratungsresistent (never change a running system), bis es dann irgendwann kracht.

Da sieht man aber noch viel schlimmere Dinge, wie offene FTP- Server nach außen mit sensiblen Daten. Da muss man manchmal echt die Beherrschung wahren.

Schlimm wird es immer nur dann, wenn dann tatsächlich mal was passiert. Verschlüsselung etc.
Dann sind wieder wir die Buhmänner, die nicht "eindringlich" genug beraten hätten.
Und hätte man das nur gewusst etc.

In Wirklichkeit sind von unserer Seite in den akuten Zeiten der Verschlüsselungstrojaner wöchentlich Schreiben von uns rausgegangen, wo wir uns auch schriftliche Bestätigungen von den Kunden, die nicht handeln wollten eingeholt haben.

Dann wird trotzdem noch darauf beharrt, dass man es nicht verstanden hätte, wenn dort steht, dass es keine Frage ist ob die Daten unzugänglich werden, sondern nur wann und eine direkt verbundene Sicherung nicht wiederhergestellt werden kann.

Somit sind und bleiben die größten Sicherheitsrisíken immer noch die User und ungepflegte/veraltete Systeme.

@Rockstar85
Wir sprechen hier auf technischer Ebene. Und unsere Erfahrungen decken sich nicht zwangsläufig mit unserer Handlungsempfehlung an unsere Kunden bzw. unseren Handlungen.

Die Beratung unserer Kunden fällt, sofern sie einen Vertrag mit uns haben zwangsweise in eine andere Richtung aus. Ich bin ja nicht wahnsinnig...

Wieso sollte ich auch die Verantwortung bezüglich einer dieser Schwachstellen an mein Bein binden?

Und- Wannacry ist ja eine ganz andere Liga - Das ist ja wie ich oben geschrieben habe einer der Einfallstore, die man als Hacker als erstes nutzen würde.
Aber wer zu diesen Zeiten (wannacry) in kritischen Netzen noch eine SMB1 negotiation zugelassen hat, hat sowieso mit dem Feuer gespielt.
Da muss sich der entsprechende Administrator, der solche Systeme betrieb, zur Recht einige unangenehme Fragen gefallen lassen.

Da gibts ja nichts schöneres für den Kriminellen, wenn sich etwas im Direktangriff übernehmen lässt (SQL Slammer war so mit das erste, was ich diesbezüglich hautnah mitgemacht/miterlebt habe).

LG
Zero
 
Zuletzt bearbeitet:
ZeroZerp schrieb:
In Mischumgebungen (ein physischer Host, der mehrere Kunden hält) ist zwangsläufig alles immer aktuell.
Na also. Bei Hetzner ist das auch so und ich gehe davon aus, dass die patches in den allermeisten Unternehmen, die solche Produkte anbieten, auch aktiviert sind. Und da die Patches Leistung kosten, ist das sehr wohl ein Problem.
 
  • Gefällt mir
Reaktionen: Rockstar85
@HerrRossi
Ja- Aber aus den Extremszenarien werden aus 20%-40% Geschwindigkeitseinbußen in der Theorie in der Praxis gerade durch die Mischumgebung beim Hoster dann vielleicht 3% - 5% wenns schlecht läuft, was durch ein übliches Overprovisioning dann tatsächlich in die völlige Bedeutungslosigkeit absinkt.

Wie gesagt- Auch das ist nicht toll und rechtfertigt NICHTS. Solche Lücken sollte und dürfte es nicht geben.
Mir fehlt bezüglich der Spectre/Meltdownvarianten und Co. aber einfach ein ganz großes Stück Verhältnismäßigkeit und eine eingehende Praxisbetrachtung.

808893


LG
Zero
 
Zuletzt bearbeitet:
Die verlinkten Tests sind Extremszenarien?
 
@HerrRossi
Es ist, wie wenn Du angibst mit Prime95 den Stromverbrauch einer CPU für einen Spieleworkload herausfinden zu wollen.
Und alle Tests, die Phoronix macht, die in Richtung Praxissimulation gehen (z.B. Perl,Redis) zeigen eher, dass man auf die Distribution bzw. Kernelversion achten sollte, als dass sich da große Einbußen ergäben.

Oder gehst Du davon aus, dass die Kunden eines gehosteten Servers Tag- und Nacht nur Benchmarks mit rein auf I/O getrimmten Workloads laufen lassen?

LG
Zero
 
Alle bisher entdeckten Sicherheitslücken sind mehr oder weniger uninteressant für Privatanwender, da der Aufwand zum Ausnutzen der Lücken viel zu groß ist als dass es sich lohnt, sagt der IT-Chef meines Vertrauens. Und dem glaube ich, im Gegensatz zu den Antiviren-Herstellern, die durch die sehr gute integrierte Antivirenlösung von MS momentan um Ihren Job bangen müssen.
Aber ich kann nachvollziehen, dass die rote Fraktion sich so über jede neue Meldung freut. Ryzen 3000 hat, außer man benötigt tatsächlich die vielen Kerne eines 3900X, realistisch betrachtet nichts zu bieten, was einen 8700K oder 9900K obsolet macht. Da muss dann regelmäßig eine neue Sicherheitslücke entdeckt werden.
 
Na klar, AMD steckt hinter den Sicherheitslücken bei Intel :D Und jetzt haben die Roten auch noch Jim Keller eingeschleust :D

@ZeroZerp Wir können sicherlich noch länger so weitermachen, du magst auf dem Gebiet auch bewanderter sein als ich, aber was du schreibst - auch widersprüchliches, weil ihr selber ja die Patches aktiviert habt - überzeugt mich nicht. Wie viel Leistung die patches im tatsächlichen Betrieb kosten werden wir sowieso nicht beziffern können, weil auch jeder Workload anders ist, aber sie kosten Leistung. Die Sicherheitslücken sind kein Weltuntergang, aber sie sind auch keine totale Belanglosigkeit.

Intel hat momentan sowieso ganz andere Probleme, mit AMDs Rome müssen sie erstmal fertig werden und da fallen sie wieder in alte Muster, indem sie Druck auf ihre Partner ausüben.
 
  • Gefällt mir
Reaktionen: Rockstar85 und .Sentinel.
@HerrRossi
Da können wir uns bestens drauf einigen.
Wobei ich den Widerspruch nicht entdecken kann.
Die rechtlich Sichere Option muss ja nicht immer mit einer technisch gerechtfertigten übereingehen.

Was für einen Grund hätte ich dafür bürgen zu wollen, dass einem ungepatchten System nichts passiert bzw. die rechtlichen Konsequenzen auf mich zu nehmen.

Wie gesagt- Meine Ausführungen betreffen rein die Relevanz in der Praxis. Immer mit dem Vermerk, dass findige Köpfe vielleicht zukünftig in der Lage sind, vielleicht durch Ausnutzung mehrerer Timing- basierter Schwächen der Mikroarchitektur vielleicht in Kombination diese Lücken effektiver exploiten zu können.

Und klar geht es zu I/O Lastigen Workloads hin zu den höchsten Geschwindigkeitseinbußen. Das geht eben bis zu den Extremen (synthetische Tests von Phoronix), wo auf die I/O Systeme maximal mit 4k Anfragen eingehämmert wird, bis zu garkeinen Auswirkungen auf die Performance (Desktopbetrieb).

In diesem Sinne denke ich, dass die Argumente ausgetauscht sind und auch die Standpunkte klar dargelegt wurden. So muss das sein. Schön überhaupt mit jemandem auf diesem Niveau diskutieren zu können.

LG
Zero
 
  • Gefällt mir
Reaktionen: HerrRossi
Zurück
Oben