Prelekcja o Meltdown & Spectre

#1

Ostatnimi czasy głośno było o podatnościach Meltdown & Spectre współczesnych procesorów.

Ataki typu side-channel na sprzęt nie są żadną nowością. Jedną z głośniejszych publikacji sprzed wielu lat było Cache missing for fun and profit. Atak polegał na zawężaniu obszaru poszukiwań możliwych kluczy prywatnych SSL wykorzystując właściwości procesorów z wątkami sprzętowymi. Choć był niepraktyczny pokazywał możliwość nieuprawnionego pozyskiwania danych z ostrożnej obserwacji czasowych opóźnień w wykonaniu instrukcji.

Na seminarium zajmowaliśmy się różnymi mechanizmami spekulacji implementowanymi w procesorach Out-of-Order, w tym: predyktorami skoków i spekulacyjnym wykonywaniu dostępów do pamięci. Zatem jesteśmy gotowi, aby rzeczowo porozmawiać o tym co stoi za Meltdown & Spectre i jaki wpływ będzie to miało na mikroarchitekturę “poprawionych” procesorów.

Jan Mazur (@mzr) wygłosi na ten temat prelekcję w poniedziałek 22 stycznia 2018, godzina 16, sala 139. Gorąco zapraszam!

11 polubień
#2

Z mojej winy pojawiły się pewne niedociągnięcia za co przepraszam i spieszę z wyjaśnieniem:

Nowoczesne procesory CISC rozbijają instrukcje na mikrooperacje. To właśnie mikrooperacje a nie całe instrukcje są kolejkowane w buforze przestawiania. Czekają tam na obliczenie wszystkich swoich operandów, aby kiedy to się stanie zostać od razu zakolejkowanym do odpowiednich jednostek funkcyjnych. Mikrooperacje mogę się wykonywać na wielu jednostkach funkcyjnych jednocześnie i co ważne nie muszą wykonywać się w tej samej kolejności w której trafiły do bufora przestawiania. Kiedy mikrooperacja zakończy się wykonywać, jej wynik i flaga wyjątku są zapisywane w buforze przestawiania. W tym momencie inne, zależne od jej wyniku mikrooperacje mogą zostać zakolejkowane do wykonania w jednostkach funkcyjnych.

Kiedy wszystkie mikrooperacje danej instrukcji zostały wykonane, może rozpocząć się proces zatwierdzania danej instrukcji. Zatwierdzając mikrooperacje danej instrukcji czynimy to w kolejności w jakiej trafiły one do bufora przestawiania. Jeśli któraś z mikrooperacji ma ustawioną flagę wyjątku to zgłaszamy wyjątek na instrukcji do której ona należy, oraz czyścimy bufor przestawiania (robimy rollback).

Czyli wyjątek na instrukcji jest zgłaszany dopiero gdy wszystkie mikrooperacje instrukcji się wykonają i zatwierdzana będzie mikrooperacja powodująca wyjątek. W tym czasie mogło wykonać się wiele instrukcji / mikrooperacji innych instrukcji, w tym także instrukcji będących w kolejności programu PO instrukcji zgłaszającej wyjątek! Te mikrooperacje/instrukcje mogą modyfikować stan cache, który później nie jest przywracany.

Można wykorzystać sytuację wyścigu pomiędzy zgłoszeniem wyjątku, a modyfikacją cache.

Z tego co wiem to nie wiadomo czy na pewno i dokładnie w taki sposób podatne procesory realizują algorytm Tomasulo. Jednak jest to bardzo pradopodobne.

Nieudana próba stworzenia PoC, dokładnie opisana.
Publikacja o Meltdown

5 polubień
#3

Wydaje mi się, że tu jest ładne podsumowanie (nie licząc marudzenia, że niektórzy nie dostali informacji wcześniej): http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html

2 polubienia