TPM niezgodny z systemem gościa

TPM niezgodny z systemem gościa wskazuje na wirtualny TPM maszyny wirtualnej niekompatybilny z wymaganiami zainstalowanego systemu operacyjnego.

TPM niezgodny z systemem gościa – czym jest ten problem

Komunikat „TPM niezgodny z systemem gościa” dotyczy sytuacji, w której moduł TPM udostępniany maszynie wirtualnej nie odpowiada wymaganiom systemu operacyjnego uruchomionego wewnątrz tej maszyny. TPM, czyli Trusted Platform Module, służy do przechowywania i ochrony kluczy kryptograficznych, obsługi bezpiecznego rozruchu oraz potwierdzania, że środowisko uruchomieniowe ma oczekiwaną konfigurację. W przypadku systemu gościa nie chodzi zwykle o fizyczny układ znajdujący się na płycie głównej, lecz o jego wirtualny odpowiednik.

System operacyjny może sprawdzać między innymi obecność TPM w wymaganej wersji, dostępność określonych funkcji kryptograficznych, sposób generowania identyfikatora modułu oraz zgodność ustawień bezpieczeństwa. Jeżeli wirtualny moduł został dodany w nieodpowiednim trybie, jest wyłączony, ma inną generację albo został zmieniony po instalacji systemu, pojawia się informacja o niezgodności. Taki stan może blokować instalację, aktualizację lub uruchomienie systemu, a czasem powodować problemy z szyfrowaniem dysku i odzyskiwaniem danych.

Niezgodność nie musi oznaczać uszkodzenia komputera. Często jest skutkiem różnicy między konfiguracją oczekiwaną przez system gościa a konfiguracją ustawioną w programie do obsługi maszyn wirtualnych. Znaczenie ma także sposób utworzenia danej maszyny, jej format konfiguracji, tryb rozruchu oraz to, czy system został przeniesiony z innego środowiska.

TPM niezgodny z systemem gościa a wersje, tryby i zgodność

Wirtualny TPM nie jest prostą kopią fizycznego układu. Jest funkcją emulowaną lub dostarczaną przez warstwę oprogramowania, która musi zostać prawidłowo przypisana do konkretnej maszyny. Przy porównywaniu konfiguracji należy sprawdzić, czy system gościa oczekuje TPM 2.0, czy używany jest starszy wariant, a także czy moduł jest aktywny przed uruchomieniem systemu. Sama obecność wpisu oznaczającego TPM nie przesądza jeszcze o pełnej zgodności.

Istotny bywa również tryb uruchamiania. Nowoczesne systemy najczęściej współpracują z rozruchem UEFI i bezpiecznym rozruchem, natomiast starsza maszyna skonfigurowana z klasycznym BIOS-em może mieć ograniczenia przy korzystaniu z funkcji zabezpieczeń. Zmiana trybu po instalacji systemu może doprowadzić do braku startu, ponieważ układ partycji, wpisy rozruchowe i mechanizmy ochrony nie zawsze są wymienne bez dodatkowego przygotowania.

Warto odróżnić kilka podobnych sytuacji:

• brak wirtualnego TPM – system gościa nie widzi żadnego modułu;
• TPM w nieodpowiedniej wersji – moduł jest wykrywany, lecz nie spełnia wymagań systemu;
• uszkodzona lub niedostępna pamięć stanu – konfiguracja modułu nie może zostać odczytana;
• niezgodny tryb zabezpieczeń – ustawienia rozruchu lub szyfrowania nie pasują do instalacji;
• zmiana właściciela albo identyfikatora modułu – system traktuje środowisko jako nowe i może zażądać klucza odzyskiwania.

W przypadku systemu szyfrowanego kluczami zależnymi od TPM ostrożność ma szczególne znaczenie. Usunięcie modułu, wyczyszczenie jego stanu lub utworzenie nowego urządzenia zabezpieczającego może uniemożliwić automatyczne odblokowanie danych. Przed zmianami powinno się potwierdzić dostęp do klucza odzyskiwania i wykonać kopię ważnych plików.

TPM niezgodny z systemem gościa – typowe przyczyny i objawy

Jedną z częstszych przyczyn jest utworzenie maszyny bez modułu TPM, a następnie próba instalacji systemu, który go wymaga. Innym źródłem problemu może być skopiowanie plików maszyny na inny komputer lub przejście na inną wersję oprogramowania obsługującego maszyny wirtualne. Konfiguracja może wtedy wskazywać urządzenie, którego nowa platforma nie potrafi prawidłowo otworzyć.

Do niezgodności dochodzi także po przywróceniu migawki, odtworzeniu kopii zapasowej albo ręcznej edycji pliku konfiguracyjnego. Wirtualny moduł TPM jest powiązany ze stanem konkretnego systemu. Przywrócenie jedynie dysku wirtualnego bez odpowiadającego mu stanu zabezpieczeń może zostać odczytane jako próba uruchomienia systemu w nieznanym środowisku. Objawami bywają komunikaty o braku zgodności, żądanie klucza odzyskiwania, nieudana aktualizacja, zatrzymanie rozruchu lub powrót do ekranu naprawy systemu.

Podobny komunikat może być wywołany przez ograniczenia sprzętowe komputera gospodarza. Jeżeli firmware ma wyłączone funkcje bezpieczeństwa, aktualizacje są niekompletne albo ustawienia ochrony blokują dostęp do wymaganych mechanizmów, warstwa wirtualna może nie udostępnić poprawnego modułu. Nie należy jednak pochopnie zmieniać wszystkich ustawień firmware, ponieważ ingerencja w rozruch, szyfrowanie i zabezpieczenia może pogorszyć sytuację.

Przydatne jest zapisanie dokładnej treści komunikatu, momentu jego wystąpienia oraz ostatnich zmian. Znaczenie ma informacja, czy problem pojawił się po aktualizacji, migracji, skopiowaniu maszyny, zmianie dysku, przywróceniu kopii lub włączeniu szyfrowania. Takie dane ułatwiają rozdzielenie problemu konfiguracji od problemu z samym systemem gościa.

TPM niezgodny z systemem gościa – praktyczne sprawdzanie konfiguracji

Prace diagnostyczne powinny zaczynać się od kopii zapasowej i zabezpieczenia kluczy odzyskiwania. Następnie można sprawdzić, czy maszyna ma przypisany wirtualny moduł TPM, czy jest on aktywny oraz jaka wersja jest prezentowana systemowi. Warto również zweryfikować tryb UEFI, bezpieczny rozruch, kolejność urządzeń startowych i zgodność ustawień z wymaganiami konkretnego systemu operacyjnego.

Nie powinno się od razu usuwać modułu TPM ani tworzyć nowego. Taka operacja może zmienić zestaw kluczy i doprowadzić do utraty dostępu do zaszyfrowanego dysku. Najpierw należy ustalić, czy zachowana jest pierwotna konfiguracja, czy dostępny jest klucz odzyskiwania oraz czy problem dotyczy całej maszyny, czy tylko jednej migawki. W razie potrzeby bezpieczniej jest pracować na kopii, pozostawiając oryginalne pliki nienaruszone.

Jeżeli maszyna była przenoszona, należy sprawdzić zgodność wersji oprogramowania, uprawnień i lokalizacji plików zabezpieczeń. Przy odtwarzaniu kopii trzeba zachować powiązane elementy, a nie tylko wirtualny dysk. W niektórych przypadkach właściwym rozwiązaniem jest ponowne przypisanie istniejącego modułu do maszyny, w innych – naprawa wpisów rozruchowych lub odtworzenie konfiguracji z kopii. Zakres działania zależy od tego, czy dane są zaszyfrowane i czy system nadal uruchamia się w trybie awaryjnym.

Po każdej zmianie powinno się wykonać kontrolny start systemu, sprawdzić wykrywanie TPM, status bezpiecznego rozruchu oraz możliwość odblokowania danych. Dobrą praktyką jest także przejrzenie dzienników systemowych i komunikatów programu obsługującego maszyny wirtualne. Pozwala to ustalić, czy moduł został odrzucony z powodu wersji, braku stanu, uprawnień, konfliktu identyfikatora czy niezgodności trybu startowego.

Kiedy zgłosić TPM niezgodny z systemem gościa do serwisu

Wsparcie serwisowe jest wskazane, gdy komunikat pojawił się po migracji lub odtworzeniu kopii, system żąda klucza odzyskiwania, komputer nie przechodzi rozruchu albo nie ma pewności, które pliki odpowiadają za stan modułu. Szczególnej ostrożności wymagają przypadki z szyfrowaniem dysku, wieloma punktami przywracania lub ważnymi dokumentami zapisanymi wyłącznie w maszynie wirtualnej. W takiej sytuacji każda pochopna zmiana może utrudnić późniejsze odzyskanie dostępu.

W ramach diagnostyki można ustalić zależność między systemem gospodarza, maszyną wirtualną i systemem gościa, sprawdzić konfigurację TPM, przeanalizować komunikaty rozruchowe oraz ocenić, czy możliwe jest bezpieczne odtworzenie środowiska. W Warszawie takie czynności wykonuje Warszawskie Pogotowie Komputerowe 24/7, a naprawy z reguły kończą się w ciągu 3 dni roboczych. Przed rozpoczęciem prac powinno się przekazać informację o szyfrowaniu, kopiach zapasowych, ostatnich zmianach i ewentualnym kluczu odzyskiwania.

Do zgłoszenia warto dołączyć nazwę systemu operacyjnego, wersję programu używanego do uruchamiania maszyny, dokładną treść błędu oraz informację, czy środowisko było kopiowane lub przenoszone. Jeżeli system nadal działa, nie należy usuwać modułu TPM, kasować migawek ani resetować zabezpieczeń przed wykonaniem kopii. Jeżeli nie działa, najlepiej zachować oryginalne pliki i unikać kolejnych prób automatycznej naprawy bez rozpoznania przyczyny.