ghecko
Digital Caveman
- Registriert
- Juli 2008
- Beiträge
- 27.042
@Kacha
Ja, ich lese gerade das Takeaway pdf.
Die Funktion hier "einfach" runterzubrechen ist wohl unmöglich, aber die Conclusion bringt es wohl auf den Punkt:
Puh, das klingt nicht gut.
Ja, ich lese gerade das Takeaway pdf.
Die Funktion hier "einfach" runterzubrechen ist wohl unmöglich, aber die Conclusion bringt es wohl auf den Punkt:
Das Problem liegt in der Art und Weise, wie der Cache Way Predictor funktioniert. Soweit ich das verstanden habe, soll dieser anfragen von Prozessen, die ihren eigenen virtuellen Adressraum haben, auf den physischen L1 und L2 Cache leiten. Und durch das Beproben der Zugriffszeit kann man herausfinden, ob ein benachbarter Prozess auf demselben Core einen Zugriff auf eine bestimmte Speicheradresse getätigt hat. Wie der Prozess aus seinem virtuellen Adressraum es nun auf den Speicherbereich des benachbarten Prozesses schafft hab ich noch nicht ganz verstanden, aber es ist scheinbar möglich.The key takeaway of this paper is that AMD’s cache way predictors leak secret information. To understand the implementation details, we reverse engineered AMD’s L1D cache way predictor, leading to two novel side-channel attack techniques. First, Collide+Probe allows monitoring memory accesses on the current logical core without the knowledge of physical addresses or shared memory. Second, Load+Reload obtains accurate memory-access traces of applications co-located on the same physical core. We evaluated our new attack techniques in different scenarios. We established a high-speed covert channel and utilized it in a Spectre attack to leak secret data from the kernel. Furthermore, we reduced the entropy of different ASLR implementations from native code and sandboxed JavaScript. Finally, we recovered a key from a vulnerable AES implementation. Our attacks demonstrate that AMD’s design is vulnerable to side-channel attacks.
Puh, das klingt nicht gut.