Zdaniem naukowców: w tej chwili nie jest jasne, czy Meltdown wpływa również na procesory ARM i AMD.
Janghou
1
Istnieje przykład, że możesz ukraść hasło za pomocą Javascript w przeglądarce (Chrome / Firefox).
Janghou
4
@ alex2003super: Nie wariuj. Chociaż skala dotkniętych urządzeń jest oszałamiająca, szanse na to, że dotknie Cię ten problem w jakikolwiek sposób, są dość niskie. A nawet gdyby tak nie było, wariactwo nie pomogłoby. :)
Lekkość ściga się z Monicą
1
Wygląda na to, że nie są bezbronni, oto najnowszy artykuł na ten temat raspberrypi.org/blog/…
Według samych ARM rdzenie procesorów stosowane we wszystkich modelach przed Pi 4 nie są wrażliwe .
Większość odmian tego procesora spekulacji nie wpływa na większość procesorów uzbrojenia. Ostateczną listę niewielkiego podzbioru procesorów zaprojektowanych pod kątem Arm, które są podatne, można znaleźć poniżej. [patrz link do tabeli]
Żaden z powyższych rdzeni nie jest wymieniony jako podatny na jakąkolwiek wersję ataku (nie ma ich wcale, ponieważ nie ma znanej podatności na te ataki).
Maliny Pi 4 wykorzystuje Cortex-A72 , które są wymienione jako podatne wariantów 1, 2, 3a i 4. Zgodnie jest malina Pi 4 podatne na czynów Spectre? , Raspbian zawiera oprogramowanie łagodzące te luki, więc ryzyko wykorzystania powinno być niskie. Inne systemy operacyjne mogą nie zawierać odpowiednich zabezpieczeń, a chociaż ARM twierdzi, że w Cortex-A72 została wydana poprawka sprzętowa, nie jest jasne, czy zostało to zastosowane w Pi 4.
Zauważ, że warianty 1 i 2 (CVE-2017-5753 i CVE-2017-5715) są znane jako Spectre , a warianty 3 (CVE-2017-5754) i 3a (powiązany atak badany przez ARM) nazywane są Meltdown . Dlatego żadne z urządzeń Raspberry Pi wcześniejszych niż Pi 4 nie jest uważane za wrażliwe na Spectre lub Meltdown.
Zastanawiam się, czy zmiany w jądrze Linuksa, które są wymagane w innych architekturach, zostaną wyparte do wersji Linuksa działających na Raspberry Pi? Podobno zmiany te spowolnią system, więc może wpłynie to na RP, nawet jeśli łaty nie są potrzebne.
Bobby Durrett
4
Łatka jądra wykrywa, na którym procesorze działa, i automatycznie się wyłącza, jeśli nie jest to model, którego dotyczy problem. Ponadto jądra dla Raspberry Pi (i większości innych komputerów jednopłytkowych) są zbudowane specjalnie dla dostępnego sprzętu i nie ma powodu, aby opiekunowie włączali lub włączali omawianą łatkę.
Perkins
1
@BobbyDurrett, zmiany Meltdown w jądrze znajdują się w specyficznej dla x86 sekcji bazy kodu. Zmiany związane z Spectre są wszędzie, ale większość z nich znajduje się w specyficznych dla procesora sekcjach kodu lub jest obsługiwana przez kompilator. Niektóre bity, takie jak zmiany strukturalne w kodzie sieci, mogą wyciekać do Pi, ale większość z nich nie.
Mark
Dziękuję za komentarze. Interesujące jest zastanowienie się, które części kodu jądra Linux są specyficzne dla procesora. Wydaje mi się, że w systemie operacyjnym, który działa na wielu różnych procesorach, trzeba wykonać dobrą robotę, dzieląc kod właściwy dla każdego procesora.
Bobby Durrett
22
Pi (wszystkie wersje) nie jest wrażliwy.
Spectre i Meltdown wymagają wykonania poza kolejnością. Cortex-A7 wykorzystywane we wczesnym Pi 2 i A53 Cortex stosowanych w późniejszym Pi 2 i 3 jest Pi architektura ściśle zamówienie. ARM11 stosowane w Pi 1 jest częściowo poza kolejnością, ale nie w sposób, który pozwala Widmo lub Meltdown do pracy.
ARM to potwierdza : tylko bardzo ograniczony podzbiór procesorów ARM ma sprzęt, który czyni je wrażliwymi na Spectre, jeszcze bardziej ograniczony podzbiór jest wrażliwy na Meltdown i uważa się, że wszystkie z nich pozwalają złagodzić zagrożenie.
Jeśli chodzi o Meltdown, jest to bardzo specyficzna luka w niektórych procesorach, więc jeśli ARM twierdzi, że procesor w Raspberry Pi nie jest podatny na ataki, prawdopodobnie można mu zaufać.
Jednak Spectre jest bardziej ogólną podatnością. Jak dotąd pokazano tylko dwa warianty, ale jestem pewien, że jest ich więcej. Błąd procesora polega na tym, że stan predyktora gałęzi nie jest opróżniany podczas przełączania kontekstu, a ten stan predyktora gałęzi jest indeksowany przez bity niskiego rzędu adresu instrukcji gałęzi i nie jest w ogóle oznaczany. Więc możesz mieć dwie gałęzie, które mają ten sam stan predykcyjny gałęzi, nawet ponad granicami procesu.
Jestem bardzo pewien, że procesor we wszystkich modelach Raspberry Pi jest podobny do praktycznie wszystkich innych procesorów, ponieważ predyktorem gałęzi jest po prostu duży zestaw 2-bitowych liczników nasycenia (mocno zajęty, słabo zajęty, słabo niezabrany, silnie Nie wzięty). Indeksem do tej tablicy są bity niskiego rzędu adresu instrukcji rozgałęzienia i nie ma znacznika, a ten stan predykcyjny nigdy nie jest kasowany.
Teraz, jeśli dwie gałęzie mają ten sam stan predyktora, możesz zmierzyć, w jaki sposób dana gałąź przyjęła w niedawnej przeszłości. W związku z tym istnieje wyciek informacji Spectre! Jeśli możesz w sposób niezawodny uruchomić przeglądarkę w celu wykonania rozgałęzienia kodu w haśle z JavaScript i zmierzyć, w jaki sposób poszły gałęzie, możesz rzeczywiście wyodrębnić hasło. To jest skrajny przykład, nikt rozsądny nie rozgałęziłby się na każdym kawałku hasła w sposób, który można uruchomić z JavaScript, ale to pokazuje problem.
Nie wierz we wszystko, co mówi ARM. ARM oznacza prawdopodobnie to, że exploity opracowane przez Google nie działają na tych procesorach ARM. Nie oznacza to, że byliby niewrażliwi na Spectre. Może działać jakiś inny rodzaj exploita.
Zobacz to pytanie: https://security.stackexchange.com/questions/176678/is-branch-predictor-flush-instruction-a-complete-spectre-fix i zrozum implikacje jego odpowiedzi. Nieuczciwy kod JavaScript działający w przeglądarce może z powodu Spectre zmierzyć, w jaki sposób poszły inne gałęzie procesu. Nawet instrukcja opróżniania predyktora gałęzi nie naprawi tego nieuczciwego problemu JavaScript, chyba że przeglądarka aktywnie opróżni predyktor gałęzi przed uruchomieniem niezaufanego kodu.
Spectre będzie z nami bardzo, bardzo długo, ponieważ predyktor gałęzi używa 14 bitów, ponieważ indeks nie jest oznaczony pozostałymi 18 bitami 32-bitowej przestrzeni adresowej, ponieważ wymagałoby to 20 bitów (licznik nasycenia 2 bitów , 18 bitów tag) zamiast tylko 2 bitów. To pomnożyłoby rozmiar predyktora gałęzi przez dziesięć! Oczekuję, że producenci procesorów dodadzą instrukcję czyszczenia predyktora gałęzi, która działa nawet w przestrzeni użytkownika bez specjalnych uprawnień, a jądro będzie jej używać podczas przełączania kontekstu, a przestrzeń użytkownika będzie używać jej podczas uruchamiania niezaufanego kodu JITed. To rozwiązałoby większość problemów Spectre w praktyce, ale teoretycznie nie wszystkie.
„ Teraz, jeśli dwie gałęzie mają ten sam stan predyktora, możesz zmierzyć, w jaki sposób konkretna gałąź przyjęła w niedawnej przeszłości. ” Jak to zrobić bez spekulacyjnego wykonania?
Peter Taylor
@PeterTaylor te procesory ARM mają predyktor gałęzi, a zatem mają działanie spekulacyjne. Brakuje ich wykonania poza kolejnością.
juhist
Są udokumentowane, że mają pobieranie instrukcji spekulatywnych, ale nie jest to wykonanie spekulatywne. To słuszne, że nadal można go używać jako wyroczni.
Peter Taylor
Nawet spekulacyjne pobranie może być wystarczające, ponieważ wystąpią niewielkie, ale mierzalne różnice w opóźnieniu.
juhist
Linux już dodawał losowość adresów jądra; nie możesz przewidzieć adresu oddziału.
Odpowiedzi:
Według samych ARM rdzenie procesorów stosowane we wszystkich modelach przed Pi 4 nie są wrażliwe .
Rdzenie procesorów używane przez starsze Pisy to:
Pi 1 i Zero (W) : ARM11
Pi 2 V1 : ARM Cortex-A7
Pi 2 V1.2 i Pi 3 : ARM Cortex-A53
Żaden z powyższych rdzeni nie jest wymieniony jako podatny na jakąkolwiek wersję ataku (nie ma ich wcale, ponieważ nie ma znanej podatności na te ataki).
Maliny Pi 4 wykorzystuje Cortex-A72 , które są wymienione jako podatne wariantów 1, 2, 3a i 4. Zgodnie jest malina Pi 4 podatne na czynów Spectre? , Raspbian zawiera oprogramowanie łagodzące te luki, więc ryzyko wykorzystania powinno być niskie. Inne systemy operacyjne mogą nie zawierać odpowiednich zabezpieczeń, a chociaż ARM twierdzi, że w Cortex-A72 została wydana poprawka sprzętowa, nie jest jasne, czy zostało to zastosowane w Pi 4.
Zauważ, że warianty 1 i 2 (CVE-2017-5753 i CVE-2017-5715) są znane jako Spectre , a warianty 3 (CVE-2017-5754) i 3a (powiązany atak badany przez ARM) nazywane są Meltdown . Dlatego żadne z urządzeń Raspberry Pi wcześniejszych niż Pi 4 nie jest uważane za wrażliwe na Spectre lub Meltdown.
źródło
Pi (wszystkie wersje) nie jest wrażliwy.
Spectre i Meltdown wymagają wykonania poza kolejnością. Cortex-A7 wykorzystywane we wczesnym Pi 2 i A53 Cortex stosowanych w późniejszym Pi 2 i 3 jest Pi architektura ściśle zamówienie. ARM11 stosowane w Pi 1 jest częściowo poza kolejnością, ale nie w sposób, który pozwala Widmo lub Meltdown do pracy.
ARM to potwierdza : tylko bardzo ograniczony podzbiór procesorów ARM ma sprzęt, który czyni je wrażliwymi na Spectre, jeszcze bardziej ograniczony podzbiór jest wrażliwy na Meltdown i uważa się, że wszystkie z nich pozwalają złagodzić zagrożenie.
źródło
Chciałbym zaproponować inne podejście do tego.
Jeśli chodzi o Meltdown, jest to bardzo specyficzna luka w niektórych procesorach, więc jeśli ARM twierdzi, że procesor w Raspberry Pi nie jest podatny na ataki, prawdopodobnie można mu zaufać.
Jednak Spectre jest bardziej ogólną podatnością. Jak dotąd pokazano tylko dwa warianty, ale jestem pewien, że jest ich więcej. Błąd procesora polega na tym, że stan predyktora gałęzi nie jest opróżniany podczas przełączania kontekstu, a ten stan predyktora gałęzi jest indeksowany przez bity niskiego rzędu adresu instrukcji gałęzi i nie jest w ogóle oznaczany. Więc możesz mieć dwie gałęzie, które mają ten sam stan predykcyjny gałęzi, nawet ponad granicami procesu.
Jestem bardzo pewien, że procesor we wszystkich modelach Raspberry Pi jest podobny do praktycznie wszystkich innych procesorów, ponieważ predyktorem gałęzi jest po prostu duży zestaw 2-bitowych liczników nasycenia (mocno zajęty, słabo zajęty, słabo niezabrany, silnie Nie wzięty). Indeksem do tej tablicy są bity niskiego rzędu adresu instrukcji rozgałęzienia i nie ma znacznika, a ten stan predykcyjny nigdy nie jest kasowany.
Teraz, jeśli dwie gałęzie mają ten sam stan predyktora, możesz zmierzyć, w jaki sposób dana gałąź przyjęła w niedawnej przeszłości. W związku z tym istnieje wyciek informacji Spectre! Jeśli możesz w sposób niezawodny uruchomić przeglądarkę w celu wykonania rozgałęzienia kodu w haśle z JavaScript i zmierzyć, w jaki sposób poszły gałęzie, możesz rzeczywiście wyodrębnić hasło. To jest skrajny przykład, nikt rozsądny nie rozgałęziłby się na każdym kawałku hasła w sposób, który można uruchomić z JavaScript, ale to pokazuje problem.
Nie wierz we wszystko, co mówi ARM. ARM oznacza prawdopodobnie to, że exploity opracowane przez Google nie działają na tych procesorach ARM. Nie oznacza to, że byliby niewrażliwi na Spectre. Może działać jakiś inny rodzaj exploita.
Zobacz to pytanie: https://security.stackexchange.com/questions/176678/is-branch-predictor-flush-instruction-a-complete-spectre-fix i zrozum implikacje jego odpowiedzi. Nieuczciwy kod JavaScript działający w przeglądarce może z powodu Spectre zmierzyć, w jaki sposób poszły inne gałęzie procesu. Nawet instrukcja opróżniania predyktora gałęzi nie naprawi tego nieuczciwego problemu JavaScript, chyba że przeglądarka aktywnie opróżni predyktor gałęzi przed uruchomieniem niezaufanego kodu.
Spectre będzie z nami bardzo, bardzo długo, ponieważ predyktor gałęzi używa 14 bitów, ponieważ indeks nie jest oznaczony pozostałymi 18 bitami 32-bitowej przestrzeni adresowej, ponieważ wymagałoby to 20 bitów (licznik nasycenia 2 bitów , 18 bitów tag) zamiast tylko 2 bitów. To pomnożyłoby rozmiar predyktora gałęzi przez dziesięć! Oczekuję, że producenci procesorów dodadzą instrukcję czyszczenia predyktora gałęzi, która działa nawet w przestrzeni użytkownika bez specjalnych uprawnień, a jądro będzie jej używać podczas przełączania kontekstu, a przestrzeń użytkownika będzie używać jej podczas uruchamiania niezaufanego kodu JITed. To rozwiązałoby większość problemów Spectre w praktyce, ale teoretycznie nie wszystkie.
źródło