Jakie są potencjalne pułapki związane z minimalnym jądrem, które uruchamia kod zarządzany?
14
Załóżmy, że chcę zbudować system operacyjny oparty na bardzo małym macierzystym dolnym jądrze, które działa jako interpreter / środowisko wykonawcze kodu zarządzanego i większe górne jądro skompilowane do nienatywnego języka maszynowego (bajtowy kod Java, CIL itp.). Przykładami podobnych systemów operacyjnych byłyby Osobliwość i Kosmos .
Jakie pułapki i wyzwania związane z programowaniem wiążą się z pisaniem systemu operacyjnego z tego rodzaju infrastrukturą w przeciwieństwie do rozwiązania czysto natywnego?
W zależności od języka może istnieć wiele wyzwań rozwojowych:
Wskaźniki: Jeśli język nie ma wskaźników, wykonywanie zadań będzie względnie łatwe. Na przykład możesz użyć wskaźników, aby zapisać w pamięci VGA i wydrukować na ekranie. Jednak w języku zarządzanym będziesz potrzebować pewnego rodzaju „plug” (z C / C ++), aby zrobić to samo.
Montaż: system operacyjny zawsze wymaga montażu. Języki takie jak C #, Java itp. Nie działają z nim tak dobrze, w przeciwieństwie do C / C ++. W C lub C ++ możesz również mieć wbudowany zestaw, który jest bardzo, bardzo przydatny do wielu zadań. Jest WIELE przypadków, w których jest to potrzebne (przykłady w x86): ładowanie GDT, ładowanie IDT, włączanie stronicowania, konfigurowanie przerwań IRQ itp.
Kontrola: jeśli używasz czegoś takiego jak Kosmos, nie masz pełnej kontroli. Kosmos jest mikro-jądrem i zasadniczo „ładuje” twoje „jądro”. Możesz zaimplementować coś takiego jak Kosmos od zera, jeśli naprawdę tego chcesz, może to jednak potrwać bardzo długo.
Koszty ogólne: w przypadku języków zarządzanych istnieje DUŻO kosztów ogólnych w porównaniu do C lub nawet C ++. Rzeczy takie jak Kosmos muszą zaimplementować wiele rzeczy, zanim będzie można uruchomić jądro świata C # hello. W C jesteś gotowy do pracy, nie potrzebujesz prawdziwej konfiguracji. W C ++ jest tylko kilka rzeczy, które należy zaimplementować, aby móc korzystać z niektórych funkcji C ++.
Struktury: W C / C ++ istnieją struktury, których nie ma wiele zarządzanych języków, dlatego trzeba zaimplementować jakiś sposób posiadania struktury. Na przykład, jeśli chcesz załadować IDT (tablicę deskryptorów przerwań), w C / C ++, możesz utworzyć strukturę (z spakowanym atrybutem) i załadować ją za pomocą instrukcji lidt instrukcji ASM x86 . W języku zarządzanym jest to o wiele trudniejsze ...
Języki zarządzane pod względem składni są łatwiejsze, jednak wiele rzeczy związanych z systemem operacyjnym często nie jest zbyt dobrze dopasowanych. Nie oznacza to, że nie można ich używać, jednak często zaleca się coś takiego jak C / C ++.
Ta odpowiedź jest dość słaba. Jakie są „stosunkowo łatwe zadania”, których nie można wykonać bez wskaźników (z wyjątkiem małego fundamentu)? Jakie części wymagają montażu? Jakiej kontroli brakuje? Na czym opierasz swoje stwierdzenie dotyczące kosztów ogólnych? Dlaczego nie możesz mieć struktur w zarządzanym języku?
Gilles „SO- przestań być zły”,
1. Nie ma powodu, dla którego język zarządzany nie oferowałby możliwości dostępu do pamięci VGA, tylko prymitywne mapowanie / odwzorowywanie musiałoby być dostarczone jako operacja podstawowa (operacja podstawowa zarządzania pamięcią). 2. Niektóre przełączanie zadań (np. Zapisywanie rejestrów) zwykle musi być wykonywane jako kod asemblera, ale jest bardzo zlokalizowane, nie jest to argument za tym, aby mieć 99% systemu operacyjnego w języku zarządzanym. Manipulowanie MMU to prymitywne zarządzanie pamięcią. 4. C także wymaga konfiguracji (ustaw stos i stos); języki zarządzane wymagają nieco większej konfiguracji, ale nie ma jakościowej różnicy.
Gilles 'SO - przestań być zły'
@Gilles, pytanie brzmi: jakie są wyzwania rozwojowe związane z używaniem zarządzanego języka. Są to wyzwania rozwojowe, jednak nadal możesz z powodzeniem je pokonać ...
Problem polega na tym, że rodzaje błędów, które mogą powodować lukę w zabezpieczeniach, są bardzo różne od tych, do których przywykli badacze bezpieczeństwa. W tradycyjnym mikrojądrze wszystkie sterowniki i inne części jądra są izolowane od siebie, uruchamiając je w różnych przestrzeniach adresowych. W mikrojądrze, w którym izolacja jest implementowana za pomocą kodu zarządzanego sprawdzania typu, unikasz ogromnych kosztów przełączania przestrzeni adresowej za każdym razem, gdy potrzebujesz skorzystać z pod-usługi, ale kompromis polega na tym, że ocena mechanizmu izolacji jest trudniejsza.
Każda konkretna część jądra (powiedzmy sterownik urządzenia) napisana w języku zarządzanym jest bezpieczna wtedy i tylko wtedy, gdy moduł sprawdzania typu twierdzi, że sterownik jest bezpieczny, a moduł sprawdzania typów nie zawiera błędów. Sprawdzanie typów jest więc częścią jądra jądra. W praktyce wydaje się, że kontrolery typów są znacznie większe i bardziej skomplikowane niż tradycyjne rdzenie mikrojądrowe. Oznacza to, że powierzchnia ataku jest potencjalnie większa.
Nie wiem, czy tradycyjne techniki izolacji mikrojądra czy techniki izolacji oparte na kodzie zarządzanym są naprawdę mniej lub bardziej niezawodne. Występuje tutaj problem ładowania początkowego: dopóki techniki izolacji kodu zarządzanego nie będą szeroko stosowane, nie będziemy wiedzieć, jak często są niepewne. Ale nie wiedząc, jak bardzo są niepewni, trudno jest wdrożyć je w sytuacjach krytycznych dla bezpieczeństwa.
Uważam te argumenty za bardzo dziwne. (To prawda, że moje uprzedzenia w metodach formalnych mogą być stronnicze, ale nie jest to jedyna podstawa mojej opinii.) Sprawdzanie typów nie jest tak złożone, w porównaniu z mikrojądrem i MMU. Na przykład mikrojądro Coq ma około 14kLoC OCaml - więcej niż mikrojądro, ale nie tyle, i napisane w języku mniej podatnym na błędy niż większość jąder (bez C lub asemblera). Sprawdzanie typów nie jest podatne na warunki wyścigowe, które są szczególnie subtelną klasą błędów.
Gilles „SO- przestań być zły”,
Kod zarządzany daje lepszą możliwość radzenia sobie z pewną klasą błędów; na przykład analiza przepływu informacji może udowodnić brak kanałów bocznych (prawdopodobnie zajmie to dużo pracy i nie wiem, w jakim stopniu zostało to zrobione, ale w zasadzie jest wykonalne), podczas gdy izolacja sprzętowa pozwala tylko przetestować kanały boczne, o których myślałeś.
Gilles 'SO - przestań być zły'
Z praktycznego punktu widzenia kilka maszyn wirtualnych zapewniających izolację uzyskało certyfikat na poziomie EAL5 i wyższym. Oto dwa przykłady, które możesz mieć w portfelu, jeśli jesteś Europejczykiem, ponieważ są one używane w kartach inteligentnych, takich jak karty kredytowe: MULTOS , otwarta platforma Java Card . W społeczności zajmującej się ocenami bezpieczeństwa słyszałem wiele wątpliwości, że izolacja MMU mogłaby wykraczać poza EAL2.
Słyszałem, jak twierdził ( badacz pracujący nad konkurencyjną techniką mikrojądra ), że bardzo mało wiadomo na temat oceny bezpieczeństwa systemów, które można rozszerzyć za pomocą zarządzanego kodu.
Problem polega na tym, że rodzaje błędów, które mogą powodować lukę w zabezpieczeniach, są bardzo różne od tych, do których przywykli badacze bezpieczeństwa. W tradycyjnym mikrojądrze wszystkie sterowniki i inne części jądra są izolowane od siebie, uruchamiając je w różnych przestrzeniach adresowych. W mikrojądrze, w którym izolacja jest implementowana za pomocą kodu zarządzanego sprawdzania typu, unikasz ogromnych kosztów przełączania przestrzeni adresowej za każdym razem, gdy potrzebujesz skorzystać z pod-usługi, ale kompromis polega na tym, że ocena mechanizmu izolacji jest trudniejsza.
Każda konkretna część jądra (powiedzmy sterownik urządzenia) napisana w języku zarządzanym jest bezpieczna wtedy i tylko wtedy, gdy moduł sprawdzania typu twierdzi, że sterownik jest bezpieczny, a moduł sprawdzania typów nie zawiera błędów. Sprawdzanie typów jest więc częścią jądra jądra. W praktyce wydaje się, że kontrolery typów są znacznie większe i bardziej skomplikowane niż tradycyjne rdzenie mikrojądrowe. Oznacza to, że powierzchnia ataku jest potencjalnie większa.
Nie wiem, czy tradycyjne techniki izolacji mikrojądra czy techniki izolacji oparte na kodzie zarządzanym są naprawdę mniej lub bardziej niezawodne. Występuje tutaj problem ładowania początkowego: dopóki techniki izolacji kodu zarządzanego nie będą szeroko stosowane, nie będziemy wiedzieć, jak często są niepewne. Ale nie wiedząc, jak bardzo są niepewni, trudno jest wdrożyć je w sytuacjach krytycznych dla bezpieczeństwa.
źródło