Control-flow Enforcement (CET)

Co musisz wiedzieć

Jak to działa

Stosy cieniowe utrzymują chroniony stan adresów powrotu, podczas gdy śledzenie rozgałęzień pośrednich ogranicza cele śledzonych rozgałęzień pośrednich. Dotyczą one różnych transferów sterowania oraz mają osobną enumerację i mechanizmy aktywacji. System operacyjny, program ładujący, plik binarny aplikacji i biblioteki uczestniczą w zapewnieniu działania chronionego środowiska wykonawczego.

Gdzie funkcja jest przydatna

Odpowiednio zbudowana aplikacja może działać z zarządzanym przez system operacyjny stosem cieniowym, dzięki czemu niezgodny adres powrotu wyzwala zdefiniowany wyjątek, zamiast po cichu przekierowywać wykonanie. Polityka zgodności może się różnić w przypadku starszych modułów oraz ochrony w trybie użytkownika w porównaniu z trybem nadzorcy.

Jak sprawdzać obsługę i włączenie

Sprawdź bit 7 w CPUID.07H.00H:ECX pod kątem obsługi stosu cieniowego oraz bit 20 w EDX pod kątem śledzenia rozgałęzień pośrednich, a następnie sprawdź udokumentowany przez system operacyjny stan ochrony procesu. Sam dostępny bit procesora nie gwarantuje aktywnego egzekwowania ochrony dla działającego programu.

Możliwości sprzętowe, stan włączenia oraz egzekwowanie ochrony muszą być sprawdzane osobno. Procesor może obsługiwać zabezpieczenie, podczas gdy system operacyjny, aplikacja lub zasady maszyny wirtualnej go nie aktywują. Pole obsługi w bazie danych nie jest atestacją działającego systemu.

Czego ta funkcja nie określa

Pole CET nie dowodzi, że obie podfunkcje są obecne lub włączone. CET nie czyni pliku binarnego godnym zaufania, nie zapobiega każdemu błędowi uszkodzenia pamięci ani nie zastępuje aktualizacji. Globalne wyłączenie ochrony nie jest standardowym rozwiązaniem problemu z awariami aplikacji.

Zgodność i wydajność w praktyce

Należy dbać o aktualność systemu operacyjnego, oprogramowania układowego i powiązanego środowiska wykonawczego. Jeżeli zabezpieczenie ujawni problem ze zgodnością, należy w pierwszej kolejności skorzystać z diagnostyki producenta i oficjalnych aktualizacji. Zmiana ogólnego przełącznika ochrony może wpłynąć na niepowiązane aplikacje i powinna być prowadzona zgodnie z jednoznacznymi zasadami wdrażania i przywracania.

Praktyczna lista kontrolna weryfikacji

1. Zanotuj dokładny model procesora lub platformy oraz wersje używanej aplikacji, systemu operacyjnego i środowiska wykonawczego. Zachowaj dokładne sformułowanie błędu lub wymagania.
2. Sprawdź dokumentację producenta dla danego modelu, a następnie zweryfikuj faktyczne możliwości i stan włączenia w środowisku, w którym działa program.
3. Porównaj każde wymaganie wybranego pliku binarnego lub backendu. Podobnie nazwana funkcja, alias lub ogólne oznaczenie technologii nie są wystarczające.
4. Upewnij się, że aplikacja wybrała zamierzoną implementację. Użyj jej udokumentowanej diagnostyki oraz obsługiwanego mechanizmu fallback, gdy wymagania nie są spełnione.
5. Wprowadzaj jednorazowo tylko jedną obsługiwaną zmianę i powtarzaj to samo obciążenie testowe. Zachowaj oryginalną konfigurację oraz dostępną ścieżkę przywracania.

Gdy funkcja jest wymieniona, lecz oprogramowanie nie może z niej skorzystać

Zacznij od elementu, w którym bezpośrednio występuje błąd. Baza danych sprzętu opisuje zarejestrowane możliwości; system operacyjny lub hipernadzorca może udostępniać inne środowisko efektywne. Błąd nieprawidłowej instrukcji (illegal instruction) wymaga także zbadania faktycznej instrukcji powodującej błąd oraz kompilacji pliku binarnego, ponieważ uszkodzenie danych lub inna nieobsługiwana instrukcja może wywołać podobny objaw.

Zainstaluj wersję aplikacji, sterownika lub środowiska wykonawczego obsługiwaną na danej platformie i w razie potrzeby użyj udokumentowanej przez producenta kompilacji bazowej lub awaryjnej. Aktualizacja oprogramowania nie może utworzyć instrukcji, której procesor fizycznie nie posiada. Modyfikacje oprogramowania układowego i zasad bezpieczeństwa powinny przebiegać zgodnie z procedurą producenta systemu i planem przywracania, a nie ogólnikowym schematem optymalizacji.

Powiązane funkcje i przydatne rozróżnienia

CET-IBT · Stosy cieniowe CET · Execute Disable (NX) · OS Guard i SMEP

Źródła i zakres niniejszego opisu

Intel 64 and IA-32 Architectures Software Developer's Manual · Jądro Linux: stos cieniowy Control-flow Enforcement Technology

Te źródła definiują zachowanie architektoniczne i wymagania oprogramowania. Nie weryfikują one niezależnie każdej wartości funkcji na powiązanej stronie modelu sprzętu. W celu sprawdzenia obsługi przez model należy skorzystać z materiałów producenta na tej stronie i sprawdzić efektywną konfigurację systemu. Niniejszy artykuł nie zawiera wyników testów wydajnościowych, certyfikacji ani daty niezależnego przeglądu.

Powiązane

Te elementy są powiązane z tym artykułem. Typ jest podany przy każdym łączu.

Źródła i weryfikacja

Własność redakcyjna: Feex. Nie odnotowano daty niezależnego przeglądu. Jak prowadzimy badania.

• Intel 64 and IA-32 Architectures Software Developer's Manual · Tomy 1 i 2 opisują wymienione rodziny instrukcji oraz CPUID; tom 3 opisuje stan, stronicowanie, VMX i mechanizmy ochrony. Dokumentacja architektury nie przesądza o obsłudze w konkretnym modelu.
• Jądro Linux: stos cieniowy Control-flow Enforcement Technology · Rozróżnia wsparcie sprzętowe, znaczniki binarne, aktywację w programie ładującym i aktywną ochronę na poziomie wątku. Opisuje IBT i stosy cieniowe jako oddzielne mechanizmy.