Co faktycznie pokazuje sekcja „błędy” w / proc / cpuinfo?

W systemie Debian Stretch i testowaniu / Buster z bieżącym jądrem i zainstalowanym mikrokodem nadal widzę topnienie i widmo na liście błędów /proc/cpuinfo.

Jednak uruchamianie spectre-meltdown-checkerprogramów nie jest wrażliwe.

Zastanawiam się więc, co /proc/cpuinfoto pokazuje. Czy są to tylko luki w zabezpieczeniach tego procesora i czy będą one zawsze wymienione, pomimo posiadania łatanego systemu?

linux cpu proc

— hurrbert
źródło

Odpowiedzi:

Cel pola „błędów” w /proc/cpuinfoopisanym w komunikacie zatwierdzenia, który go wprowadził :

x86/cpufeature: Dodaj flagi błędów do /proc/cpuinfo

Zrzuć flagi, które wskazują, że wykryliśmy i / lub zastosowaliśmy obejścia błędów dla procesora, na którym wykonujemy, w podobny sposób jak flagi funkcji.

Zaletą jest to, że nie kumulują się one z czasem, podobnie jak funkcje procesora.

Wcześniej błędy sprzętowe wykryte przez jądro były wymienione jako osobne funkcje ( np . Niesławny błąd F00F, który ma swój własny f00f_bugwpis w /proc/cpuinfo32-bitowych systemach x86). Wpis „błędy” został wprowadzony, aby utrzymać je w jednej funkcji idącej naprzód, w tym samym stylu co flagi procesora x86 .

O ile wpisy w praktyce oznaczają, jak widać w komunikacie, wszystko, co gwarantuje, to że jądro wykryło błąd sprzętowy. Musisz szukać gdzie indziej (komunikaty rozruchowe lub określone /procwpisy lub /syswpisy, takie jak pliki w /sys/devices/system/cpu/vulnerabilities/), aby ustalić, czy problemy zostały rozwiązane.

Przydatność wpisów „błędów” jest ograniczona na dwa sposoby. Po pierwsze, prawdziwych negatywów nie można odróżnić od nieznanych: jeśli pole nie określa „cpu_meltdown”, nie możesz (tylko z pola) wiedzieć, czy to oznacza, że jądro nie wie o Meltdown lub że na procesor nie ma wpływu Meltdown. Po drugie, wykrywanie może być zbyt uproszczone; zachowuje ostrożność, więc może zgłosić, że twój procesor jest podatny na zagrożenia, gdy nie jest. Ponieważ „wykrywanie” zależy od tabeli, jego dokładność zależy od używanej wersji jądra.

W przypadku błędów Meltdown i Spectre proces wykrywania, który podaje wartości w /proc/cpuinfo następujący sposób , działa na x86:

jeśli procesor nie wykonuje żadnych spekulacji (klasa 486, niektóre klasy Pentium, niektóre atomy), nie jest oznaczany jako zmieniony przez Meltdown lub Spectre;
wszystkie pozostałe procesory są oznaczone jako warianty Spectre 1 i 2 (niezależnie od wersji mikrokodu itp.);
jeśli CPU nie jest wymieniony jako niewrażliwy na spekulacyjne obejście sklepu , jeśli jego mikrokod nie twierdzi, że ogranicza SSB, a jeśli CPU nie twierdzi, że ogranicza SSB, oznacza to, że ma wpływ SSB;
jeśli procesor nie jest wymieniony jako niewrażliwy na Meltdown (AMD) i jeśli jego mikrokod nie twierdzi, że łagodzi Meltdown, oznacza to, że ma wpływ na Meltdown.

— Stephen Kitt
źródło

W przypadku widma i krachu nie są nawet wykrywani, ale po prostu zakładają . Mam uporządkowane x86, na które nie ma to wpływu, ale jądro po prostu zgłasza, że tak jest z powodu zakodowanej reguły, która w zasadzie mówi „każde procesor Intel starszy niż X bez zastosowanej łaty mikrokodu jest podatny na załamanie”.

— R ..

@R .. czy twój procesor jest uwzględniony w tabelach zamówień w jądrze? (Poszukaj „cpu_no_speculation” tutaj, aby zobaczyć najnowsze tabele.) To jest rzeczywiście jeden z problemów z wpisem „błędy” wrt. Meltdown, Spectre i wsp., Jego dokładność naprawdę zależy od tego, jak aktualne jest twoje jądro, ponieważ ich „wykrywanie” jest zależne od tabeli.

— Stephen Kitt

Nie, to Centerton Bonnell i stamtąd go nie ma. Zobaczę o przesłaniu łatki.

— R ..

Czy ktoś wie, czy nadal jest to poprawne, gdy aktualizacje mikrokodu zostały zastosowane podczas rozruchu, ale po załadowaniu jądra?

— Bachsau

Luki w zabezpieczeniach Meltdown / Spectre dotyczą projektowania / architektury chipsetu procesora, a wkrótce po zakupie nowego sprzętu w przyszłości łatki stanowią niezłą iluzję bezpieczeństwa w perspektywie długoterminowej . Z czasem mogą pojawić się nowe metody wykorzystywania wad, które mogą ominąć obecne łatki.

Krótko mówiąc, obecne łatki / mikrokody oprogramowania łagodzą problemy w stosunku do znanych metod exploitów z rodziny Spectre / Meltdown, ale nie rozwiązują podstawowych problemów projektowych procesorów, które na to pozwalają. Dotknięte (kilka generacji) procesorów nie przestały być podatne na zagrożenia w dłuższej perspektywie (i najprawdopodobniej nigdy nie będą).

Jednak, jak słusznie stwierdza @Gilles, posiadanie tego ostrzeżenia nie oznacza, że obecne znane exploity będą działać metody Spectre / Meltdown; nie będą działać, jeśli łatki są zainstalowane.

W przypadku wspomnianym w pytaniu jądro sprawdza tylko modele procesorów, o których wiadomo, że mają na nie wpływ Spectre / Meltdown (na razie wszystkie procesory x86, jeśli mówimy tylko o x86), a zatem cpu-insecurenadal są wymienione w sekcji błędów / line in /proc/cpuinfo.

Idź sprawdź swoje /proc/cpuinfo . Będzie zawierał cpu_insecure, jeśli twoje jądro ma łatkę KPTI

Odkryłem, że łatka KPTI ma ten fragment kodu:
   /* Assume for now that ALL x86 CPUs are insecure */
   setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
A po aktualizacji jądra otrzymasz:
bugs      : cpu_insecure

PS. Wprowadzono już serię aktualizacji nowej metody wykorzystywania „błędów” Spectre / Meltdown. To chyba nie ostatni raz.

— Rui F. Ribeiro
źródło

np. jeśli możesz wstrzymać się z zakupem hw przez chwilę, poczekaj na nową generację procesorów. Moja kryształowa kula powiedziała mi, że w średnim okresie będziemy mieli wiele serwerów z drugiej ręki sprzedających orzechy ziemne.

— Rui F Ribeiro

Błędy procesora są wymienione, /proc/cpuinfonawet jeśli zostały w pełni wyeliminowane przez łatkę oprogramowania. Ich obecność nie oznacza, że twój system jest podatny na ten konkretny błąd.

— Gilles „SO- przestań być zły”

@Gilles przyznany, nie będziesz mógł zastosować znanych exploitów. Mieliśmy już jednak do czynienia z exploitami dotyczącymi 1. generacji łatek i zaryzykuję stwierdzenie, że istnieje wiele interesów komercyjnych, które uciszają krytykę tego, że jest to podstawowa wada projektowa, która wymusi poważne przeprojektowanie procesora.

— Rui F Ribeiro

Dotyczy to exploitów typu Spectre / Meltdown, są to podstawowe problemy projektowe, które będą nadal dawać. Ale napisałeś, że tak jest w przypadku bugsseriali i to po prostu źle. Większość błędów w projektowaniu procesorów ma pełne obejście programowe, które kosztuje tylko niewielką wydajność. Jeśli jądro zastosuje obejście, błąd jest nieszkodliwy.

— Gilles „SO- przestań być zły”

@Rui och, myślę, że nie wyraziłem się wystarczająco jasno - miałem na myśli, że artykuł nie odpowiedział na pytanie zadane przez jego własny tytuł, a nie, że nie odpowiedział na to pytanie ;-). (W tym momencie tytuł artykułu brzmi: „Jak przełomowy błąd Spectre pozostał tajemnicą przez siedem miesięcy”, ale artykuł nie wyjaśnia, w jaki sposób IMO.)

— Stephen Kitt