AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

Wobei man denen zugute halten kann, dass dieses Halbwissen jahrelang von diversen Medien mit forciert wurde.
 
Würde IMHO nur für die Server-Zens wirklich Sinn machen, aber prinzipiell grundsätzlich nicht verkehrt die Idee (vor allem für VM-Server). Wobei das ganze of Security by Obscurity basiert, und am Ende vermutlich geknackt werden kann, und/oder versteckte Hintertüren möglich sind.
 
Zuletzt bearbeitet:
War das nicht nur bei Intel ein Problem oder hab ich das falsch in Erinnerung aber am rawhammer musste ich auch denken ;)
 
War das nicht nur bei Intel ein Problem oder hab ich das falsch in Erinnerung
Es war kein Intel-Problem. Es ist ein Problem von DDR3-RAM, dass sich bei massiver Nutzung einer Row ein Feld bildet, das sich auf die benachbarten Rows auswirkt und dort Bits zum kippen bringen kann. Auf Intel-Systemen trat das Problem in der Tat weit häufiger auf als auf AMD-Systemen. Das dürfte aber vor allem daran gelegen haben, dass die Intel Memory-Controller deutlich leistungfähiger sind als die aktuellen von AMD und die Speicherchips daher stärker belastet werden.
 
Ja, gegen Rowhammer sollte das auch helfen. Aber ich sehe vor allem großen Vorteil darin, dass jede VM-Instanz ihren eigenen Speicherschlüssel bekommen kann, und das sollte es praktisch unmöglich machen aus der Instanz auszubrechen.
 
Ja, gegen Rowhammer sollte das auch helfen. Aber ich sehe vor allem großen Vorteil darin, dass jede VM-Instanz ihren eigenen Speicherschlüssel bekommen kann, und das sollte es praktisch unmöglich machen aus der Instanz auszubrechen.

Gab es da nicht in Hardware dieses Stop-Bit was einen overflow verhindern sollte?
 
Naja, theoretisch gibt es alles mögliche. Praktisch gab es immer wieder Ausbrüche. Der Vorteil hier wäre, nicht mal der Admin des VM-Servers käme an die Instanzdaten, solange er sich nicht ordentlich an der Instanz anmelden würde, weil der Speicherschlüssel nur der Instanz zur Verfügung steht.

Aber wie gesagt: Am Ende wird man auch da bestimmt wieder irgendwelche Lücken finden.
 
Dein erster Beitrag zielte doch aber darauf ab - einen Overflow zu verhindern - wobei ich da nur den ungewollten im Fokus hatte.
Jetzt entnehme ich deiner Aussage dir geht es auch um den bewusst herbeigeführten um Systeme zu unterwandern....

Aber jetzt sehe ich den echten Mehrwert - den Overflow kann man ohne Verschlüsselung auch bekämpfen...
Dein Einwand ist aber Gold wert - wenn ich nun VM`s in der Cloud fahre auf Zen-Hardware kann ich sicherstellen das kein Admin mithört... zumindest mal theoretisch... vorher war das nicht möglich...
 
Zuletzt bearbeitet:
Es war kein Intel-Problem. Es ist ein Problem von DDR3-RAM, dass sich bei massiver Nutzung einer Row ein Feld bildet, das sich auf die benachbarten Rows auswirkt und dort Bits zum kippen bringen kann. Auf Intel-Systemen trat das Problem in der Tat weit häufiger auf als auf AMD-Systemen. Das dürfte aber vor allem daran gelegen haben, dass die Intel Memory-Controller deutlich leistungfähiger sind als die aktuellen von AMD und die Speicherchips daher stärker belastet werden.
Sehr interessant, das dürfte auch auf die hohe single core leistung von intel zurück zu führen sein.
das erklärt auch warum amd beim bully auf multibit ecc setzt, massive parallel. 8)
 
Ich gebe gleich zu, dass ich das in der Quelle verlinkte Dokument nicht gelesen habe. Ohne weiteres schützt einfache RAM-Verschlüsselung durch die CPU nur gegen einen Angriff von außerhalb des Systems, z. B. Coldboot-Attacken. Das ist schon mal eine gute Sache. Letzlich wird erst mal nur der RAM an die CPU gebunden, andere Lesequellen haben keinen Zugriff mehr, wobei ich mich dann frage wie DMA funktionieren soll...

Mit mehr Fähigkeiten (z. B. mehrere Keys, Schnittstellen fürs Betriebssystem) kann man eine Unterscheidung Kernelspace vs. Userspace, je VM (steht in der News), je User oder sogar je Prozess ermöglichen.
 
DMA sollte doch immer noch funktionieren, das wird entweder teil der MMU oder zwischen MMU und Memory Controller sitzen und darauf muss der DMA ja auch zugreifen um die richtige (physikalische) Adresse zu erfahren.

Es kann aber auch gegen interne Attacken wie Rowhammer helfen, zumindest wenn versucht wird ein bestimmtes bit zu setzen. Durch die Verschlüsselung steckt die Information ja nicht mehr an der selben stelle. Wenn man nur das System abschießen will, ist die Verschlüsselung wohl egal.
 
Ja, der Punkt dürfte an der Stelle zu sein, dass man zwar Hammern kann, aber wenn man ein Bit kippt, und dann die Entschlüsselung drüber läuft, dann weiß man nicht was hinterher dabei raus kommt. Ansonsten waren sowohl AMD als auch Intel von Rowhammer betroffen, und es gab glaube ich auch ein Update, dass DDR4 auch nicht 100% sicher ist.
 
Zuletzt bearbeitet:
Jo ganz klar, für Quad und Dualcore soll ja erstmal Bristol Ridge verkauft werden, ausserdem geht AMD so auf Nummer sicher mit dem 14nm Verfahren nicht zu viel Ausschuss zu produzieren und kann teildefekte 8-Kerner dann später als 6 und 4 Kerner verkaufen... Wer weiß, vllt. brechen se es ja auch noch, wie beim Phenom, auf 3 Kerner runter, obgleich dies seinerzeit natürlich aus der Produktion teildefekter 4-Kerner resultierte...
 
Das bei 3DCenter erwähnte 2-Kern Die macht eh keinen Sinn, wenn ein Zen Cluster aus 4 Kernen besteht. Ich denke weniger als 4 Kerne wird es von der CPU sowieso nicht geben. Halt eine vergleichbare Strategie wie bei Orochi, FX8 -> FX6 -> FX4. Das 4-Kern Die kommt später als APU. Das kann man dann auch für 2-Kerner beschneiden.
 
Das bei 3DCenter erwähnte 2-Kern Die macht eh keinen Sinn, wenn ein Zen Cluster aus 4 Kernen besteht.
Ja wenn, aber wer sagt, dass das so bleiben muss?
Angeblich gibts ja erst nen 14nm Steamroller als 2kerner, aber wenn der dann mal irgendwann später einen Refresh braucht, böte sich Zen an.

Aber zu Anfang wirds das nicht geben. Ist halt so wie immer, erstmal ein Die als Prototyp, die Variationen kommen dann später, zuletzt im Billigsegment.
 
Und aus zwei 8tern bauen sie dann die 16er / 32 Threads CPU`s für den Servermarkt...
 
Die Vermutung liegt nahe, ich bin nur mal gespannt ob wir dann über eine MCM oder Interposer Lösung reden.
 
Und aus zwei 8tern bauen sie dann die 16er / 32 Threads CPUs für den Servermarkt...
Nö, es gibt ein eigenes 16-Kern Die, aus dem dann ein 32 Kern/64Thread Teil gebastelt wird, zumindest wenn die Cern-Infos stimmen:
http://www.planet3dnow.de/cms/22501...kernen-vermutlich-aber-nicht-als-am4-version/

Möglich wärs natürlich trotzdem, dass sie 2 kleine Dies zu nem 16er zusammenschalten ... böte sich möglicherweise als Versuchsballon für die größere Version an und man könnte die Plattform schon mal früher auf den Markt bringen. Ob sies machen werden .. mal schauen, kostet halt wieder extra.
 
Ja wenn, aber wer sagt, dass das so bleiben muss?
Ein eigenes Die für 2 Kerne macht doch ab 14nm keinen wirklichen Sinn mehr. Da ist so viel Transistorbudget vorhanden, ich denke wir werden hier den nächsten Schritt im Kernerennen erleben. Dual-Core ist im Einsteiger- und Mainstreambereich seit wann erschwinglich? Seit 65nm? Ich denke mit 14nm werden die Quads diese Aufgabe übernehmen. Und AMD wird's möglich machen. Intel hatte daran bisher ja kein Interesse. Quads gab's da immer erst ab etwa €200. Ausschliessen kann man sicherlich nicht, dass AMD irgendwann tatsächlich ein Dual-Core Zen Die macht. Ich glaub's aber nicht. Und wenn, dann maximal irgendein (Semi-)Custom Design für irgendwelche Low Power Lösungen.

Angeblich gibts ja erst nen 14nm Steamroller als 2kerner
Sagt wer? Hört sich für mich erst mal unlogisch an. Wenn überhaupt, dann wäre Excavator in 14nm denkbar. Wetten würde ich darauf aber nicht. AMD betont schon seit längerem, 14nm == Zen. Oder anders formuliert, wenn's nicht Zen ist, dann isses nicht 14nm.
 
In den Quellen steht was steht was von Retail/Consumer Market.

Server kommt ja später, daher bleibe ich bei der Vermutung eines 16-Chips, nur wird der halt nicht gleich am Anfang zu haben sein, sondern erst Q1 2017 für Server-CPUs mit 16/32 Kernen..
 
Angeblich gibts ja erst nen 14nm Steamroller als 2kerner ...

Da würde mich auch mal die Quelle interessieren.
Macht doch gar keinen Sinn.

Wenn dann XV, aber selbst der wird nicht geshrinked.
Für welches Einsatzgebiet sollte das Sinn machen?

Embedded/Custom von Katzen über Bulli nach ZEN? Neeee!
Von KatZEN nach KatZEN (pffff, netter Wortwitz) schon eher, aber Dualcore auch da wiederum eher nicht.
AMD will ja die Diversität des Portfolios eingrenzen (AM1, AM3+, FM3 -> AM4) und da macht es überhaupt keine Punkte
drei unterschiedliche uArch parallel zu produzieren. Also auch da (Katzen, Bulli -> ZEN).
Da noch einen Shrink von "Restmüll" durchzuführen, wenn ZEN schon auf dem Zielprozess ist, ist doch gaga und kostet nur.
Die Leistung von einem Einmoduler ist doch auch unterirdisch.
 
Zurück
Oben Unten