Wbudowany hiperwizor

Wbudowany hiperwizor to hiperwizor obsługujący wymagania systemów wbudowanych .

Wymagania dotyczące wbudowanego hiperwizora różnią się od hiperwizorów ukierunkowanych na aplikacje serwerowe i desktopowe. Wbudowany hiperwizor jest od samego początku projektowany w urządzeniu wbudowanym, a nie ładowany po wdrożeniu urządzenia. Podczas gdy środowiska stacjonarne i korporacyjne używają hiperwizorów do konsolidacji sprzętu i izolowania środowisk komputerowych od siebie, w systemie wbudowanym różne komponenty zwykle działają wspólnie, aby zapewnić funkcjonalność urządzenia. Wirtualizacja mobilna pokrywa się z wirtualizacją systemów wbudowanych i ma wspólne przypadki użycia.

Typowe atrybuty wbudowanej wirtualizacji obejmują wydajność, bezpieczeństwo, komunikację, izolację i możliwości pracy w czasie rzeczywistym.

Tło

Wirtualizacja oprogramowania jest głównym tematem w przestrzeni korporacyjnej od późnych lat 60. XX wieku, ale dopiero od początku XXI wieku jej zastosowanie pojawiło się w systemach wbudowanych. Wykorzystanie wirtualizacji i jej implementacja w postaci hypervisora ​​w systemach wbudowanych bardzo różni się od aplikacji korporacyjnych. Efektywna implementacja wbudowanego hiperwizora musi uwzględniać szereg problemów specyficznych dla tego typu aplikacji. Kwestie te obejmują wysoce zintegrowany charakter systemów wbudowanych, wymóg szybkiej komunikacji izolowanych bloków funkcjonalnych w systemie, potrzebę wydajności w czasie rzeczywistym/deterministycznej, środowisko docelowe o ograniczonych zasobach oraz szeroki zakres wymagań dotyczących bezpieczeństwa i niezawodności.

Hypervisor

Hiperwizor zapewnia jedno lub więcej środowisk wirtualizacji oprogramowania, w których inne oprogramowanie, w tym systemy operacyjne , może działać z pozornym pełnym dostępem do bazowego sprzętu systemowego, podczas gdy w rzeczywistości taki dostęp znajduje się pod pełną kontrolą hiperwizora. Te środowiska wirtualne nazywane są maszynami wirtualnymi (VM), a hiperwizor zazwyczaj obsługuje wiele maszyn wirtualnych zarządzanych jednocześnie.

Klasyfikacja

Hiperwizory są ogólnie klasyfikowane jako typ 1 lub typ 2, w zależności od tego, czy hiperwizor działa wyłącznie w trybie nadzorcy lub trybie uprzywilejowanym (typ 1), czy też sam jest hostowany przez system operacyjny jako zwykła aplikacja (typ 2).

Hiperwizory typu 1 zarządzają kluczowymi zasobami systemowymi wymaganymi do utrzymania kontroli nad maszynami wirtualnymi i zapewniają minimalną zaufaną bazę obliczeniową (TCB). Hiperwizory typu 2 zazwyczaj działają jako aplikacje w systemie operacyjnym o bardziej ogólnym przeznaczeniu, polegając na usługach systemu operacyjnego do zarządzania zasobami systemowymi. Obecnie rozszerzenia jądra są często ładowane w celu wykorzystania sprzętu z obsługą wirtualizacji.

Wbudowany hiperwizor

Wbudowany hiperwizor to najczęściej hiperwizor typu 1, który obsługuje wymagania rozwoju systemów wbudowanych . Zobacz referencje i bardziej szczegółową dyskusję.

Wymagania te podsumowano poniżej.

• Mały, szybki hypervisor z obsługą wielu izolowanych maszyn wirtualnych;
• Obsługa lekkiej, ale bezpiecznej enkapsulacji komponentów podsystemu o średnim ziarnie, które silnie ze sobą współpracują;
• Komunikacja o dużej przepustowości i małych opóźnieniach między komponentami systemu, podlegająca konfigurowalnej, ogólnosystemowej polityce bezpieczeństwa;
• Minimalny wpływ na zasoby systemowe i gwarancje opóźnień w czasie rzeczywistym;
• Możliwość wdrożenia polityki planowania między maszynami wirtualnymi i zapewnienia obsługi komponentów systemu czasu rzeczywistego;

Realizacja

Wbudowany hiperwizor zwykle udostępnia wiele maszyn wirtualnych, z których każda emuluje platformę sprzętową, na której działa zwirtualizowane oprogramowanie. Maszyna wirtualna może emulować natywny sprzęt, w którym to przypadku osadzony kod działający na rzeczywistej maszynie będzie działał na maszynie wirtualnej i odwrotnie. Emulacja natywnego sprzętu nie zawsze jest możliwa lub pożądana, a zamiast tego można zdefiniować platformę wirtualną .

Gdy maszyna wirtualna zapewnia platformę wirtualną, oprogramowanie gościa musi zostać przeniesione , aby działać w tym środowisku, jednak ponieważ platformę wirtualną można zdefiniować bez polegania na natywnym sprzęcie, oprogramowanie gościa obsługujące platformę wirtualną może działać bez modyfikacji na różnych różnych platformach sprzętowych obsługiwane przez hiperwizora.

Wbudowane hiperwizory wykorzystują parawirtualizację lub wykorzystują funkcje wirtualizacji podstawowego procesora. Parawirtualizacja jest wymagana w przypadkach, gdy sprzęt nie pomaga i często obejmuje rozległe modyfikacje architektury rdzenia obsługującego jądro jądra gościa. Emulacja sprzętu na poziomie rejestru jest rzadko spotykana we wbudowanych hiperwizorach, ponieważ jest bardzo złożona i powolna. Niestandardowy charakter systemów wbudowanych oznacza, że ​​potrzeba obsługi niezmodyfikowanego, wyłącznie binarnego oprogramowania gościa, które wymaga tych technik, jest rzadka.

Rozmiar i wydajność implementacji jest również problemem dla wbudowanego hiperwizora, ponieważ systemy wbudowane są często znacznie bardziej ograniczone pod względem zasobów niż platformy stacjonarne i serwerowe. Pożądane jest również, aby hiperwizor utrzymywał jak najdokładniej natywną prędkość, reakcję w czasie rzeczywistym oraz determinizm i efektywność energetyczną bazowej platformy sprzętowej.

Projekt hiperwizora

Implementacje aplikacji systemów wbudowanych najczęściej opierały się na małych projektach mikrojądra i jądra separacji , z wbudowaną wirtualizacją jako integralną funkcją. Zostało to wprowadzone w PikeOS w 2005 roku. Przykłady tych podejść zostały opracowane przez takie firmy jak Open Kernel Labs (mikrojądro, po którym następuje jądro separacji) i LynuxWorks (jądro separacji). Wydaje się, że VirtualLogix stoi na stanowisku, że podejście oparte na dedykowanym monitorze maszyny wirtualnej (VMM) byłoby jeszcze mniejsze i bardziej wydajne. Kwestia ta jest przedmiotem toczącej się debaty. Jednak główny punkt sporny jest taki sam dla wszystkich stron dyskusji – duże znaczenie ma szybkość i rozmiar wdrożenia (dla danego poziomu funkcjonalności). Na przykład: „… hiperwizory do użytku wbudowanego muszą działać w czasie rzeczywistym, a także ograniczać zasoby”.

Wymagania dotyczące zasobów

Systemy wbudowane są zazwyczaj bardzo ograniczone pod względem zasobów ze względu na koszty i ograniczenia techniczne sprzętu. Dlatego ważne jest, aby wbudowany hiperwizor był jak najbardziej wydajny. Projekty oparte na mikrojądrze i jądrze separacji pozwalają na małe i wydajne hiperwizory. Tak więc wbudowane hiperwizory mają zwykle ślad pamięci od kilkudziesięciu do kilkuset kilobajtów, w zależności od wydajności implementacji i poziomu dostarczanej funkcjonalności. Implementacja wymagająca kilku megabajtów pamięci (lub więcej) jest generalnie nie do zaakceptowania.

Dzięki małej TCB wbudowanego hiperwizora typu 1 system może być bardzo bezpieczny i niezawodny. Standardowe techniki inżynierii oprogramowania, takie jak inspekcje kodu i systematyczne testowanie, mogą być wykorzystane do zmniejszenia liczby błędów w tak małej bazie kodu do niewielkiego ułamka defektów, których należy się spodziewać w przypadku połączenia hiperwizora i systemu-gościa, które mogą być Łącznie 100 000–300 000 linii.

Komunikacja maszyn wirtualnych

Jedną z najważniejszych funkcji wymaganych we wbudowanym hiperwizorze jest bezpieczny mechanizm przekazywania komunikatów, który jest potrzebny do obsługi komunikacji między procesami w czasie rzeczywistym. W środowisku osadzonym system zwykle ma wiele ściśle powiązanych zadań, z których niektóre mogą wymagać bezpiecznej izolacji od siebie. W środowisku zwirtualizowanym wbudowany hiperwizor będzie obsługiwał i wymuszał izolację między wieloma maszynami wirtualnymi. Te maszyny wirtualne będą zatem wymagać dostępu do mechanizmu, który zapewnia komunikację między zadaniami z małymi opóźnieniami.

Mechanizm komunikacji międzyprocesowej (IPC) może być wykorzystany do realizacji tych funkcji, jak również wywołania wszystkich usług systemowych i zaimplementowany w sposób zapewniający utrzymanie pożądanego poziomu izolacji VM. Ponadto, ze względu na znaczący wpływ na wydajność systemu, taki mechanizm IPC powinien być wysoce zoptymalizowany pod kątem minimalnych opóźnień.

Wymagania sprzętowe

Wbudowany hiperwizor musi mieć pełną kontrolę nad zasobami systemowymi, w tym dostępem do pamięci, aby zapewnić, że oprogramowanie nie może wydostać się z maszyny wirtualnej. Dlatego hiperwizor wymaga, aby docelowy procesor zapewniał obsługę zarządzania pamięcią (zwykle przy użyciu MMU ). Wiele wbudowanych procesorów, w tym ARM , MIPS i PowerPC , podążyło za dostawcami układów do komputerów stacjonarnych i serwerów, dodając sprzętową obsługę wirtualizacji. Jednak nadal istnieje duża część wbudowanych procesorów, które nie zapewniają takiej obsługi i wymagany jest hiperwizor obsługujący parawirtualizację .

Procesory ARM wyróżniają się tym, że większość ich projektów procesorów klasy aplikacji obsługuje technologię o nazwie ARM TrustZone, która zapewnia zasadniczo wsparcie sprzętowe dla jednej uprzywilejowanej i jednej nieuprzywilejowanej maszyny wirtualnej. Zwykle minimalny system operacyjny Trusted Execution Environment (TEE) jest uruchamiany w bezpiecznym świecie, a natywne jądro działa w niezabezpieczonym świecie.

Przypadków użycia

Niektóre z najczęstszych przypadków użycia wbudowanego hiperwizora to:

1. Niezależność systemu operacyjnego

Projektanci systemów wbudowanych mogą mieć wiele sterowników sprzętowych i usług systemowych, które są specyficzne dla platformy docelowej. Jeśli wymagana jest obsługa więcej niż jednego systemu operacyjnego na platformie, jednocześnie lub kolejno przy użyciu wspólnego projektu sprzętowego, wbudowany hiperwizor może znacznie uprościć zadanie. Takie sterowniki i usługi systemowe można wdrożyć tylko raz dla środowiska zwirtualizowanego; usługi te są następnie dostępne dla dowolnego hostowanego systemu operacyjnego. Ten poziom abstrakcji umożliwia również programistom systemów wbudowanych implementację lub zmianę sterownika lub usługi w sprzęcie lub oprogramowaniu w dowolnym momencie, bez widocznego wpływu na hostowany system operacyjny.

2. Obsługa wielu systemów operacyjnych na jednym procesorze

Zwykle jest to używane do uruchamiania systemu operacyjnego czasu rzeczywistego (RTOS) dla funkcji czasu rzeczywistego niskiego poziomu (takich jak stos komunikacyjny), przy jednoczesnym uruchomieniu systemu operacyjnego ogólnego przeznaczenia (GPOS), takiego jak Linux lub Windows , aby obsługują aplikacje użytkownika, takie jak przeglądarka internetowa lub kalendarz. Celem może być modernizacja istniejącego projektu bez dodatkowej złożoności drugiego procesora lub po prostu zminimalizowanie zestawienia materiałów (BoM).

3. Bezpieczeństwo systemu

Wbudowany hiperwizor jest w stanie zapewnić bezpieczną enkapsulację dowolnego podsystemu zdefiniowanego przez programistę, dzięki czemu zaatakowany podsystem nie może ingerować w inne podsystemy. Na przykład podsystem szyfrowania musi być silnie chroniony przed atakiem, aby zapobiec wyciekowi informacji, które szyfrowanie ma chronić. Ponieważ wbudowany hiperwizor może zamknąć podsystem w maszynie wirtualnej, może następnie wymusić wymagane zasady bezpieczeństwa dla komunikacji do iz tego podsystemu.

4. Niezawodność systemu

Hermetyzacja komponentów podsystemu w maszynie wirtualnej gwarantuje, że awaria dowolnego podsystemu nie będzie miała wpływu na inne podsystemy. Ta hermetyzacja zapobiega rozprzestrzenianiu się błędów z podsystemu w jednej maszynie wirtualnej do podsystemu w innej maszynie wirtualnej, poprawiając niezawodność. Może to również umożliwić automatyczne zamknięcie i ponowne uruchomienie podsystemu po wykryciu błędu. Może to być szczególnie ważne w przypadku sterowników urządzeń wbudowanych, ponieważ występuje tam największa liczba błędów, a tym samym jest to najczęstsza przyczyna awarii systemu operacyjnego i niestabilności systemu. Umożliwia również enkapsulację systemów operacyjnych, które niekoniecznie zostały zbudowane zgodnie ze standardami niezawodności wymaganymi od nowego projektu systemu.

5. Dynamiczna aktualizacja oprogramowania systemowego

Oprogramowanie lub aplikacje podsystemu można bezpiecznie aktualizować i testować pod kątem integralności, pobierając je na bezpieczną maszynę wirtualną przed „uruchomieniem” w działającym systemie. Nawet jeśli ten proces się nie powiedzie, system może powrócić do poprzedniego stanu poprzez ponowne uruchomienie oryginalnego podsystemu oprogramowania/aplikacji, bez zatrzymywania działania systemu.

6. Ponowne wykorzystanie starszego kodu

Wirtualizacja pozwala na używanie starszego kodu wbudowanego w środowisku systemu operacyjnego, w którym został opracowany i zweryfikowany, jednocześnie uwalniając programistę od korzystania z innego środowiska systemu operacyjnego w oddzielnej maszynie wirtualnej dla nowych usług i aplikacji. Starszy kod osadzony, napisany dla określonej konfiguracji systemu, może przejąć wyłączną kontrolę nad wszystkimi zasobami systemowymi pamięci, wejścia/wyjścia i procesora. Tę bazę kodu można ponownie wykorzystać w niezmienionej postaci w alternatywnych konfiguracjach systemu we/wy i pamięci za pomocą maszyny wirtualnej w celu przedstawienia mapy zasobów i funkcjonalności zgodnej z pierwotną konfiguracją systemu, skutecznie oddzielając dotychczasowy kod od specyfiki nowego lub zmodyfikowanego projektu sprzętu.

Tam, gdzie dostępny jest dostęp do kodu źródłowego systemu operacyjnego, parawirtualizacja jest powszechnie stosowana do wirtualizacji systemu operacyjnego na procesorach bez obsługi wirtualizacji sprzętowej, a zatem aplikacje obsługiwane przez system operacyjny mogą również działać w niezmodyfikowanej i bez ponownej kompilacji w nowych projektach platform sprzętowych.

Nawet bez dostępu do źródła, starszy kod binarny może być wykonywany w systemach działających na procesorach obsługujących sprzętową wirtualizację, takich jak technologie AMD-V , Intel VT oraz najnowsze procesory ARM z obsługą wirtualizacji. Starszy kod binarny mógłby działać całkowicie niezmodyfikowany na maszynie wirtualnej z całym mapowaniem zasobów obsługiwanym przez wbudowany hiperwizor, przy założeniu, że sprzęt systemowy zapewnia równoważną funkcjonalność.

7. Ochrona IP

Cenna zastrzeżona własność intelektualna może wymagać ochrony przed kradzieżą lub niewłaściwym użyciem, gdy platforma wbudowana jest wysyłana do dalszych prac rozwojowych przez (na przykład) klienta OEM . Wbudowany hiperwizor umożliwia ograniczenie dostępu innych komponentów oprogramowania systemowego do określonej części systemu zawierającej IP, która wymaga ochrony.

8. Segregacja licencji na oprogramowanie

Własność intelektualna oprogramowania działająca w ramach jednego schematu licencjonowania może być oddzielona od własności intelektualnej innego oprogramowania działającej w ramach innego schematu. Na przykład wbudowany hiperwizor może zapewnić izolowane środowisko wykonawcze dla prawnie zastrzeżonego oprogramowania współdzielącego procesor z oprogramowaniem open source podlegającym licencji GPL.

9. Migracja aplikacji z systemów jednordzeniowych do wielordzeniowych

Ponieważ nowe procesory wykorzystują architekturę wielordzeniową w celu zwiększenia wydajności, wbudowany hiperwizor może zarządzać bazową architekturą i udostępniać jednoprocesorowe środowisko starszym aplikacjom i systemom operacyjnym, wydajnie wykorzystując nowy projekt systemu wieloprocesorowego. W ten sposób zmiana środowiska sprzętowego nie wymaga zmiany istniejącego oprogramowania.

Produkty komercyjne

• Crucible firmy Star Lab Corp.
• Cross-OS Hypervisor — umożliwia natywną pracę aplikacji na pojedynczej platformie systemu operacyjnego firmy MapuSoft Technologies, Inc.
• OKL4 Hypervisor — obsługuje inteligentne podłączone urządzenia oparte na architekturze ARM (wbudowane, mobilne). Używany w aplikacjach wrażliwych na obronę i bezpieczeństwo. Obsługiwane komercyjnie przez Cog Systems.