An sich kein schlechts Video, jedoch kamen meiner Meinung einige wichtige Dinge etwas zu kurz.
Zunächst einmal, ist das Problem neben der Sprungvorhersage vorallem auch die so genannte "Out-of-Order Execution". Dabei werden CPU-Befehle schon ausgeführt, obwohl sie noch nicht dran wären. Die CPU tut also so, als würde sie die Befehle schon einmal ausführen (das muss auch nicht immer in der richtigen Reihenfolge geschenen), merkt sich das Ergbniss und wenn der Befehl dann darn ist hat man den Geschwindigkeitsgewinn, da die Daten fertig geladen und berechnet sind. Dabei tut die CPU auch so, als wäre jeder Speicherzugriff erfolgreich. Stellt die CPU aber später fest, dass ein Speicherzugriff nicht erfolgreich war und sie diesen Befehl nicht hätte ausführen dürfen, da der Prozess keinen Zugriff auf den Speicherbereich hatte (Usermode-Prozess auf Kernelspeicher) oder weil es die Programmlogik verbietet (hier kommt auch maßgeblich die Sprungvorhersage zum tragen), dann wird dieser Befehl wieder zurück gerollt und so getan, als wäre er nie ausgeführt worden.
Dabei gibt es nur ein Problem... die CPU hat lesend auf eine Speicherzelle zugegriffen und die Daten im Cache abgelegt. Jedoch wird das laden in den Cache nicht zurückgerollt. Nun kann über Zeitmessungen recht einfach festgestellt werden worauf verbotener weise zugegriffen wurde.
Jedoch zielte Meltdown nicht darauf ab seine Rechte lokal zu erweitern. Meltdown zielte darauf ab, Kernelspeicher auszulesen. Das ist/war möglich, da der Kernelspeicher der Einfacheit halber im Speicher eines Nutzerprossesses vollständig eingeblendet wurde und mit dem Bit (Supervisor-Bit) geschützt wurde. Intel CPUs haben dieses Bit aber zuspät in der Out-of-Order Execution ausgewertet wodurch der zugriff nicht rechtzeitg verhindert werden konnte. (AMD CPUs machen hier laut angaben den Check eher und greifen erst garnicht auf den Speicher zu). Behoben werden, konnte das durch eine vollständige Trennung des Kern und Nutzerspeichers.
Auch ist es eigentlich mit keinem der beiden Angriffe möglich auf Speicher außerhalb des eigenen Addressraums zuzugreifen. Das heißt es sollte nicht möglich sein auf andere Prozesse zugegriffen. Da jedoch zum Bsp. javascript im Prozess des Browsers ausgeführt wird, ist das trotzdem ein großes Problem.
Und um Abschließend auch noch auf eine Kommentarfrage einzugehen. Das Problem ist eine indirekte Folge aus Sprungvorhersage und "Out-of-Order Execution". Es ist aber sicher nicht sinnvoll und notwending diese Features wieder komplett zu entfernen.
Denn CPUs die in-order arbeiten, wären um einiges langsamer als ihrer out-of-order Äquvivalete (siehe Intel Atom und Core-i von 2012). Das Konzept muss nur wahrscheinlich nocheinmal neu überdacht werden. (Was soweit ich das verstanden habe schonmal damit anfangen würde beim Aufräumen hinter fälchlicherweise ausgeführten Befehlen nicht die hälfte zu vergessen)