Sdfendor schrieb:
Intel sieht kein (neues) Problem, das nicht bereits adressiert wäre.
Hier muss man differenzieren. Du kannst mit der Totschlagkeule die Caches zu leeren das Problem quasi egalisieren. Aber das kostet halt Unmengen an Performance. Kann man jetzt so oder so sehen, ob das eine gute Lösung ist
Auf der anderen Seite hat es einen gewissen wahren Kern. Denn wenn die Entwickler ihre Sauhaufen aufräumen würden, dann würde es wahrscheinlich auch viel weniger zu holen geben. Das brisante an der Nummer ist ja, dass du quasi beliebig an die Daten ran kommst und man es so erstmal nicht verhindern kann. Im Resultat der bisherigen Praktik, dass eben der zugewiesene Speicherbereich und die Funktionen innerhalb der CPU "safe" sind hat man sich sozusagen nie darum gekümmert, den Fußabdruck möglichst klein zu halten.
Ich behaupte mal ganz frech - zukünftig wird der Trend nicht zwingend in Richtung ultimative Sicherheit der Hardware gehen (weil das ist genau so utopisch wie 100% sichere Software zu fordern), sondern dahin, dass Software mit einem gewissen Anspruch an Sicherheit eben Routen implementiert, wo solche Daten möglichst nur und ausschließlich dann überhaupt abgreifbar sind, wenn in diese in gerade diesem Moment benötigt werden. Das kostet auch Leistung und Zeit und macht Aufwand - keine Frage, aber es wäre das bei weitem einfachere Mittel ggü. quasi Caches alle Nase lang komplett von außen erzwungen zu leeren. Mit allen Leistungsnachteilen daraus. -> Müssen halt die Entwickler die brisanten Daten wegputzen und dann wird das auch was
GroundZeroX schrieb:
Sollten die bei den entsprechenden Firmen überhaupt zu den Servern kommen gibt es ganz andere Probleme. Sowas sollte weit früher abgefangen werden müssen ansonsten ist das Sicherheitskonzept mist. Als Privat Anwender sollte es nicht weiter stören.
Nope, das ist zu einfach gedacht.
In der heutigen IT Welt ist quasi alles virtualisiert. Das ganze Konstrukt lebt effektiv davon, dass man teure Ressourcen in die breite Teilt um flexibel den jeweilgen Teilen ihr Stück vom Kuchen geben zu können. Bei Bedarf. Mit dem Trend der Containerisierung geht das sogar nochmal einen Zacken schärfer, weil dort noch die Dynamik dazu kommt, das während der Fahrt auf Anforderung hoch und runter zu skalieren.
Kurzum, es ist eher die Frage, wie man das bei diesem Workloads überhaupt raus halten will - weil als Betreiber kann man schlicht nicht 100% des Codes in und auswendig kennen. Völlig utopisch sowas anzunehmen. Sicherheitslücken in Software schlummern selbst bei Open Source Projekten teils Jahre, selbst teils zwei Stellige Jahresangaben im Code, für jeden der will, öffentlich einsehbar.
Dummerweise funktioniert das auch andersrum - es reicht ein Binary, OpenSource in oder her, wo Teile im Code "lauschen", was sich noch so rumtreibt auf dem System. Das bekommt man effektiv nur mit extrem hohem Aufwand mit.
areiland schrieb:
Ich schätze mal, dass nicht mal Computerbase oder andere Forenserver für sowas ein lohnendes Ziel darstellen dürften. Höchstens Regierungs- und Unternehmensinfrastrukturen, wo es tatsächlich streng geheime Daten geben könnte, die einen solchen Aufwand lohnenswert erscheinen lassen würden. Da ich aber weder Geheimnisträger bin, noch Patente besitze, wird ein solcher Aufwand mich kaum auch nur mittelbar betreffen.
Das kommt drauf an, was die jeweilige "Gruppe", die sowas tendentiell ausnutzt, damit bezweckt.
Man geht bei sowas gern davon aus, dass es gezielte Angriffe sind. Aber das ist nur die halbe Wahrheit. Es gibt Unmengen und nicht zielgerichteten Angriffen. Da wird einfach quer beet ins Netz geplärrt und geschaut, was an Daten zurück kommt. Damit kann man genau so schaden anrichten. Vielleicht nicht in der existensvernichtenden Weise, wie ein gezielter Angriff auf ein Unternehmen oder eine Person das täte, aber Kleinvieh macht auch Mist.
Wenn mir wer von jedem Bankkonto der Welt auch nur einen einzigen Cent überweisen würde - ich würde nicht nein sagen
Was kümmert den einzelnen denn bitte einen Cent? Die Summe aber machts für den, der das Resultat bekommt...
Tzk schrieb:
Wenn ich das richtig verstehe geht es (mal wieder) darum Daten von Thread A in Thread B auszulesen, weil beide Threads dank SMT auf einem Kern liegen und somit den gleichen uOP Cache nutzen? Das ganze noch gemischt mit spekulativer Ausführung und wir haben den Salat...
Beim Schnellüberfliegen, das müsste auch ohne SMT funktionieren, weil CPUs sind Multithread fähig. Threads werden geparkt, das ganze OoO Kunstrukt sorgt in Teilen eben auch dafür, dass du mehrere Threads nicht direkt zeitgleich, aber möglichst optimal "schnell" parallel ausführst. Es werden dabei ja nicht nur die Befehle von Threads bei Nutzung von SMT parallel in die Pipeline gekippt, sondern das trifft auch Befehle von Threads, die "zeitgleich" auf einem einzigen Single Hardwarethread laufen. Allein schon, weil mehrere Ausführungseinheiten existieren, die parallel angesprochen werden können - die Befehle wandern abe am Ende alle durch den µOp Cache.
