Błąd śpiączki Cyrixa
Błąd śpiączki Cyrix to wada projektowa procesorów Cyrix 6x86 (wprowadzonych w 1996 r.), 6x86L i wczesnych 6x86MX , która umożliwia nieuprzywilejowanym programom zawieszenie komputera.
Odkrycie
Według Andrew Balsy, mniej więcej w czasie odkrycia błędu F00F w Intel Pentium , Serguei Shtyliov z Moskwy znalazł lukę w procesorze Cyrix podczas opracowywania sterownika dysku IDE w asemblerze . Alexandr Konosevich z Omska dalej badał błąd i był współautorem artykułu z Uwe Post w niemieckim magazynie technologicznym c't , nazywając go „ukrytym błędem CLI” (CLI to instrukcja, która wyłącza przerwania w architekturze x86 ). Balsa, jako członek listy mailingowej jądra Linuksa , potwierdził, że następujący program w C (który używa wbudowanego języka asemblera specyficznego dla x86 ) może zostać skompilowany i uruchomiony przez nieuprzywilejowanego użytkownika:
bez znaku c [ 4 ] = { 0x36 , 0x78 , 0x38 , 0x36 }; int main () { asm ( " movl $c, %ebx \n " "ponownie: xchgl (%ebx), %eax \n " " movl %eax, %edx \n " " jmp ponownie \n " ); }
Wykonanie tego programu czyni procesor całkowicie bezużytecznym, dopóki nie zostanie ponownie uruchomiony, ponieważ wchodzi on w nieskończoną pętlę , której nie można przerwać . Dzięki temu każdy użytkownik mający dostęp do systemu Cyrix z tym błędem może przeprowadzić atak typu „odmowa usługi” .
Jest to podobne do wykonania instrukcji Halt and Catch Fire , chociaż błąd śpiączki nie jest jedną konkretną instrukcją.
Analiza
To, co powoduje błąd, nie jest maską przerwania ani jawnym wyłączeniem przerwań. Zamiast tego anomalia w potoku instrukcji Cyrixa uniemożliwia obsługę przerwań na czas trwania pętli; ponieważ pętla nigdy się nie kończy, przerwania nigdy nie będą obsługiwane. Instrukcja xchg jest atomowa , co oznacza, że inne instrukcje nie mogą zmieniać stanu systemu podczas jej wykonywania. Aby zapewnić tę atomowość, projektanci Cyrix sprawili, że xchg jest nieprzerywalny. Jednak z powodu potokowania i przewidywania rozgałęzień kolejny xchg wchodzi do potoku przed zakończeniem poprzedniego, powodując zakleszczenie .
Obejścia
Rozwiązaniem niezamierzonych przypadków błędu jest wstawienie innej instrukcji do pętli, przy czym instrukcja nop jest dobrym kandydatem. Cyrix zasugerował serializację kodu operacji xchg, omijając w ten sposób potok. Techniki te nie będą jednak służyć do zapobiegania celowym atakom.
Błędowi można również zapobiec, wyłączając niejawne blokowanie magistrali, zwykle wykonywane przez instrukcję xchg . Osiąga się to poprzez ustawienie czwartego bitu (maska 0x10 ) w rejestrze konfiguracyjnym CCR1 .
Zobacz też
Notatki
Linki zewnętrzne
- Wczesny opis błędu autorstwa Andrew Balsy
- Rejestry Cx6x86 (i nieudokumentowane funkcje)