Wydział AEI Budowa Komputerów Rok akad.: 2007/2008 Sem.: 7 Skład sekcji: Michał Pawełczyk Grupa: BDSiSK2 Temat referatu: ARM dynamiczny rozwój i rozwiązanie kwestii bezpieczeństwa w oparciu o technologię TrustZone Sekcja: x e-mail/tel. kontaktowy: anghan@tlen.pl Data wykonania: 29.01.2008 Data oddania sprawozdania: Ocena: --- 1 / 17 ---
Wstęp Architektura ARM (Advanced RISC Machine, pierwotnie Acorn RISC Machine) jest 32-bitową architekturą (modelem programowym) procesorów typu RISC. Różne wersje procesorów ARM są szeroko stosowane w systemach wbudowanych (ang. embedded systems) i systemach o niskim poborze mocy, ze względu na ich energooszczędną architekturę. ARM CPU zdominowały rynek przenośnej elektroniki, gdzie niski pobór mocy jest głównym celem stworzenia przeznaczonego do użytku urządzenia. Procesor ARM jest jednym z najczęściej stosowanych procesorów na świecie. Jest używany między innymi w dyskach twardych, telefonach komórkowych, routerach, kalkulatorach a nawet w zabawkach dziecięcych. Obecnie zajmuje ponad 75% rynku 32- bitowych CPU dla systemów wbudowanych. Najbardziej udanym projektem ARM był procesor ARM7TDMI szeroko stosowany w telefonach komórkowych. Moc obliczeniowa procesorów daje projektantowi naprawdę spore możliwości. ARM umożliwia instalacje na tym procesorze systemu operacyjnego, z zaimplementowanymi mechanizmami wielowątkowości, z możliwością wykorzystania zawartego w systemie stosu TCP/IP czy systemu plików (np. FAT32). Powstało wiele takich systemów: Windows CE, NUTOS(Ethernut), i wiele dystrybucji Linuksa opatrzonym hasłem embedded (Embedded Debian, Embedded Ubuntu) Dynamiczny rozwój architektury procesorów ARM Historia Projektowanie pierwszego procesora ARM rozpoczęło się w 1983 roku, jako projekt rozwojowy angielskiej firmy Acorn Computers Ltd. Grupa inżynierów kierowana przez Rogera Wilsona i Steve'a Furbera rozpoczęła projektowanie jądra będącego ulepszoną wersją procesora MOS 6502 firmy MOS Technology. Acorn produkował w tym czasie komputery w oparciu o mikroprocesor MOS 6502, więc celem projektu było opracowanie nowego potężniejszego mikroprocesora programowalnego w podobny sposób, który dawałby większe możliwości zastosowania. Pierwsza wersja testowa, nazywana ARM1, opracowana została 22 lata temu w 1985 roku, a rok później ukończono wersję produkcyjną ARM2. ARM2 wyposażony był w 32- bitową szynę danych, 26-bitową przestrzeń adresową oraz w szesnaście 32-bitowych rejestrów. Był to w tym czasie najprostszy szeroko stosowany 32-bitowy mikroprocessor, zawierający tylko 30 tysięcy tranzystorów. Prostota wynikała głównie, jak w większości procesorów w tym czasie, braku cache. ARM2 miał z tego powodu bardzo niski pobór mocy i jednocześnie szybkość przetwarzania większą od procesora Intel 80286. Następna wersja ARM3 produkowana była z 4KB cache, co jak można się domyślić doprowadziło do poprawienia wydajności. W późnych latach osiemdziesiątych firma Apple Computer rozpoczęła współpracę z Acorn Computers w projektowaniu nowszej wersji jądra ARM. Projekt był na tyle istotny, że Acorn wydzielił grupę projektową tworząc w 1990 roku nową firmę o nazwie Advanced RISC Machines (ARM Ltd.). Wynikiem tej współpracy był procesor ARM6, udostępniony w --- 2 / 17 ---
roku 1990. Firma Apple użyła opartego na ARM6 procesora ARM610 w palmtopie (PDA) o nazwie Apple Newton. Jądro procesora ARM6 zawiera około 35 tysięcy tranzystorów i jest tylko niewiele większe od jądra ARM2 (30 tysięcy tranzystorów). Dzięki swej prostocie jądro ARM może być łączone z dodatkowymi blokami funkcjonalnymi, tworząc w jednej obudowie, mikroprocesor dostosowany do konkretnych wymagań. Jest to możliwe, gdyż podstawą działalności ARM Ltd. jest sprzedaż licencji na zaprojektowane jądra. Dzięki temu powstały także mikrokontrolery oparte na architekturze ARM. Firma DEC zakupiła licencję na architekturę ARM i na jej podstawie zaprojektowała procesor StrongARM. Przy częstotliwości 233MHz procesor ten pobierał tylko 1W mocy (najnowsze wersje StrongARM pobierają znacznie mniej). Projekt ten został następnie przejęty przez firmę Intel, na podstawie umowy procesowej między obiema firmami. Dla Intela była to szansa na zastąpienie przestarzałej architektury i960 nową architekturą StrongARM. Na podstawie StrongARM Intel zaprojektował bardzo wydajny mikroprocesor o nazwie Xscale. Najpopularniejszą architekturą wykorzystywaną przez smartphony, PDA i inne urządzenia, które nosimy ze sobą i używamy trzymając w rękach jest ARMv4. Charakterystyka budowy By pozostawić budowę procesora czystą, prostą i szybką została na sztywno związana z mikrokodem podobnie jak najprostszy procesor ośmiobitowy 6502 używany pierwotnie przez mikrokomputery Acorn. Architektura ARM zawiera następujące elementy RISC: architektura korzystająca z instrukcji load (odczytaj z pamięci)/store (zapisz do pamięci brak wsparcia dla niesymetrycznego dostępu do pamięci (obecnie wspierane w rdzeniach ARMv6) Zredukowana liczba rozkazów 16 dużych 32 bitowych rejestrów Zmienna szerokość instrukcji z 32 bitowych do łatwych w zdekodowaniu i przygotowaniu (łatwość jako koszt redukcji gęstości kodu) Większość instrukcji wykonuje się w pojedynczym cyklu maszynowym. By wynagrodzić prosty projekt w porównaniu z współczesnymi sobie procesorami takimi jak Intel 80286 i Motorola 68020, kilka unikalnych pomysłów zostało wykorzystanych. Warunkowe wykonanie większości instrukcji, redukcja skoków powrotnych i kompensacja zapobiegająca dziurom i skokom Instrukcje arytmetyczne zmieniają warunek tylko kiedy jest to pożądane 32 bitowy bufor przesuwny może zostać użyty bez stratnego wykonania z większością instrukcji arytmetycznych i obliczanych adresów Wydajne tryby adresowania indeksowego --- 3 / 17 ---
Proste, ale wydajne, dwa uprzywilejowane poziomy przerwań subsystemowe z przełączanymi bankami rejestrów Zestaw instrukcji procesora ARM stanowi rozwinięcie zestawu instrukcji MOS 6502. Główne zmiany dotyczą zwiększenia efektywności potokowego przetwarzania instrukcji. Zgodnie z założeniami architektury RISC, rozkazy są tak skonstruowane, aby wykonywały się w ściśle określonym czasie - zwykle w jednym cyklu maszynowym. Interesującą zmianą jest użycie 4-bitowego kodu warunkowego na początku każdej instrukcji. Dzięki temu każda instrukcja może być wykonana warunkowo. Ogranicza to przestrzeń dostępną,na przykład, dla instrukcji przeniesień w pamięci, ale z drugiej strony nie ma potrzeby stosowania instrukcji rozgałęzień dla kodu zawierającego wiele prostych instrukcji warunkowych. Klasycznym przykładem jest implementacja algorytmu Euklidesa wyznaczania największego wspólnego dzielnika. Funkcja w języku C wygląda następująco: int gcd(int i, int j) { while (i!= j) if (i > j) i -= j; else j -= i; return i; } W asemblerze procesora ARM pętla będzie wyglądać następująco: b test loop subgt Ri,Ri,Rj suble Rj,Rj,Ri test cmp Ri,Rj bne loop W powyższym kodzie nie widać rozgałęzień dla instrukcji if oraz else. Inną unikalną cechą zestawu instrukcji procesora ARM jest łączenie operacji przesunięcia i obrotu w rejestrze z instrukcjami arytmetycznymi, logicznymi, czy też przesłania danych z rejestru do rejestru. Dzięki temu wyrażenie języka C "a += (j << 2);" może zostać przetłumaczone przez kompilator w pojedynczą instrukcję asemblera. Przedstawione cechy powodują, że typowy program zawiera mniej linii kodu niż w przypadku innych procesorów RISC. W rezultacie jest mniejsza liczba operacji pobrania/zapisania argumentów instrukcji, więc potokowość jest bardziej efektywna. Pomimo, że procesory ARM są taktowane zegarem o stosunkowo niskiej częstotliwości są konkurencyjne w stosunku do znacznie bardziej złożonych procesorów. Procesory ARM posiadają także kilka rozwiązań rzadko spotykanych w innych procesorach RISCowych jak względne adresowanie PC (rzeczywiście, w ARM PC jest jednym z jego 16 rejestrów) i tryby pre-inkrementacji oraz post-inkrementacji. Inną rzeczą wartą wzmianki jest fakt, że w zbiorze instrukcji procesorów ARM zmieniało się coś przez cały czas. Niektóre z wczesnych procesorów (pierwotnie wersje ARM7TDMI) na przykład nie miały instrukcji do ładowania dwóch bajtów jednocześnie, --- 4 / 17 ---
wynikało z tego mówiąc wprost, że nie było możliwe wygenerowanie kodu, który zachowywał by się w przewidywalny sposób dla zmiennych C typu volatile short. ARM7 i wiele wcześniejszych modeli miało trzy stopniowy potok; etapami były dostarczane, dekodowane i wykonywane. Procesory o zwiększonej wydajności, takie jak ARM9, mają pięciostopniowy potok. Dodatkowe zmiany dla większej wydajności zawierają szybsze dodawania i bardziej skuteczną logikę przewidywania skoków. Architektura zapewnia nie natrętny sposób rozszerzania zbioru instrukcji używając koprocesorów, które mogą zostać zaadresowane używając MCR, MRC, MRRC i MCRR komend programu. Przestrzeń koprocesora jest podzielona logicznie na szesnaście koprocesorów, które są numerowane od 0 do 15, koprocesor 15 (cp15) jest zarezerwowany dla niektórych nietypowych funkcji kontrolnych jak zarządzanie cachem i operacje MMU. W urządzeniach opartych o ARM, urządzenia peryferyjne są zwykle dołączane do procesora przez mapowanie ich fizycznych rejestrów w przestrzeni pamięci ARM lub w przestrzeni koprocesora lub podłączenie do innego urządzenia (magistrala), które kieruje podłączenie do procesora. Dostęp koprocesora jest nisko utajniony więc niektóre peryferia (na przykład kontroler przerwań Xscale) zostały zaprojektowane do dostępu obiema drogami (przez pamięci i przez koprocesor). Thumb Nowsze procesory ARM posiadają skompresowany zbiór instrukcji nazwany Thumb. Używa on 16 bitowej szerokości instrukcji kodującej (ale nadal działa na 32 bitowych danych). W Thumb, mniejsze kody maszynowe mają mniejszą funkcjonalność. Na przykład, tylko skoki mogą być warunkowe i wiele kodów maszynowych nie może uzyskać dostępu do wszystkich rejestrów procesora. Jednak krótsze kody maszynowe dają możliwość polepszenia zwartości kodu mimo wszystko, nawet jeśli niektóre operacje wymagają użycia większej ilości instrukcji. Szczególnie w sytuacji gdzie pamięć portu lub szerokość magistrali jest zmuszona być mniejsza niż 32 bity, krótsze kody maszynowe pozwalają na większa wydajność niż w przypadku użycia kodów 32 bitowych, ponieważ bardziej efektywnie korzystają limitowanej przepustowości pamięci. Zwykle oprogramowanie wbudowane ma mały zasięg adresów 32 bitowej ścieżki danych i pozostaje reszta 16 bitów lub inna liczba (np. Game Boy Advance). W tej sytuacji, jest zwykle sens skompilować kod Thumb i ręcznie zoptymalizować kilka z najbardziej obciążających procesor części programu poprzez użycie (rozkazów spoza Thumb) zbioru 32 bitowych instrukcji, umiejscowienie ich w limitowanej przestrzeni pamięci o szerokości 32 bitów. Pierwszym procesorem z instrukcjami Thumb był ARM7TDMI. Wszystkie ARM9 i późniejsze rodziny, wliczając w to Xscale zawierają dekoder instrukcji Thumb. Rozszerzenie instrukcji DSP By ulepszyć architekturę ARM dla przetwarzania sygnałów cyfrowych i aplikacji multimedialnych wiele nowych instrukcji zostało dodanych do zbioru. By to pokazać konstrukcje, które posiadają ten rozszerzony zbiór instrukcji zostały oznaczone literą E w nazwie architektury (ARMv5TE i ARMv5TEJ). Nowe instrukcje są pospolite i architekturach procesorów przetwarzających cyfrowe sygnały. Są kombinacje wielokrotnego mnożenia ze znakiem, nasyconego dodawania i liczenia znaczących zer. --- 5 / 17 ---
Jazelle Technologia nazwana Jazelle DBX (Direct Bytecode execution bezpośrednie wykonanie bajt kodu) pozwala niektórym architekturom ARM wykonywać kod bajtowy Java w sprzęcie jako kolejny stan pośród innych istniejących stanów ARM i Thumb. To pozwala na przyśpieszenie dla niektórych bajt kodów podczas zgłaszania się do specjalnego oprogramowania lub innych. Pierwszym procesorem z technologią Jazelle był ARM926EJ-S: Jazelle została oznaczona literą 'J' w nazwie CPU. Technologia ta jest używana przez firmy produkujące telefony komórkowe do przyśpieszania gier i aplikacji napisanych w Java ME. Thumb-2 Technologia Thumb-2 miała debiut w rdzeniu ARM1156, który się pojawił w 2003 roku. Thumb-2 rozszerzył ograniczony zbiór instrukcji 16 bitowy z Thumb o dodatkowe instrukcje 32 bitowe by mogły objąć większy zakres. Rezultat, który jest celem Thumb-2 jest osiągnięcie zwartości kodu podobnej jak przy Thumb i osiągów podobnych do zbioru instrukcji ARM na pamięci 32 bitowej. Thumb-2 także rozszerza instrukcje ARM i Thumb o kilka dodatkowych rozkazów, wliczając w to manipulację na bitach, rozgałęzienia tablic i wykonanie warunków. Wszystkie chipy ARMv7 wspierają zbiór instrukcji Thumb-2. Niektóre chipy takie jak Cortex-M3, wspierają tylko instrukcje Thumb-2. Inne chipy z serii Cortex i ARM11 obsługują obyda tryby: zbiór instrukcji ARM i zbiór instrukcji Thumb-2. Środowisko wykonawcze Thumb (ThumbEE) ThumbEE, także znane jako Thumb-2EE, którego nazwa marketingowa brzmi Jazelle RCT, pojawił się w roku 2005. Pierwszym procesorem, który obsługiwał nową technologię był procesor Cortex-A8. ThumbEE wprowadził małe rozszerzenie do Thumb-2 tworząc solidną podstawę dla kodu generowanego w czasie uruchomienia (np. JIT compilation) by dawać sobie radę z środowiskami uruchomieniowymi. ThumbEE jest kierowany dla języków takich jak Limbo, Java, C#, Perl i Python i dopuszcza kompilatory JIT do produkowania małego skompilowanego kodu bez ingerencji w środowisko. Nowe możliwości wprowadzone przez ThumbEE zawierają automatyczne sprawdzanie null pointerów lub każdej instrukcji load i store oraz instrukcji przeznaczonych do sprawdzania rozgałęzień tablic. Został też umożliwiony dostęp do rejestrów r8-r15 (gdzie stan Jazelle/DBX Java VM jest trzymany) i możliwość rozgałęzień do uchwytów małych kawałków często wykonywanego kodu zwykle używanego do implementowania możliwości języka wysokiego poziomu. Takich jako alokacja pamięci dla nowego obiektu. Zaawansowany SIMD (NEON) Zaawansowane rozszerzenie SIMD, sprzedawane jako technologia NEON jest kombinacją 64 i 128 bitowego zbioru instrukcji SIMD (Single Instruction Multiple Data), które pozwalają ustandaryzować przyśpieszenie dla aplikacji przetwarzających media i sygnały. NEON może odtwarzać pliki MP3 dekodując je przy taktowaniu zegara na poziomie 10 Mhz. Może również uruchomić kodek mowy GSM ARM (Adaptive Multi-Rate) przy taktowaniu zegara nie większym niż 13 Mhz. Daje to możliwości zaoferowania obszernego zbioru instrukcji, oddzielne rejestry i niezależność od uruchamianego sprzętu. NEON wspiera 8-, 16-, 32-, 64 bitowe integery, liczby zmienno przecinkowe pojedynczej precyzji i operacje obróbki audio/video tak samo dobrze jak przetwarzania gier. W NEON, SIMD potrafi wykonać do 16 operacji w tym samym czasie. --- 6 / 17 ---
VFP Technologia VFP jest rozszerzeniem koprocesora w architekturze ARM. Pozwala ono przeprowadzać operacje o niskim koszcie na liczbach zmiennoprzecinkowych pojedynczej i podwójnej precyzji zgodnych z ANSI/IEEE Std 754-1985 Standard for Binary Floating-Point Arithmetic. VFP pozwala na wykonywanie operacji zmiennoprzecinkowych przydatnych w szerokim spektrum zainteresowań, które obejmuje aplikacje na takie urządzenia jak PDA, smartphone, kompresory i dekompresory głosu, grafika trójwymiarowa i cyfrowe audio, drukarki, oprogramowanie samochodowe. Architektura VFP także wspiera uruchamianie krótkich instrukcji wektorowych pozwalające na równoległość SIMD. Jest to użyteczne w aplikacjach przetwarzających grafikę i sygnały przez redukcję rozmiaru kodu i wzrost wydajności. Rozszerzenia bezpieczeństwa (TrustZone) Rozszerzenia bezpieczeństwa, sprzedawane pod nazwą technologia TrustZone(TM), zostały wprowadzone do ARMv6KZ i późniejszych architektur. Wprowadza ono nisko kosztową alternatywę do dodawania dodatkowego dedykowanego rdzenia do SoC (Systemon-a-chip). Było to możliwe dzięki wprowadzeniu dwóch procesorów wirtualnych obsługiwanych przez sprzętowa kontrolę bazową. To pozwala przełączać się aplikacjom niskopoziomowym do przełączania się pomiędzy dwoma stanami, w odniesieniu do świata (by zredukować zamieszanie z innymi możliwymi nazwami domen) w sposób jakie informacja może być chroniona przed przeciekiem z bardziej zaufanego świata do mniej zaufanego świata. To przełączanie przestrzeni jest ogólnie niezależne od wszystkich innych możliwości procesora, więc każdy świat może działać niezależnie od drugiego używając tego samego rdzenia. Pamięć i peryferia są poinformowane o operującym na rdzeniu świecie i może użyć kontroli dostępu do ukrycia sekretów i kodu w urządzeniach. Typową aplikacją technologii TrustZone jest uruchomienie bogatego systemu operacyjnego w mało zaufanym świecie, i mało chronionego specjalizowanego kodu i bardziej zaufanym świecie. Rozwiązania bezpieczeństwa w oparciu o technologię TrustZone Trusted computing (zaufana informatyka) jest pojęciem, które budzi szerokie zainteresowanie w środowisku informatycznym. By zaprojektować łatwo chronione systemy wbudowane, zostało wprowadzone do ARMv6 rozszerzenia bezpieczeństwa. Rozszerzenie TrustZone jest zasadniczo proste. Zawiera w zasadzie jedną dodatkową instrukcję, nowy bit konfiguracyjny i dodatkowy poziom regulacji dostępu współdziałający z istniejącym użytkownikiem i trybami zabezpieczeń. TrustZone pozwala na uruchomienie małego fragmentu krytycznego kodu jako monitorowany proces w systemie czasu rzeczywistego i aplikacji. Kontekst ochrony może polegać na szyfrowaniu, deszyfrowaniu, autentykacji i dystrybucji certyfikacji i innych małych, ale decydujących zadań. Ponieważ procesory ARM są dedykowane dla smartphonów, komputerów ręcznych, palmtopów, telefonów komórkowych i innych systemów wbudowanych by zapobiegać szkodliwości złośliwych hakerów, którzy rzadko skupiają swoje zainteresowanie na --- 7 / 17 ---
komputerach innej klasy niż PC. Sieci bezprzewodowe i aktualizujące się programy otworzyło nowe możliwości dla intruzów. Do tej pory typowy system wbudowany miał mniejszą liczbę źródeł z której mógł zostać zaatakowany, inaczej niż w przypadku komputerów klasy PC. Mimo, że ARM uznaje definicję architektury TrustZone za ukończoną. Firma nadal pracuje z kluczowymi klientami, uniwersytetami, konsultantami nad udoskonaleniem i znalezieniem wrażliwych punków rozwiązania. ARM zamierza zaimplementować to rozwiązanie w najnowszej wersji rdzenia ARM11. Pierwsza krzemowa implementacja miała miejsce w końcówce roku 2004 i pojawiła się w produkcji w roku 2005. Tak jak już wcześniej pisano TrustZone stało się standardem procesora ARMv6. Rdzeń jako podstawa ochrony Kluczowym elementem TrustZone jest to, że rozszerzenie to jest na sztywno powiązane z rdzeniem mikroprocesora, a nie zaimplementowane w postaci jakiegoś firmwaru lub softwaru. Takie rozwiązanie jest bardzo ważne ponieważ pozwala osiągnąć wysoki stopień bezpieczeństwa bez użycia oprogramowania. Systemy operacyjne są w prosty sposób łamane, nawet jeśli zostały zaprojektowane do zadań związanych z bezpieczeństwem, większość jednak nie została w tym kierunku projektowana od początku. Niektórzy producenci systemów operacyjnych starają się by ich produkty były poprawiane przez zewnętrznych nadzorców. Wprowadza to jednak także kolejną okazję do popełnienia innych, nowych błędów. Znacznie lepszym rozwiązaniem jest w tym wypadku jest zaimplementowanie podstawowych rozwiązań bezpieczeństwa w logice procesora i zminimalizowanie liczby aplikacji, które muszą być chronione. Od dawna znaną prawdą jest, że im więcej drzwi i okien tym więcej możliwości na włamanie do środka. Dlatego tak dużą wagę przykłada się w ARMie do rozwiązania sprzętowego. Należy jednak zauważyć, że zaimplementowanie mechanizmów bezpieczeństwa w procesorze ma też swoje minusy. Przede wszystkim takie rozwiązanie jest mniej elastyczne niż zwykłe rozwiązanie programowe. Podejście sprzętowe zwiększa również rozmiar samego procesora. Z tych dwóch powodów ARM stara się by TrustZone pozostał tak zwarty jak to możliwe i niepotrzebnie się nie rozrastał. ARM wyposażony w TrustZone wymaga około 15K-20K bramek i zwiększa powierzchnię zwykłego ARM11 o blisko 5%. Jest to jednak do zaakceptowania przy zastosowaniach, które wymagają rozwiązań bezpieczeństwa. Z kolei dla produktów, które nie wymagają takich zabezpieczeń ARM na pewno będzie kontynuował linię procesorów bez TrustZone w ciągu najbliższej przyszłości. W zasadzie, TrustZone pracuje dzięki dodaniu specjalnego zabezpieczenia domeny, która uzupełnia istniejącego użytkownika i trybami zabezpieczeń. TrustZone jest jednak bardziej uprzywilejowany niż pozostałe tryby, w których jest uruchamiany ROTS (jest on z kolei bardziej uprzywilejowany niż tryb użytkownika, w którym są uruchamiane aplikacje). Zarówno uprzywilejowany kod jak i kod użytkownika może być uruchamiany w trybie chronionym TrustZone. W tym znaczeniu poziom zabezpieczeń procesora ARMv6 różni się od pierścieni dostępu znanych rodziny x86. TrustZone jest opisywany przez ARM jako równoległy poziom zabezpieczeń domeny, a nie jako nowa warstwa w stosie domen. Aby wejść do TrustZone, RTOS (Real-time Operating System) musi wywołać pojedynczą nową instrukcję TrustZone: secure monitor interrupt (SMI) monitorowane przerwanie chronione. Tylko RTOS uruchomiony w uprzywilejowanym trybie może wywoływać SMI. Takie ograniczenie ma za zadanie ochronę wielu możliwości przed wystąpieniem błędu, ponieważ procesor generuje wyjątek kodu maszynowego jeśli program --- 8 / 17 ---
uruchamiany w trybie użytkownika stara się wywołać SMI bezpośrednio. Tak więc program musi uzyskać pozwolenie by dostać się do TrustZone poprzez odwołanie do API od RTOS. Wywołanie funkcji API w RTOS daje możliwość sprawdzenia wszystkiego co konieczne by stwierdzić czy program nie chce wykonać jakiejś złośliwej operacji. Jednak stopień zabezpieczenia który jest wprowadzany zależy od tego co dobrowolnie wprowadzi sprzedawca. Minimalnym stopniem jest dodanie ochrony instrukcji SMI. Bit bezpieczeństwa Wcześniejszy rozdział opisywał możliwości, które przyniosło wprowadzenie TrustZone. W tym rozdziale postaram się zastanowić co dzieje się podczas wywołania instrukcji SMI. Kiedy wykonywana jest instrukcja SMI, procesor zostaje przełączony domenę TrustZone, tryb ten jest także zwany monitorowanym trybem chronionym. Aby przełączyć się w nowy tryb ustawiany jest bit bezpieczeństwa, nazywany S-bit, w koprocesorze o numerze 15 (CP15). Jest to rejestr stanu bezpieczeństwa, który znajduje się w ścisłej części pamięci systemu. Rejestr CP15 jest stałym elementem programowanie ARM, ponieważ zawarte są w nim bity konfiguracyjne wielu najważniejszych funkcji rdzenia. Monitory bezpieczeństwa są małymi samodzielnymi, wielowątkowymi programami, które są kompletnie niezależne od regularnego RTOS. Konieczne jest także chronione jądro systemu operacyjnego i chronione sterowniki urządzeń. Jest to wymagane do przełączania kontekstu pomiędzy stanem chronionym i niechronionym. ARM zapewnia odwołanie do kodu z poziomu monitora chronionego, ale jest nadal ustalane jak dostarczyć zabezpieczone jądro i sterowniki. Wymagane jest by jądro zależało od aplikacji, w minimalny zakresie musi ono być zdolne do zarządzania pamięcią w sposób chroniony, ale musi również duplikować wiele tak wiele funkcji RTOS jak to możliwe. Integralność systemu jest osiągnięta poprzez ochronę jądra i konserwację źródeł i ułatwienie zadanie deweloperom poprzez formalny opis. Ciekawą sprawą jest, e monitor i ochrona monitora to nie setki kilo bajtów a jedynie dziesiątki. Podczas ustawienia S-bitu cały czas monitor bezpieczeństwa nadzoruje operacje wykonywane przez procesor. Najpierw zachowywany jest stan wykonywanego w danym momencie procesu zanim kontekst zostanie przełączony na nowy proces chroniony. Monitor jest zobowiązany do przechowania zawartości rejestru dla procesu niechronionego. W dodatkowych bankach rejestrów CP15 monitor zapisuje również konfigurację procesów niechronionych. Zliczając wszystko można stwierdzić, że TrustZone dodaje 350 bitów informacji o stanie procesora i około 200 cyklów zegara do przełączenia kontekstu, przełączenie kontekstu może być również szybsze gdyby stan chroniony używał jedynie podzbioru z rejestrów procesora. Trzeba również wziąć pod uwagę, że odpowiedzialność monitora za zapis odtworzenie stanów kiedy następuje przełączania pomiędzy trybem chronionym i niechronionym nie wymaga by dodać jakikolwiek kod do RTOS. RTOS przejmuje uchwyt kontekstu tylko w wypadku procesów niechronionych. Monitor ochronny nie musi koniecznie czyścić cachu instrukcji, cachu na dane, TCM, lub innej pamięci przy przełączaniu kontekstu, ponieważ TrustZone dzieli strukturę na chronioną i niechronione części. Cache, jednostka zarządzania pamięcią (MMU) i bufor translacji posiadają dodatkowe bity (znaczniki S-bit) by trzymać kontrolę nad tymi częściami. Tylko procesy chronione mają dostęp do części chronionej pamięci lub linii cache. Podobnie jak wcześniej, wszelkie próby dostępu przez niechronione procesy do restrykcyjnej linii cache lub pamięci, generuje błąd cachu i zewnętrzny błąd. --- 9 / 17 ---
Także chronione partycjonowanie tworzy części cachów bez limitów dla niechronionych procesów, obecnie chronione linie cachu nie są blokowanie, jeśli programista nie zainteresuje się tym i ich nie zablokuje. Nowe dane z procesów chronionych i nie chronionych mają zdolność do wyrzucenia danych z chronionych linii cachu pod pozorem normalnej pracy, która jest wykonywana w czasie działania cache. Strony pamięci nie są organizowane podobnie jak cache w linie. System, który używa TrustZone musi posiadać oddzielne dedykowane TCM (Tightly Coupled Memory) dla danych chronionych i tych, które ochrony nie posiadają. Architektura procesora ARMv6 posiadała do 4 TCM i deweloperzy mogli dzielić jeden fizycznie spójny blok pamięci SRAM na kilka logicznych TCM. Ciekawą sprawą jest że te partycje mogą dynamicznie zmieniać swój rozmiar podczas działania, co może nieść ze sobą pewne niepożądane skutki, takie jak dynamiczne alokowanie pamięci jakiś źródeł pamięci, które są wymagane przez inny proces. ARM posiada chroniony monitor strony pamięci które są wewnątrz chronionego TCM. Tym sposobem, częściowo dzięki własnej ochronie i częściowo dzięki działaniu monitora utajnienie odpowiednich informacji zostało osiągnięte. TrustZone jest w stanie tylne drzwi nagminnie wykorzystywane przez złośliwe programy dzięki utrzymywaniu rozdzielonych partycji w cachu i pamięci i ściśle przestrzegając dostępu do tych partycji. Program, do którego nie można mieć zaufania nie potrafi wykonać swoich własnych instrukcji lub kontrolować rozmiar danych w systemie lub niszczyć wyników działania przetwarzania danych. Ochrona przerwań Kolejnym wyzwaniem, które stanęło przed technologią TrustZone i musiało zostać rozwiązane jest przejmowanie przerwań mogących zostać wywołane przez złośliwe programy. Przerwanie może zostać wykorzystane podstępnie do zmiany kierunku wykonania fałszywego przerwania i udaremnienie chronionego procesu. Jedno z rozwiązań jest bardzo proste. Polega ono na blokowaniu wszystkich przerwań kiedy procesor jest w trybie chronionym. Takie rozwiązanie może być zastosowane w systemie, który nie musi odpowiadać w czasie rzeczywistym na zdarzenia lub nie przeprowadza czasochłonnych procedur objętych ochroną. Jest to rozwiązanie całkowicie niedopuszczalne w systemach ściśle przestrzegających rygoru czasu rzeczywistego. Miejscem, w którym można spotkać tego typu rozwiązania jest na pewno zakład przemysłowy. Konsorcjum ARM założyło, że większość systemów będzie potrzebowała czegoś więcej. Rozwiązaniem, które zastosowano jest tablica wektorów przerwań dla trybów chronionych i niechronionych. Każdy z trybów ma jednak w tym wypadku własną politykę. Chroniona tablica wektorów jest przechowywana w chronionej pamięci i jest punktem odniesienia dla przerwań wywoływanych w trybie chronionym. Z kolei tablica wektorów niechronionych jest przechowywane analogicznie w niechronionym obszarze pamięci. Takie rozwiązanie może doprowadzić do duplikacji wielu uchwytów przerwań i pewnej redundancji w systemie, ale jest też w stanie zapobiec by złośliwe oprogramowania nadpisało chronioną tablice wektorów. Można by pójść dalej i rozszerzyć ochronę na wszystkie przerwania, ale to wymagało by przełączania systemu w tryb chroniony przy wywołaniu każdego z przerwań, co jak napisano wcześniej ma swoje koszty. Dobra ochrona, lecz kiepska wydajność nie jest rozwiązaniem najlepszym. Przerwania, które nie muszą być chronione także mogą odnieść korzyść z istnienia TrustZone. Dla przykładu wiele systemów wbudowanych używa przerwań dla regularnego resetowania timera w watchdogu. Gdyby timer przestał być resetowany i odmierzył czas do --- 10 / 17 ---
zera to nastąpiłby restart systemu. Pozwala to systemowi automatycznie rozwiązać problem i wyrwać system w sytuacji gdzie program zwiesił się bez możliwości dalszego działania. Złośliwe oprogramowanie może to wykorzystać na swój sposób. Maskując przerwanie czasowe może doprowadzić do ciągłego restartowania urządzenia, ataku typu Denial-ofservice lub otworzyć możliwość do instalacji złośliwych sterowników lub programów, a nawet całego nowego RTOS. Z drugiej strony, złośliwy program może postąpić zupełnie odwrotnie, wyłączając przerwanie czasowe spowoduje uniemożliwienie restartu i naprawienie błędu systemowego. W celu udaremnienia tego typu ataków, TrustZone może zatrzymać maskowanie w systemie przerwań o wysokim priorytecie w czasie uruchamiania niechronionego kodu. Architektura procesora ARMv6 udostępnia dwa rodzaje przerwań. Przerwania regularne (IRQ) (zwykłe) i przerwania o wysokim priorytecie szybkie przerwania (FIQ). Przerwania IRQ zawsze wykonują skok do instrukcji rozgałęziającej w tablicy wektorów przerwań. Powoduje to opóźnienie kiedy wywoływany jest uchwyt przerwania. Wektor FIQ jest zawsze ostatnią pozycją w tablicy wektorów, który jest aktualnym punktem dla uchwytu przerwania. Eliminuje to konieczność wykonania rozgałęzienia. FIQ posiada wyższy priorytet niż IRQ dlatego jest ważne by były niemaskowane w niechronionych procesach. Przy użyciu TrustZone FIQ może przełączyć system w tryb chroniony, skąd monitor może wykonać skok do tablicy wektorów chronionych i uchwytów przerwań. Po zakończeniu zadania wykonywanego w trybie chronionym, niezależnie czy było to przerwanie czy też część aplikacji, TrustZone wykonuje wcześniej opisaną instrukcję SMI ponownie by wyczyścić S-bit i rejestrze statusu CP15. Monitor odnawia także pozostałe rejestry do stanu sprzed przełączenia kontekstu, a następnie ponownie przełącza procesor w tryb niechroniony. Wszystkie instrukcje i dane przechowywane w chronionych partycjach w cachu, TCM i pamięci pozostają nie rozdzielone. TrustZone może również zapobiec spontanicznym restartom i zainfekowaniu systemu kodem usypiającym urządzenia do czasu następnego regularnego uruchomienia. Deweloperzy maja możliwość konfiguracji by uruchomić system od razu w uprzywilejowanym trybie chronionym i sprawdzić czy nie ma jakiś intruzów przed załadowaniem właściwego RTOS. Poprzez sprawdzenie autentyczności kodu w czasie uruchomienia system może ustawić się w bezpiecznym stanie. --- 11 / 17 ---
Tworzenie kompletnego pancerza TrustZone pozostałby prawdopodobnie nieefektywnym narzędziem, gdyby pozostała cześć systemu była niezdatna do użytku. Ten sam S-bit, który jest w MMU i TLB, reguluje dostęp do chronionych partycji TCM, może być także barierą dla dostępu do pamięci RAM, ROM i flash. Deweloperzy mają możliwość konfiguracji peryferiów w taki sposób by sprawdzały S-bit zanim podejmą działania mające na celu wykonanie krytycznych operacji. S-bit pojawia się w magistrali AMBA, która łączy wbudowane peryferia, kontrolerze DMA, interfejsach I/O, koprocesorach, i logicznych blokach rdzenia procesora. Dodatkowa modyfikacja tych urządzeń zapewni, że stan S-bitu będzie chronił w dostęp do wszystkich transakcji. Rysunek pokazuje w jaki sposób TrustZone przeprowadza ogólno systemową ochronę systemu. Wirtualnie każdy komponent wbudowanego systemu sprzętowy i programowy może korzystać z zalet TrustZone w ten sam sposób, ponieważ rozszerzenie jest nieodłączną częścią architektury ARMv6. Żaden inny mikroprocesor nie zapewnia podobnej ochrony na poziomie architektury. Istnieje możliwość dodać podobne rozszerzenie do konfigurowalnych procesorów produkowanych na licencji ARC International, MIPS Technologies oraz Tensilica lub inne mające możliwość dodania rozszerzeń pracujących prawidłowo ponad TrustZone. Dla przykładu ARC posiada instrukcję rozszerzającą dla procesora ARCtangent-A5, która powoduje przyśpieszenie każdego protokołu korzystającego z kodowania DES lub 3DES. Są to dla przykładu protokoły takie jak IPSec (Internet Protocol Seciurity), SSL (Secure Sockets Layer), TLS (Transport Layer Security), and kodowane PPP (Point-to-Point Protocol). Dodatkowo ARC wypuścił ostatnio na światło dzienne dwie nowe paczki bezpieczeństwa, które są znane po nazwami IPShield i ARCprotect. IPShield służy do dodania do ARC licencjonowanego stosu TCP/IP dla procesorów RCtangent-A5, ARM, MIPS, ColdFire, and Power-PC. ARCprotect używa rozszerzenia DES i mnóstwa innych instrukcji do przyśpieszenia IPShield na procesorze ARCtangent-A5. Zazwyczaj zamówione rozszerzenia są unikalne dla licencji, w której zostały udokumentowane. Nie są w tym względzie dostępne ogólnie dla wszystkich licencji jako część rdzenia danej architektury. Z punktu widzenia zasad bezpieczeństwa rozszerzenia mają zarówno wady jak i zalety. Zaletą jest bez wątpienia fakt, że zamówione rozszerzenia mogą oferować większą skuteczność ochrony niż TrustZone zbudowany przez ARM jeśli projekt nie jest nigdzie opisany. Łamanie zamówionych instrukcji jest również niemożliwe, ponieważ są one ukryte w sprzętowej logice. Deasemblacja nie wnosi niczego nowego poza ujawnieniem kodu maszynowego i oficjalnie uzyskuje się w ten sposób kod niemożliwy do identyfikacji. Wadą implementacji zasad bezpieczeństwa poprzez dodawanie własnych rozszerzeń jest to że wymaga do poświęcenia znacznie większej ilości pracy na sam projekt, a konieczne jest by uczynić to rozszerzenie wpierającym narzędzia i oprogramowanie tworzone przez niezależne firmy. Jedyną droga, którą można obejść tą wadę jest stworzenie dla danego konfigurowalnego procesora takie rozszerzenia, które będzie rozprowadzane i licencjonowane dla klientów, którzy dany procesor zakupią. Jako przykład można przytoczyć rozszerzenie firmy ARC do protokołu DES, które nie jest częścią architektury ARCtangent, ale ARC uczynił je dostępnym dla wszystkich licencji ARCtangent-A5. Rozszerzenia bezpieczeństwa takie jak TrustZone, które nie przyśpieszają konkretnego algorytmu lub protokołu mogą kosztować pewną utratę wydajności. Każdy podprogram, uchwyt przerwania, dostęp do pamięci lub wymiana informacji z urządzeniem I/O, które wymagają ochrony musi wykonać przełączenie w tryb chroniony lub sprawdzić S-bit. Ostatnia czynność jest jak opisywano wykonywana by sprawdzić czy procesor nadal pracuje --- 12 / 17 ---
w chronionym trybie. Jeśli ochrona zostanie doprowadzona do granic możliwości, także wszystko co działa ponad nią będzie działać na granicy możliwości. Deweloperzy muszą się ściśle kierować rozsądkiem by ocenić, która część tworzonego systemu potrzebuje danego poziomu zabezpieczeń. Kolejnym powodem dla, którego nie warto tonąć razem z technologią TrustZone jest fakt, że weryfikacja bezpieczeństwa systemu rośnie gwałtownie razem ze stopniem skomplikowania kodu oprogramowania. Teoretycznie wywołanie RTOS i uruchomienie aplikacji powinno też uruchomić tryb chroniony w TrustZone. Praktyka pokazuje jednak, że znalezienie i zamknięcie wszystkich potencjalnych pętli nieskończonych jest zadaniem z gatunku tych niewykonalnych. ARM zachęca konstruktorów by chronić tylko ich najważniejszy kod i inne rozwiązanie tej kwestii nie zostało podane. Systemu używające technologii TrustZone potrzebują więcej pamięci wbudowanej dla monitora chroniącego, ochrony jądra, i informacji stanu przechowywanych podczas przełączania ochrony. Dodatkowe 15K-20K bramek logicznych jest również wymaganie, które stawia przed światem technologia TrustZone. Pamiętać należy, że dodatkowa pamięć musi uczynić chip trochę większy i zużyje z pewnością więcej energii. Nie ma jeszcze odpowiednich danych by skalkulować wszystkie efekty straconej energii i miejsca, ale można przypuszczać, ze ten przyrost będzie mniejszy niż 10%. Jest to relatywnie dość niska cena jaką trzeba ponieść za bezpieczny system. Każda inna technologia ochrony zaimplementowana na wyższym poziomie abstrakcji niż architektura procesora będzie prawdopodobnie potrzebować znacznie więcej pamięci i zużyje więcej energii na dodatkowe przetwarzanie. Można być też pewnym, że wyższy poziom abstrakcji poniesie ze sobą też koszty znacznie mniejszej wydajności. Oczywiście żaden system nigdy nie będzie stuprocentowo odporny na atak. W świecie informatyki jak wiadomo, projektanci są cały czas tylko o krok przed przestępcami. Dlatego też ARM jako poważne konsorcjum jest bardzo ostrożne z rozdawaniem wszelkich gwarancji na niezawodność ich rozwiązania. TrustZone nie jest w pełni bezpiecznym systemem. Należy pamiętać, że jest to tylko architektura, która umożliwia ułatwienie deweloperom zbudowanie ich własnego bezpiecznego systemu. Patrząc z takiej perspektywy, TrustZone można uznać za żadne rozwiązanie, ponieważ wymaga jeszcze wiele pracy od samego projektanta urządzenia. Wiele deweloperów ARMa prawdopodobnie zignoruje tą technologię. Są jednak tacy, którzy będą mieli za zadanie zaprojektować bezpieczny system i ten procent będzie się zwiększał TrustZone dał deweloperom prosty fundament, którego żadne rozwiązania wysokiego poziomu nie są w stanie powielić. Projektowanie systemu TrustZone Kontrola bezpieczeństwa TrustZone jest gotowa do użycia jako zestaw peryferyjnych bloków funkcyjnych podłączonych do magistrali komponentów i peryferiów regulujących dostęp. Wszystko zostało dostarczone przez ARMa. Bardzo rzadko jest konieczność zmodyfikowania jakiejś istniejącej części systemu części systemu by mogła ona działać w TrustZone. TrustZone Protection Controller (TZPC) System o wysokiej elastyczności i konfigurowalności może zostać stworzony przez użycie TZPC (ARM PrimeCell BP147). Jest to peryferyjny kontroler programowy obsługujący AMBA APB. Determinuje ona, który inne peryferia zostaną dopuszczone do chronionego dostępu, a które peryferia dostaną jedynie możliwość dostępu do niechronionych zasobów. TZP potrafi także wyliczyć programowalną wartości wielkości obszaru używanej przez TrustZone Internal Memory Wrapper by kontrolować dostęp do chronionej pamięci. Rejestry TZPC muszą być zamapowane w pamięci w chronionej przestrzeni, jest to konfigurowalne jedynie w momencie startu systemu. --- 13 / 17 ---
Configurable Interconnect Wewnętrzna komunikacja pomiędzy komponentami systemu jest składnikiem decydującym w kwestii jego bezpieczeństwa. Komunikacja ta musi wspierać chronione tranzakcje wymiany danych. AMBA AXI Configurable Interconnect PrimeCell (PL300) jest dostarczoną przez ARMa zautomatyzowaną magistralą do połączenia w systemie komponentów typu master i slave. Wszystkie połączenia master/slave przechodzą przez nadzór Configurable Interconnect, który zajmuje się każdą tranzakcją i odrzuca te w wypadku, których jest przypuszczenie, że są niedopuszczalne z punktu widzenia TrustZone (całość kontrolowana jest z poziomu TZPC). TrustZone On-Chip Memory W TrustZone jest sprawą pożądaną by system posiadał pamięć wbudowaną umiejscowioną w zamapowanej chronionej przestrzeni adresowej dla chronionych danych lub kodu. Bloki pamięci SRAM nie dostarczają zwykle żadnego wsparcia dla rozwiązań kontroli. Tak więc RM TrustZone Internal Memory Wrapper PrimeCell (BP141) sam musi zadbać o otoczenie pamięci blokami chronionymi. Aby włączyć pojedynczy blok pamięci fizycznej do wymiany danych pomiędzy zapisem chronionym i niechronionym, Internal Memory Wrapper pobiera konfigurację wejść z TrustZone Protection Controller i magistrali AMBA AXI aby osądzić legalność zgłoszeń i blokować niedopuszczalną wymianę danych w chronionej przestrzeni adresowej. AXI2APB Bridge Dal peryferiów używających protokołu AMBA APB the AXI2APB Bridge PrimeCell (BP135) utworzył łatwe połączenie protokołów magistrali AMBA APB i AMBA AXI. To przejście pobiera sygnały kontrolne z TrustZone Protection Controller i wydaje decyzję czy dane urządzenie peryferyjne może uzyskać dostęp do chronionej tranzakcji. Rodzaje przerwań Kontrola przerwań musi być ściśle chroniona, aby żadne złośliwe oprogramowanie nie miało dostępu do kontroli nad nimi i tym samy przejąć kontrolę nad systemem. ARM1176JZ(F)-S nadal posiada jedynie dwa zwykłe przerwania wejściowe. Są to nfiq i nirq. W systemie TrustZone mamy jednak dostępny tryb Monitor, który może być używany do filtrowania przerwań przed ulokowaniem ich w chronionym i niechronionym świecie. Najprostsza konfiguracja to użycie nfiq jako przerwania chronionego, wywoływanego bezpośrednio w trybie Monitora Ochrony. nirq jest wykorzystywane jako przerwanie niechronione. --- 14 / 17 ---
TrustZone Secure Interrupt Controller (TZIC) tworzy chronione przerwania nfiq z surowych źródeł przerwań i przypasowuje je jako nfiq w procesorze. Zatrzymuje także źródła, które wybrały nfiq z kontrolera przerwań niechronionych. Dzięki temu chronione przerwania nie mogą być kontrolowane lub widoczne z przestrzeni niechronionej. Chronione przerwania są przestawiane w tryb niechronione w przypadku gdy procesor znajduje się w stanie niechronionym. Non-Secure Interrupt Controller Kontroler przerwań niechronionych może zostać łatwo zaprojektowany w podobny sposób jak ARM s PL192 Vectored Interrupt Controller PrimeCell (PL192). Kontroler przerwań niechronionych jest używany do tworzenie jak można się domyślić przerwań niechronionych nirq z źródeł przerwań, które zostały dopuszczone do wykonania przez TZ-IC. Ochrona podczas debuggowania Dostęp debugera w ARM1176JZ(F)-S jest nadal osiągany przez rejestr CP15 tak jak zwykle, tym razem jest to jednak chroniona wersja. Istnieją dwa dodatkowe rozszerzenia, kór mają za zadanie podnieść ochronię debuggowania: Nowe piny, które wyłączają dostęp do rejestru CP15 kiedy on jest w chronionym trybie dostępu. Nowy rejestr, Secure Debug Enable Register, który zawiera dwa nieinwazyjne bity kontrolne by umożliwić proces debuggowania, zawiera też liczniki i próbkowanie PC. --- 15 / 17 ---
Te dwa nowe rozwiązania zostały włączone w istniejącą technologię debuggowania i do CoreSight. Nowa generacja ARMa ma zaszyty tryb debuggowania. Oprogramowanie TrustZone Aby uzupełnić dodatki bezpieczeństwa do procesora i części sprzętowej systemu, ARM przy współpracy z Trusted Logic dostarczył środowisko uruchomieniowe o wysokim stopniu bezpieczeństwa dal rdzeni TrustZone. To zabezpieczenie licencjonowane przez ARM stanowi kompletny framwork dla bezpiecznego zintegrowanego i testowanego oprogramowania zaprojektowanego dla środowisk o wysokich wymaganiach bezpieczeństwa. Zalety stosowania oprogramowania ARM TrustZone Koszt, czas i kompletność zawarta w chronionym systemie jest znacząca. ARM zadbał o konieczne kroki do pozyskania wszystkich koniecznych bloków by pomóc swoim partnerom do wykorzystania w sposób pełno wymiarowy i pełnowartościowy frameworku chronionego dostarczanego przez TrustZone. Oprogramowanie to jest w pełni przygotowane do kompletnej pracy z procesorem ARM1176JZ(F)-S Oprogramowanie i sprzęt razem pracują w odpowiedni sposób by zaimplementować optymalne rozwiązanie bezpieczeństwa dla dzisiejszych czasów. --- 16 / 17 ---
Oprogramowanie ARM TrustZone zawiera następujące komponenty: Chronione Jądro Natywne serwisy: zakres serwisów kryptograficznych, integrujących sprawdzanie i ochronę danych Trusted Interpreter zbudowane w oparciu o STIP TrustZone APIs I sterowniki urządzeń Bootloader Oprogramowanie monitora TrustZone Literatura: ARM Limited Wikipeda EN - http://en.wikipedia.org/wiki/arm_limited Arm architecture Wikipedia EN - http://en.wikipedia.org/wiki/arm_architecture TrustZone Technology Overview - http://www.arm.com/products/esd/trustzone_home.html Arm Glossary - http://www.arm-development.com/arm_glossary ARM TrustZone and Discretix CryptoCell Technologies Combined to Create Next- Generation Security for Mobile Content - http://www.arm.com/news/15624.html msystems And ARM Collaborate To Offer An Enhanced TrustZone Security Solution - http://www.arm.com/news/14876.html ARM Announces RealView System Generator: Fast Virtual Prototypes For Real- Time System Interaction - http://www.arm.com/news/14065.html Secure Processor Core Technology - http://www.arm.com/news/14065.html TrustZone System Design - http://www.arm.com/products/esd/trustzone_systemdesign.html TrustZone Software - http://www.arm.com/products/esd/trustzone_software.html TrustZone API Overview - http://www.arm.com/products/esd/trustzone_apioverview.html ARM* Security, Solutions and Intel, Authenticated Flash - How to integrate Intel Authenticated Flash with ARM TrustZone* for maximum system protection. - http://www.arm.com/pdfs/intel_arm_security_whitepaper.pdf TrustZone: Integrated Hardware and Software Security - http://www.arm.com/pdfs/tz_whitepaper.pdf Security in Mobile Terminals - http://www.arm.com/miscpdfs/4509.pdf ARM DONS ARMOR - TrustZone Security Extensions Strengthen ARMv6 Architecture - Tom R.Halfhill --- 17 / 17 ---