Ondersteuning voor zelfwijzigende code in een ARM hypervisor

Transcriptie

1 Ondersteuning voor zelfwijzigende code in een ARM hypervisor Peter Van Bouwel Promotoren: prof. dr. ir. Bjorn De Sutter, prof. dr. ir. Koen De Bosschere Begeleiders: ir. Niels Penneman, dr. Jonas Maebe Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen en Architectuur Academiejaar

2 Voorwoord Wanneer je om je heen kijkt, zie je het gebeuren. De smartphones en tablets nemen de wereld over. De eerste smartphones met dualcores duiken zelfs al op. Toen ik het onderwerp voor mijn masterproef moest kiezen, sprak deze mobiele wereld me al zeer sterk aan. Ik wilde dan ook meehelpen aan een product voor deze mobiele wereld en ik ben blij dat ik dat heb kunnen doen. Ik zou dan ook iedereen willen bedanken die op de een of andere manier een bijdrage heeft geleverd voor het mogelijk maken en het verwezenlijken van deze masterproef. Hierbij wil ik de volgende personen extra in de verf zetten: Mijn promotor prof. Bjorn De Sutter voor het aanbieden van de interessante thesis en voor de vele nuttige feedback op mijn werk. Mijn begeleider Niels Penneman ook voor de vele nuttige feedback en nog een keer extra omdat hij altijd klaar stond met antwoorden op mijn vragen. Farhadur, Panagiotis en Wim om samen met Niels een aangename werksfeer te creëeren. De personen van verdieping -3 uit het Technicum die zo vriendelijk waren om de deur voor mij los te maken wanneer deze nog op slot was. Mijn ouders voor de onnoemelijk vele dingen die zij voor mij doen. Een exhaustieve opsomming zou het aantal pagina s van deze masterproeftekst verdubbelen. Mijn broers voor het veinzen van interesse wanneer ik (te) enthousiast over computerzaken begin te praten. Mijn vrienden en vriendinnen om mij af en toe vanachter mijn computer weg te halen. Bedankt! Peter Van Bouwel 6 juni 2011 i

3 Toelating tot bruikleen De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef. Peter Van Bouwel 6 juni 2011 ii

4 Ondersteuning voor zelfwijzigende code in een ARM hypervisor door Peter Van Bouwel Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar Universiteit Gent Faculteit Ingenieurswetenschappen en Architectuur Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Promotoren: prof. dr. ir. Bjorn De Sutter, prof. dr. ir. Koen De Bosschere Begeleiders: ir. Niels Penneman, dr. Jonas Maebe Samenvatting Deze masterproef onderzoekt de mogelijkheid om een hypervisor voor de ARM-architectuur uit te breiden zodat deze overweg kan met integriteitscontroles en zelfwijzigende code. De hypervisor die als startpunt dient, wordt eerst uitgebreid behandeld zodat het duidelijk wordt waarom deze aangepast moet worden. Hierbij wordt ook aandacht besteed aan de ARM-architectuur zodat de lezer de oorzaken van de problemen die optreden, te weten komt. Vervolgens wordt blokkopiefunctionaliteit voorgesteld als mogelijke oplossing om de hypervisor ondersteuning te geven voor integriteitscontroles en zelfwijzigende code. Er wordt toegelicht hoe dit gerealiseerd kan worden en wat de pijnpunten zijn. Vervolgens wordt er nagegaan of de oplossing inderdaad de problemen van de initiële hypervisor verhelpt. Tot slot worden de resultaten herhaald en worden er voorstellen gedaan voor toekomstig werk. Trefwoorden: virtualisatie, hypervisor, zelfwijzigende code, blokkopiefunctionaliteit iii

5 Adding support for self-modifying code in an ARM hypervisor Peter Van Bouwel Supervisor(s): prof. Bjorn De Sutter, prof. Koen De Bosschere, Niels Penneman, Jonas Maebe Abstract This article reports work that has been done to add support for integrity checks and self-modifying code to a hypervisor that is in development for the ARM architecture. The work will be summarized first, after which it gets evaluated. Keywords Virtualization, hypervisor, self-modifying code, block copy functionality TECHNOLOGICAL progress makes it possible to have more and more applications on one mobile device. There are so many applications on a single device that a user doesn t use them all at the same time. Therefore it is inefficient to provide dedicated hardware for each application. Sharing of hardware via virtualization makes it possible to solve this inefficiency but requires a good hypervisor to minimize security risks. Currently, a hypervisor for mobile devices that is free and that can be used without restrictions is non-existent. Therefore this Master s thesis aims to contribute to the realization of such a hypervisor. At Manchester University work has been started on a hypervisor for the ARM architecture with the aforementioned properties. Since that hypervisor lacks support for integrity checks and self-modifying code, support for those will be the main topic of this Master s thesis. I. TERMINOLOGY In this Master s thesis a sensitive instruction will have the same meaning as the one explained by Popek and Goldberg [2]. A sensitive instruction is an instruction that is either control sensitive or behavior sensitive. An instruction is control sensitive if it attempts to change the amount of memory resources available or if it affects the processor mode without going through the memory trap sequence. An instruction is behavior sensitive if the effect of its execution depends on its location in real memory or if the execution is affected by the execution mode of the machine. II. DYNAMIC BINARY TRANSLATION The initial hypervisor uses dynamic binary translation (DBT) to achieve full virtualization. It has to use DBT because in the ARM instruction set not all sensitive instructions trap when executed in user mode [1]. DBT will translate the instruction sequence so that no critical instruction will be executed in user mode. A critical instruction is an instruction that can compromise the correct execution of the virtualized software when executed on hardware. A critical instruction is either a control flow instruction or a sensitive instruction. A control flow instruction is critical because it can jump to code that is not yet translated. The initial hypervisor will replace the critical instruction with a SVC-instructions. This SVC-instruction is used as an hypercall and will give execution control to the hypervisor so it can emulate the critical instruction. As a result of the emulation of a critical instruction the hypervisor will know the address where execution should continue and can thus translate the instructions situated there before continuing execution. III. THE PROPOSED SOLUTION During the investigation of the original hypervisor it became clear that the DBT was to blame for the problems with integrity checks and self-modifying code. The DBT changes the critical instructions of the original code in place. Therefore the result of reading an original or translated critical instruction from code differs, resulting in erroneous behavior. To solve this problem changes were made to the original hypervisor to support block copy functionality. By using block copy functionality, the code is copied before DBT is performed. This way the original code is left untouched therefore reading of this code is always safe. Instead of executing the original code, a translated copy of the code is executed from a block copy cache. IV. BLOCK COPY CACHE To enable the creation of copies a new data structure was added to the hypervisor: the block copy cache. This structure is a FIFO cache for translated blocks of varying size. It will work together with the components of the original hypervisor to make translated copies of blocks of code available. V. PROGRAM COUNTER PROBLEMS The use of the block copy cache implies that execution is done from a different address in memory. Because the ARM architecture has an exposed program counter (PC) [3], almost any instruction can read the PC. Since a different PC will influence the result of an instruction the hypervisor has to protect the PC. During translation the hypervisor will check for each instruction if it reads the PC, and if necessary will rewrite the instruction such that it doesn t anymore. There are two approaches used to rewrite a PC dependent instruction. The first approach can only be used

6 if a dead register is available. The second approach is general applicable but will use memory accesses and is therefore slower. The first approach will search for a dead register and will reuse that register. As shown in figure 1, the MOVT and MOVW instruction will be used to place the value corresponding to the PC value of the original instruction in register R2. Due to the pipeline structure of the ARM processor and the instruction length, the PC will be increased by eight when it is read for the add operation, this is taken into account. Finally the ADD instruction has to be rewritten to make use of R2 instead of the PC. Original instruction Block copy cache sequence Adres2: MOVW R2,#Y Adres1: ADD R2,PC,R1 MOVT R2,#X B #20 ADD R2,R2,R1 Adres1 + 8 = X<<16+Y SVC Fig. 1. Translation of an ADD instruction when a dead register is available. When no dead registers are available, a register has to be made usable. This is done by backing up the contents of a register to memory, allowing the register to be used as is necessary. Afterwards the register can be restored from memory. Figure 2 shows an example. It is important that the backup and restoration procedure happens by the translated code and not during translation, because during translation the hypervisor cannot know what the value of the register should be. It is also the task of the hypervisor to reserve a word of memory that can be used for backing up and restoring the register. Original instruction sequence CMP R2,PC BEQ #20 X<<16+Y Block copy cache STR R1,[PC-#12] MOVW R1,Y MOVT R1,X CMP R2,R1 LDR R1,[PC-#28] SVC Reserved word Critical instructions don t need to be inspected to see if they read the PC. The emulation functions of all instructions are changed so that they use the appropriate value instead of the value of the PC at the SVCinstruction. For each instruction a function has to be provided that can inspect the instruction to see if it uses the PC. When it does, this function has to use one of the solutions mentioned above. Providing all these functions is too much work for a Master s thesis, therefore functions were only implemented upon encountering problems with the corresponding instruction. Although this results in an incomplete implementation, it allows to perform tests to see if the solution works conceptually. VI. EVALUATION To make sure that the proposed solution works, two handwritten assembly test cases were made. One is a simple integrity check and one test case relocates the code that has already been executed. First it was confirmed that the initial hypervisor couldn t pass the tests, then the tests were performed successfully on the hypervisor with block copy functionality which shows that the proposed solution is promising. There was also a test performed that made use of the same Linux kernel that was used for the development of the initial hypervisor. This test showed that when interrupts were enabled, the hypervisor with block copy functionality gets stuck in an infinite loop. Due to the absence of time further investigation couldn t be performed but further work should resolve this issue. Finally speed tests showed that the hypervisor needed approximately 4,33 times the time needed by the original hypervisor to execute the same code. This slowdown is due to the copying of the instructions and the extra overhead induced to make the instructions PC independent. VII. CONCLUSION The solution that is proposed in this Master s thesis looks very promising to solve issues with selfmodifying code and integrity checks but the implementation is not complete. Future work can be done on removing the faulty behavior when interrupts are enabled and on speedup of execution. REFERENCES [1] Danielius Kudinskas, Virtualizing the ARM - the ARM hypervisor, Masters thesis, University of Manchester School of Computer Science, April [2] Gerald J. Popek and Robert P. Goldberg, Formal requirements for virtualizable third generation architectures, Commun. ACM, 17:412421, July [3] Ryan W. Moore, José A. Baiocchi, Bruce R. Childers, Jack W. Davidson, and Jason D. Hiser Addressing the challenges of DBT for the ARM architecture, baiocchi/papers/lctes2009.pdf Fig. 2. Translation of a CMP instruction when no dead register is available.

7 Inhoudsopgave Voorwoord Toelating tot bruikleen Extended abstract Inhoudstafel Afkortingen i i iv vi viii 1 Inleiding Probleemstelling Doelstelling Overzicht Gerelateerd werk Virtualisatie Vereisten van een architectuur Soorten virtualisatie Realiseren van volledige virtualisatie Hypervisors van type 1 en type ARM De ARM-processors RISC Registers Processormodi Realiseren van volledige virtualisatie op ARM Zelfwijzigende code Initiële hypervisor Overzicht van de werking van de dynamische binaire vertaling Datastructuren voor dynamische binaire vertaling Detailstudie van de vertaalstappen Problemen met zelfwijzigende code Mogelijke oplossingen Besluit vi

8 2.4 DIOTA Besluit Blokkopiefunctionaliteit Aanpassing van de werking Blokkopiecache Structuur Vervangingsstrategie Cyclisch Initialisatie en gebruik Programmatellerafhankelijke code Detecteren of een instructie de programmateller leest Oplossen programmatellerafhankelijkheid met behulp van een dood register Oplossen programmatellerafhankelijkheid zonder een dood register Kritische instructies Randgedrag van vertaalde code Datastructuren Logboek Gastcontext Instructiecatalogus Status van de implementatie Uitvoering en onderzoek Besluit Evaluatie Validatie Testen met Linuxkernel Testen voor nieuwe functionaliteit Prestaties Besluit Besluit 52 6 Toekomstig werk 53 A ARM-instructies 54 B Conditiecodes 56 C Decoder 58 C.1 Programmatellerfhankelijkheden vii

9 Afkortingen Tabel 1: De gebruikte afkortingen. Afkorting Betekenis ARM advanced RISC machine ARM ARM ARM architecture reference manual B branch B byte C carry condition CISC complex instruction set computer CSAM code scanning and analysis manager CVE centrale verwerkingseenheid CPS change processor state DBT dynamic binary translation DIOTA dynamic instrumentation, optimization and transformation of applications DRM digital rights management FIFO first in, first out FIQ fast interrupt request GPL GNU General Public License GPS global positioning system IA-32 Intel architecture, 32-bit IRQ interrupt request JIT just in time KiB kibibyte LDR load register LRU least recently used MiB mebibyte MP3 MPEG-1 layer 3 MPEG moving picture experts group Vervolg op volgende pagina... viii

10 Tabel 1: De gebruikte afkortingen. (vervolg) Afkorting MSR N NOP PATM PC RAM RISC RSR STM STMDB SVC V VM Z Betekenis move to special register from register negative condition no operation patch manager program counter random-access memory reduced instruction set computer register-shifted register store multiple store multiple decrement before supervisor call overflow condition virtual machine zero condition ix

11 Hoofdstuk 1 Inleiding Door de technologische vooruitgang worden er steeds krachtigere en energiezuinigere processors geproduceerd. Dit zorgt ervoor dat de functionaliteit van mobiele toestellen steeds blijft toenemen. Tegenwoordig zijn producten als een mobiele telefoon, een MP3-speler, een zakagenda en een GPS niet langer individuele toestellen, maar kunnen ze allen aanwezig zijn op één toestel. Toestellen die één functie hebben, bezitten gespecialiseerde hardware om hun functie uit te voeren. Wanneer men echter deze gespecialiseerde hardware wil combineren in één toestel, kan men de hardware niet langer efficiënt benutten. Dit komt omdat er voor elke functie een rekeneenheid aanwezig is, die enkel gebruikt wordt voor de bijhorende functie. Om deze inefficiëntie weg te werken, wordt hardware gedeeld door verschillende toepassingen. Dankzij het delen van hardwarecomponenten kan het aantal hardwarecomponenten en dus de kostprijs van een toestel verminderd worden. Figuur 1.1 toont hoe virtualisatiesoftware het delen van hardware toelaat door het aanmaken van virtuele machines. De virtuele machines zijn virtuele kopieën van de hardware, die door verschillende toepassingen gebruikt kunnen worden. In plaats van elke toepassing zijn eigen hardware te geven, krijgt elke toepassing zijn eigen virtuele machine. Doordat de verschillende toepassingen gebruik maken van dezelfde hardware, zijn ze niet langer geïsoleerd van elkaar. Dit kan problemen met zich meebrengen voor geheimhouding en toegangsrechten. Zo is het soms wenselijk om software geheim te houden. Dit is bijvoorbeeld meestal het geval bij software voor digitaal rechtenbeheer (DRM). Verder willen de makers van de toestellen niet dat bepaalde applicaties toegang krijgen tot bepaalde hardware-onderdelen; sommige onderdelen kunnen schade teweegbrengen aan het toestel of aan de omgeving. Zo kan slecht batterijbeheer het toestel beschadigen. Bij ontploffing betekent dit gevaar voor de gebruiker. Fout gebruik van radio-onderdelen kan dan weer het netwerk storen. Een gebrek aan isolatie zorgt er ook voor dat het mobiele toestel gemakkelijker aan te vallen is. Een aanvaller heeft immers verschillende aanvalshoeken om uit te proberen. 1

12 Virtueel kopie 1 Virtueel kopie 2 Virtueel kopie 3 Virtualisatiesoftware Hardware Figuur 1.1: Virtualisatiesoftware laat het delen van hardware toe. Een beveiligingsprobleem in één van de onderdelen die gebruik maken van de gedeelde hardware, kan er immers voor zorgen dat deze hardware niet terug wordt vrijgegeven. Er kan ook informatie worden uitgelezen van andere softwarecomponenten die gebruik maken van deze hardware. Hierdoor zal dus het gehele toestel gecompromitteerd worden. Deze kwetsbaarheid voor aanvallen wordt overigens steeds kritischer aangezien mobiele toestellen steeds krachtiger worden. Niet enkel de rekenkracht van de centrale verwerkingseenheid (CVE) vermeerdert maar ook de hoeveelheid geheugen en opslagruimte nemen toe. Toestellen worden steeds meer gebruikt voor bedrijfsdoeleinden. Vertrouwelijke bedrijfsinformatie maakt dat de toestellen een interessanter doelwit worden voor malafide personen en organisaties. Virtualisatie stelt ons dus in staat om de hardware efficiënter te gebruiken maar levert problemen op met betrekking tot isolatie. Het is de taak van een hypervisor om deze problemen te bestrijden. Een hypervisor is een arbiter die virtuele machines aanmaakt en beheert. De hypervisor zorgt ervoor dat software die normaal gezien rechtstreeks op de hardware uitvoert niet langer de hardware rechtstreeks kan aansturen. In deze masterproeftekst wordt een niet nader genoemd besturingssysteem gebruikt als voorbeeld van software die rechtstreeks op hardware uitvoert. Het besturingssysteem voert uit maar in plaats van de hardware van toestand te laten veranderen, zorgt de hypervisor ervoor dat de virtuele machine die bij het besturingssysteem hoort van toestand verandert. De hypervisor maakt dus één virtuele machine aan per besturingssysteem. Hierbij heeft de hypervisor de mogelijkheid om per virtuele machine andere toegangsrechten toe te kennen. Wanneer een hypervisor correct functioneert, zal het voor een bepaalde softwarecomponent onmogelijk zijn om zonder toestemming het geheugen van een andere softwarecomponent te lezen of te manipuleren. Een hypervisor moet ook verhinderen dat één enkele softwarecomponent een onderdeel van de hardware (bv. de centrale verwerkingseenheid) opeist. Een hypervisor moet altijd meester blijven over de hardware. Een hypervisor die correct functioneert, garandeert een strikte isolatie. Hierdoor kan 2

13 hardware zonder problemen gedeeld worden. Virtualisatie is niet iets recent. Het wordt al jaren gebruikt om hardware op een efficiënte manier te delen. De technologie is bijvoorbeeld zeer populair in de serverwereld. Daar wil men meerdere webapplicaties draaien op een server, terwijl compromitatie van één van de applicaties geen gevolgen mag hebben voor de andere webapplicaties. Er bestaan dan ook tal van oplossingen voor servervirtualisatie. De serverwereld en mobiele wereld verschillen echter in sterke mate. Zo verschilt ten eerste de hardware uit beide werelden sterk van elkaar. In de serverwereld gelden er niet zo n sterke energiebeperkingen. De hardware van verscheidene servers bevat ook hardware-uitbreidingen om virtualisatie te versnellen [8, 12, 30]. Deze uitbreidingen zijn nog niet beschikbaar voor mobiele toestellen. Een serverhypervisor zal door de sterk verschillende architectuur van mobiele toestellen en servers niet zomaar op een mobiel toestel kunnen draaien. Een hypervisor verschilt ook van mobiele toestellen doordat er minder rekenkracht en energie voor handen is. De hypervisor moet altijd de software die bovenop hem draait controleren om er zeker van te zijn dat hij de controle van de hardware niet verliest. Hij is best zo energiezuinig en rekenefficiënt mogelijk omdat hij niet uitgeschakeld kan worden. De serverhypervisors zijn echter niet ontwikkeld met deze beperkingen. Er is daarom nood aan hypervisors die specifiek voor mobiele toestellen zijn ontworpen. 1.1 Probleemstelling Hoewel er nood is aan het delen van hardware door applicaties in mobiele toestellen, bestaat er geen gratis en vrije hypervisor die dit mogelijk maakt. Hiermee wordt bedoeld dat er geen licentiegelden betaald moeten worden om de hypervisor te gebruiken, maar ook dat men de code mag gebruiken zonder beperkingen. Een beperking kan zijn dat wanneer de software in een product wordt gebruikt, de broncode van dat product vrijgegeven moet worden. Er bestaat wel een project dat werkt aan een gratis en vrije hypervisor voor mobiele toestellen maar dit project is nog in ontwikkelfase. Één van de openstaande problemen is dat deze hypervisor niet overweg kan met zelfwijzigende code. Zelfwijzigende code wordt echter vaak gebruikt in checksums [11], JIT-compilatie [7, 20] en besturingssystemen [6]. 1.2 Doelstelling Deze masterproef heeft tot doel een bijdrage te leveren aan de ontwikkeling van een gratis en vrije hypervisor voor mobiele toestellen. Hiervoor wordt er een studie aangevat om de 3

14 problemen te identificeren. Omdat uit deze studie volgt dat de gebruikte hypervisor nog kan falen op integriteitscontroles en zelfwijzigende code, wordt er gezocht naar oplossingen hiervoor. Er wordt ook gekeken naar bestaande oplossingen voor gelijkaardige problemen om te zien of deze bruikbaar zijn voor deze masterproef. Een oplossing die interessant lijkt, is het kopiëren van code alvorens ze uit te voeren. Er worden aanpassingen voor de hypervisor voorgesteld en er wordt nagegaan of deze aanpassingen de problemen met zelfwijzigende code oplossen. Meer bepaald wordt er gekeken of checksums en relocaties correct gebeuren na de gemaakte aanpassingen. Om deze doelstelling te realiseren binnen de beperkte hoeveelheid tijd worden er enkele beperkingen opgelegd voor deze masterproef. Zo wordt dezelfde hardware-opstelling en hetzelfde gastbesturingssysteem gebruikt als in het project dat als uitgangspunt genomen werd. Ondersteuning van extra hardware en andere gastbesturingssystemen vallen buiten de scope van deze masterproef. Deze beperkingen zorgen ervoor dat de hypervisor enkel geschikt zal zijn voor de ARM-architectuur. Dit is geen probleem aangezien de mobiele markt wordt gedomineerd door de ARM-architectuur [3, 14]. 1.3 Overzicht Deze masterproeftekst bespreekt in hoofdstuk 2 gerelateerd werk. In hoofdstuk 2 komt ook de initiële hypervisor aan bod en wordt er al gekeken naar de openstaande problemen. Vervolgens beschrijft hoofdstuk 3 hoe de hypervisor aangepast wordt om deze problemen weg te werken. Hoofdstuk 4 evalueert de aanpassingen aan de hypervisor. Er zal nagegaan worden of de aanpassingen de problemen echt verhelpen maar ook of er geen nevenwerkingen zijn. In hoofdstuk 5 wordt er een besluit geformuleerd. De masterproeftekst zal eindigen met een hoofdstuk dat voorstellen doet voor toekomstig werk. 4

15 Hoofdstuk 2 Gerelateerd werk Dit hoofdstuk begint met de lezer informatie te geven over de virtualisatie die gebruikt wordt in deze masterproef. Hierbij wordt aandacht geschonken aan de redenen waarom er gebruik wordt gemaakt van een bepaalde vorm van virtualisatie. Vervolgens wordt de ARM-architectuur besproken en wordt er nagegaan wat de gevolgen zijn van deze architectuur voor het realiseren van virtualisatie. Daarna wordt de hypervisor besproken die het startpunt van deze masterproef vormt. Deze bespreking behandelt de openstaande problemen met betrekking tot integriteitscontroles en zelfwijzigende code en stelt een oplossing om deze problemen te verhelpen voor. Dit hoofdstuk eindigt met een toelichting van een dynamisch instrumentatieraamwerk dat ondersteuning biedt voor zelfwijzigende code. 2.1 Virtualisatie In mobiele toestellen wordt steeds meer hardware gedeeld (bv. het geheugen en de centrale verwerkingseenheid). Het delen van hardware kan gedaan worden door middel van systeemvirtualisatie [29]. Dit brengt echter beveiligingsproblemen met zich mee. Zo kan een slecht functionerende softwarecomponent een gedeeld hardware-onderdeel vasthouden, waardoor alle andere softwarecomponenten die afhankelijk zijn van deze hardware hun uitvoering niet kunnen voortzetten. Een kwaadwillige softwarecomponent kan door het delen van geheugen ook informatie van een andere softwarecomponent uitlezen, althans als er geen voorzorgsmaatregelen worden genomen. Wanneer virtualisatie wordt gebruikt, kan men ervoor zorgen dat de softwarecomponenten die moeten worden uitgevoerd geen rechtstreekse controle kunnen uitoefenen over de hardware. Omdat de softwarecomponenten die bovenop een hypervisor draaien meestal besturingssystemen zijn, wordt vanaf nu gastbesturingssysteem in plaats van softwarecomponent gebruikt. In plaats van de hardware rechtstreeks aan te spreken moet het gastbesturingsysteem communiceren met een hypervisor. Deze hypervisor is zelf een softwarecomponent. De hypervisor heeft echter een speciale functie; enkel hij mag de 5

16 hardware aansturen. Het is dan ook zijn taak om ervoor te zorgen dat gastbesturingssystemen geen controle kunnen krijgen over de hardware. Om deze taak te vervullen maakt de hypervisor virtuele machines aan. Deze virtuele machines zijn virtuele kopieën van de hardware en bevatten een hardwaretoestand. Per gastbesturingssysteem maakt de hypervisor een virtuele machine aan. Hiermee kan de hypervisor de hardwaretoestand voor de verschillende gastbesturingssystemen bijhouden. Telkens een gastbesturingssysteem de hardware wil aansturen, grijpt de hypervisor in. De hypervisor gaat vervolgens de toestand van de corresponderende virtuele machine aanpassen. Indien de echte hardware aangestuurd moet worden, zal dit gebeuren door de hypervisor. Daar de hypervisor de enige softwarecomponent is die de hardware kan aansturen, kan de hypervisor verhinderen dat een gastbesturingssysteem een geheugenlocatie leest of schrijft. Hierdoor kan een gastbesturingssysteem een ander gastbesturingssysteem niet beïnvloeden of observeren. Verder kan de hypervisor verzekeren dat hardware-onderdelen slechts worden aangestuurd door bevoegde gastbesturingssystemen. De hypervisor kan dus de problemen die voortkomen uit het delen van hardware vermijden Vereisten van een architectuur In een paper van Popek en Goldberg kan een voorwaarde gevonden worden die garandeert dat een architectuur efficiënt virtualiseerbaar is [23]. De voorwaarde dicteert dat een exceptie opgeworpen moet worden indien een gevoelige instructie die in bevoorrechte modus moet uitvoeren, uitgevoerd wordt in onbevoorrechte modus. Er zijn twee soorten gevoelige instructies: Controlegevoelige instructie Dit zijn instructies die proberen de beschikbare hoeveelheid geheugen aan te passen of die proberen de uitvoeringsmodus van de processor te beïnvloeden. Gedragsgevoelige instructie Bij deze instructies verschilt het gedrag bij uitvoering al naargelang de uitvoeringsmodus van de processor of de locatie in het fysiek geheugen. De voorwaarde van Popek en Goldberg is echter geen nodige voorwaarde voor virtualisatie zonder meer Soorten virtualisatie Systeemvirtualisatie kan gerealiseerd worden met behulp van verschillende technieken. Het is belangrijk om onderscheid te maken tussen volledige virtualisatie en paravirtualisatie [1, 27]. Bij volledige virtualisatie virtualiseert de hypervisor de hardware zo waarheidsgetrouw mogelijk. Hierbij is het de bedoeling dat de besturingssystemen, die uitgevoerd worden 6

17 door de hypervisor, niet te weten kunnen komen dat ze de hardware niet rechtstreeks aansturen. De hypervisor moet zich hiervoor tussen de hardware en de gastbesturingssystemen plaatsen om de aanstuurpogingen van de gastbesturingssystemen te onderscheppen. Dit zorgt voor veel overhead maar heeft als voordeel dat de besturingssystemen niet aangepast moeten worden. Het alternatief is paravirtualisatie. Bij paravirtualisatie biedt de hypervisor voor bepaalde operaties een interface aan naar het gastbesturingssysteem. Dit laatste heeft als voordeel dat deze operaties op een efficiëntere manier afgehandeld kunnen worden. Het brengt echter wel een groot onderhoudsprobleem met zich mee. Het gastbesturingssysteem moet zó aangepast worden dat het de interface herkent en gebruikt die door de hypervisor wordt aangeboden. Deze aanpassingen moeten dan telkens opnieuw gebeuren wanneer er een nieuwe versie van het besturingssysteem uitkomt. Figuur 2.1 toont het verschil tussen volledige virtualisatie en paravirtualisatie. Het belangrijkste verschil is dat er bij volledige virtualisatie geen aanpassingen aan het gastbesturingssysteem gebeurd zijn, daar waar er voor paravirtualisatie wel speciale interfaces in het gastbesturingssysteem beschikbaar worden gesteld. Programma x Programma y Programma z Programma w Ongewijzigd Besturingssysteem 1 Ongewijzigd Besturingssysteem 2 Gewijzigd Besturingssysteem 1 Gewijzigd Besturingssysteem 2 Hypervisor Hardware (a) Volledige virtualisatie Hypervisor Hardware (b) Paravirtualisatie Figuur 2.1: Het verschil tussen volledige virtualisatie en paravirtualisatie. Hoewel een hypervisor die volledige virtualisatie moet realiseren ingewikkelder is dan één die paravirtualisatie moet realiseren, is er gekozen voor volledige virtualisatie omdat het aanpassen van al de besturingssystemen en softwarecomponenten die bovenop de hypervisor gaan draaien, teveel onderhoud zou vragen Realiseren van volledige virtualisatie Wanneer de hypervisor op een naïeve manier tussen het besturingssysteem en de hardware geplaatst wordt, ontstaat er een probleem. Dit probleem is weergegeven in figuur 2.2(a). Het gastbesturingssysteem in de figuur voert zelf ook een applicatie uit. We zien dat het gastbesturingssysteem in bevoorrechte modus en de applicatie in normale modus uitvoeren. Dit betekent echter dat het besturingssysteem eender welke instructie kan 7

18 uitvoeren. De hypervisor kan hierdoor niet garanderen dat hijzelf meester blijft over de hardware. Om dit probleem op te lossen, moet het besturingssysteem geband worden van de bevoorrechte uitvoeringsmodus naar de normale uitvoeringsmodus. Deze situatie is afgebeeld in figuur 2.2(b) waar zowel besturingssysteem als applicaties in normale modus uitvoeren. Deze aanpassing zorgt er inderdaad voor dat de hypervisor zeker kan zijn dat hij altijd de controle over de hardware en software kan behouden. Programma x Ongewijzigd Besturingssysteem Hypervisor Hardware Normale uitvoeringsmodus Bevoorrechte uitvoeringsmodus Programma x Ongewijzigd Besturingssysteem Hypervisor Hardware Normale uitvoeringsmodus Bevoorrechte uitvoeringsmodus (a) Naïeve methode (b) Betere methode Figuur 2.2: Het bannen van het besturingssysteem naar normale uitvoeringsmodus. De nieuwe situatie zorgt echter wel voor een nieuw probleem. Het besturingssysteem dat geband is naar normale uitvoeringsmodus bevat immers gevoelige instructies die normaal gezien in bevoorrechte modus uitvoeren. Wanneer bevoorrechte instructies bij uitvoering in gebruikersmodus een exceptie opwerpen, zoals staat gedicteerd in de voorwaarde van Popek en Goldberg, is dit probleem eenvoudig op te lossen. De hypervisor kan dan de exceptie opvangen en het gedrag van de gevoelige instructie emuleren alsof ze in bevoorrechte modus werd uitgevoerd Hypervisors van type 1 en type 2 Een tweede indeling bij virtualisatie heeft betrekking op de hypervisor die de virtualisatie realiseert. Er wordt onderscheid gemaakt tussen hypervisors van type 1 en van type 2. Een hypervisor van type 1 wordt in de literatuur ook bare-metal hypervisor genoemd. Een hypervisor van type 2 daarentegen wordt hosted hypervisor genoemd. De verklaring voor deze namen wordt gevonden in figuur 2.3. Een hypervisor van type 1 moet zelf drivers bezitten om de hardware aan te sturen en is zelf verantwoordelijk voor het initializeren van de hardware. Een hypervisor van type 2 daarentegen kan gebruik maken van de voorzieningen die aangeboden worden door het besturingssysteem waarop hij draait. Zijn gastheer biedt immers bibliotheken en abstracties van hardware aan die gebruikt kunnen worden tijdens het ontwikkelen van de hypervisor. Hierdoor kan de ontwikkeling van de hypervisor veel sneller verlopen. Deze voordelen worden natuurlijk niet zomaar verkregen. De gastheer neemt kostbare 8

19 Programma x Programma x Ongewijzigd Besturingssysteem "Bare-metal" Hypervisor Hardware (a) Type 1 Ongewijzigd Besturingssysteem "Hosted" Hypervisor "Gastheer" Besturingssysteem Hardware (b) Type 2 Figuur 2.3: Verklaring van de naamgeving voor de verschillende typen van hypervisors. systeembronnen in en de instructies van de gevirtualiseerde besturingssystemen moeten door een extra laag gaan. Buiten de vertraging die hiermee gepaard gaat, leidt dit meestal ook tot een hoger energieverbruik [25]. Deze extra kosten kunnen aanvaardbaar zijn voor desktopsystemen. Voorbeelden van populaire type 2 virtualisatieproducten voor desktopsystemen zijn VMware Player [13] en Virtualbox [10]. Wanneer we echter een hypervisor voor mobiele toestellen willen, zijn deze extra kosten niet toelaatbaar. 2.2 ARM In de inleiding werd reeds aangehaald dat deze masterproef zich beperkt tot virtualisatie voor ARM-processors omdat deze de markt van mobiele toestellen domineren [3, 14]. Omdat de hardware die we moeten virtualiseren uiteraard implicaties heeft voor onze hypervisor, bevat deze sectie meer informatie over de ARM-processors. Vooreerst wordt er algemene informatie over de processors gegeven. Vervolgens komt de RISC-architectuur van de ARM-processor aan bod. Tenslotte worden enkele eigenschappen onder de loep genomen: de organisatie van de registers, de verschillende processormodi en de uitvoeringstoestanden De ARM-processors ARM-processors bestaan in verscheidene gedaanten; dit gaat van processors voor smartcards tot processors voor krachtige smartphones [17]. Zelf onderscheiden de ontwerpers de volgende categorieën: klassieke, ingebedde en applicatie-processors. De klassieke processors zijn diegene die reeds een tijd op de markt zijn. Het zijn ontwerpen die al vaak 9

20 verkocht zijn. De ingebedde processors zijn, zoals de naam aangeeft, voor gebruik in ingebedde systemen. Ze kunnen voornamelijk worden gebruikt als microcontroller (Cortex-M reeks) of als processor voor real-time-systemen (Cortex-R reeks). De applicatie-processors proberen meer functionaliteit en rekenkracht te leveren. Deze processors maken deel uit van de Cortex-A reeks. De Cortex-A reeks is bedoeld voor mobiele toestellen zoals smartphones en tablets en dus de hardware die we willen virtualiseren. De eigenschappen die van toepassing zijn op deze laatste categorie worden verder toegelicht RISC De ARM-architectuur is een RISC-architectuur. De standaard instructiesetarchitectuur voor een ARM-applicatieprocessor is de ARM-instructieset. De ARM-instructieset is een verzameling van instructies met vaste lengte, meer bepaald 32-bit instructies. Dit heeft als voordeel dat de instructiecodering eenvoudig kan zijn. Bij de ARM-instructieset komen de eerste vier bits van elke instructie overeen met een conditiecode. Deze code legt voorwaarden op die voldaan moeten zijn opdat de instructie wordt uitgevoerd (zie bijlage B). Naast de standaard 32-bit instructiesetarchitectuur ondersteunen de applicatieprocessors ook nog Thumb en Thumb-2. Dit zijn extra verzamelingen van instructies. In een register wordt bijgehouden welke verzameling instructies gebruikt wordt; dit is de uitvoeringstoestand. Thumb bevat 16-bit instructies zodat er een hogere codedichtheid bereikt kan worden. Omdat er slechts 16 bits voor handen zijn zullen er geen conditiecodes gebruikt worden. In plaats daarvan heeft Thumb een If Then -instructie die de 4 volgende instructies conditioneel kan laten uitvoeren. Thumb-2 heeft het voordeel van 32-bits te hebben voor instructiecodering maar streeft een hogere codedichtheid na dan de ARM-instructieset. Voor deze masterproef wordt er verondersteld dat gastbesturingssystemen enkel gebruik maken van de ARM-instructieset om de hoeveelheid werk te beperken. Er werd wel geen rekening gehouden met eigenschappen die specifiek zijn voor de ARM-instructieset omdat in de toekomst Thumb-ondersteuning wenselijk kan zijn Registers Er zijn 16 generieke 32-bit registers, R0 tot R15. De 3 registers met het hoogste rangnummer zijn speciale registers. R13 is een stapelwijzer, R14 wordt gebruikt als linkregister en R15 is de programmateller. Ondanks de speciale functies van deze 3 registers, zijn ze toch gewoon aanspreekbaar door de instructies. In de instructiecodering wordt gebruik gemaakt van 4 bits om het juiste register te selecteren. Behalve de 16 generieke registers zijn er ook nog andere registers die niet te benaderen zijn door eender welke instructie. Een voorbeeld van zo een register is het Current Program Status Register. Dit register houdt onder meer de huidige uitvoeringstoestand van de processor bij. De andere registers zijn niet relevant voor deze masterproef en worden hier dus niet behandeld. Het is wel nuttig om dieper in te gaan op het programmatellerregister. 10

21 In tegenstelling tot de meeste architecturen kan in de ARM-architectuur de programmateller gewoon uitgelezen en geschreven worden door instructies. Hierdoor moet er extra aandacht geschonken worden aan deze blootstelling van de programmateller [22]. Deze blootstelling zorgt er immers voor dat er veel code is die de programmateller uitleest. Verder kan bijna elke instructie het controleverloop beïnvloeden Processormodi Naast de verschillende uitvoeringstoestanden uit sectie 2.2.2, die bepalen uit wat voor instructies de instructiesequentie is opgebouwd, zijn er ook verschillende modi nodig waarin de processor instructies kan uitvoeren. Voor de ARM-processor die wij gebruiken zijn de volgende uitvoeringsmodi beschikbaar: User, System, Supervisor, Abort, Undefined, IRQ en FIQ. Voor deze masterproef is het belangrijk om weten dat de User - of gebruikersmodus de enige is die geen bevoorrechte instructies kan uitvoeren. Wanneer de hypervisor dus code van een gastbesturingssysteem laat uitvoeren, laat hij dit altijd in de gebruikersmodus doen. Telkens de controle wordt overhandigd aan de hypervisor door middel van een hypercall wordt de uitvoeringsmodus veranderd naar Supervisor. Dit zorgt ervoor dat de hypervisor de bevoorrechte instructies wel kan uitvoeren. De modi die bevoorrechte instructies kunnen uitvoeren, worden bevoorrecht genoemd. Met de gebruikersmodus en de bevoorrechte modus corresponderen de onbevoorrechte respectievelijk bevoorrechte instructies. Wanneer de processor een instructie moet verwerken, controleert hij voor de bevoorrechte instructies of zijn uitvoeringsmodus bevoorrecht is. Wanneer een ARM-processor een bevoorrechte instructie uit wil voeren in gebruikersmodus, kan deze instructie zich op 3 manieren gedragen [2]. NOP-gedrag De instructie gedraagt zich als een NOP. Onvoorspelbaar gedrag Er mogen geen veronderstellingen gemaakt worden over het gedrag van deze instructie. Niet gedefinieerd gedrag De instructie werpt een undefined instruction exceptie op. Er bestaat bijvoorbeeld een CPS-instructie die staat voor Change processor state. Deze instructie kan het Current Program Status Register aanpassen. Wanneer de instructie in normale modus wordt uitgevoerd, mag het echter de processortoestand niet aanpassen. Wanneer een instructie dit toch probeert in normale modus, is het resultaat een NOP. In bevoorrechte modus kan de instructie de vlaggen wel naar eender welke waarde veranderen. Hierdoor kan dezelfde instructie, al naargelang de verschillende modus waarin ze uitvoert, een ander resultaat teweeg brengen. De bevoorrechte instructies van de ARM-architectuur zijn gevoelige instructies. Aangezien in gebruikersmodus enkel die met niet gedefinieerd gedrag een exceptie opwerpen, 11

22 voldoet de ARM-architectuur niet aan de voorwaarden van Popek en Goldberg om efficiënt virtualiseerbaar te zijn [23]. De werkwijze uit sectie is dan ook niet bruikbaar voor de ARM-architectuur Realiseren van volledige virtualisatie op ARM Daar de gevoelige instructies van de ARM-architectuur niet altijd een exceptie opwerpen, mogen de gevoelige instructies van het gastbesturingssysteem niet zomaar worden uitgevoerd. Om dit probleem te verhelpen kan de hypervisor de instructies uit de instructiesequentie van het gastbesturingssysteem één voor één aflopen en het gedrag emuleren. Emulatie is traag en kan dus best zo weinig mogelijk gedaan worden. Daarom kan het interessant zijn om de instructiesequentie van het gastbesturingssysteem te vertalen. Bij vertaling worden de instructies van het besturingssysteem vertaald naar een veilige vorm. Hierdoor kunnen de vertaalde instructies wel op de hardware worden uitgevoerd. De vertaling zelf vraagt tijd maar het uitvoeren van reeds vertaalde instructies kan snel gebeuren waardoor vertaling interessanter is dan volledige interpretatie van de instructiesequentie [28]. Omdat een besturingssysteem dynamisch bibliotheken kan inladen en zelfwijzigende code kan bevatten is statische vertaling niet mogelijk [24]. Dynamische binaire vertaling kan wel gebruikt worden omdat het de instructies van het gastbesturingssysteem pas vertaalt net vooraleer ze uitgevoerd moeten worden. De vertaling van instructies wordt gedaan tot er één kritische instructie vertaald is. Een kritische instructie is een instructie waarvoor de hypervisor moet optreden om het gedrag van deze instructie te emuleren. Er zijn twee soorten kritische instructies: Controleverloopinstructie Controleverloopinstructies kunnen springen naar code die nog niet vertaald is, in dat geval moeten de instructies op het doeladres vertaald worden vooraleer ze uitgevoerd mogen worden. [22] Gevoelige instructie Gevoelige instructies moeten door de hypervisor geëmuleerd worden omdat het gastbesturingssysteem niet in bevoorrechte modus uitvoert. Een kritische instructie wordt vertaald naar een instructie die een exceptie opwerpt. Bij uitvoering van deze vertaalde instructie vangt de hypervisor de exceptie op. De hypervisor krijgt hierdoor terug de controle en kan de kritische instructie emuleren. Indien nodig vertaalt de hypervisor de instructies die eerstvolgend uitgevoerd moeten worden Zelfwijzigende code Zelfwijzigende code is code die een deel van zijn instructiesequentie overschrijft en zo dus zichzelf wijzigt. In de literatuur [5, 24] kan teruggevonden worden dat er centrale verwerkingseenheden zijn die op de hoogte worden gebracht wanneer er code wijzigt. 12

23 Jammer genoeg is dit voor de ARM-processors niet het geval. Dit betekent dat de hypervisor extra voorzorgsmaatregelen moet treffen om zelfwijzigende code te detecteren. Zelfwijzigende code kan immers instructies schrijven in een instructiesequentie die eerder door de hypervisor vertaald is. Indien de hypervisor niet op de hoogte is gebracht van de wijzigingen, kan hij deze instructies uitvoeren zonder ze eerst te vertalen. Dit zorgt voor problemen indien de zelfwijzigende code gevoelige instructies in de instructiesequentie plaatst. Uit dezelfde literaire bron blijkt ook wat er gedaan kan worden om dynamische binaire vertaling te laten werken wanneer de processor niet op de hoogte wordt gebracht. De hypervisor moet dan de vertaalde delen van de instructiesequentie als enkel lezen en uitvoeren markeren. Indien een schrijfinstructie dan een reeds vertaalde instructie overschrijft, wordt er een exceptie opgeworpen. De hypervisor vangt deze exceptie op en gaat na welke vroegere vertaling wordt aangepast. Vervolgens kan de hypervisor deze vertaling invalideren alvorens de uitvoer van het programma te vervolgen. Wanneer de gewijzigde code vervolgens uitgevoerd moet worden, heeft de hypervisor geen geldige vertaling meer voor deze instructies en moet hij dus eerst een nieuwe vertaling maken. Hierdoor is hij zeker dat de vertaalde codeblokken enkel veilige instructies kunnen bevatten. 2.3 Initiële hypervisor Deze sectie handelt over de Manchester-hypervisor. Het is de bedoeling om de onderdelen van de hypervisor die relevant zijn voor deze scriptie te duiden. Aangezien de Manchesterhypervisor is ontstaan uit 2 eindwerken van studenten aan de universiteit van Manchester, kan de lezer extra informatie vinden in de rapporten voor deze eindwerken [15, 21]. De initiële hypervisor wordt bestudeerd zodat de huidige problemen met zelfwijzigende code achterhaald kunnen worden. In het bijzonder wordt de implementatie van de dynamische binaire vertaling bestudeerd. Met implementatie wordt niet de programmacode zelf bedoeld, maar wel de concepten die de werking verduidelijken 1. Nadat er een overzicht is gegeven van de werking worden de gebruikte datastructuren kort geschetst. Dit wordt gedaan om vervolgens de gemaakte stappen in meer detail te kunnen bespreken. Wanneer de werking duidelijk is, kunnen de tekortkomingen van deze worden toegelicht. Daaropvolgend worden er oplossingen voor deze problemen voorgesteld. Hierbij zal er aandacht besteed worden aan de voor- en nadelen van de mogelijke oplossingen, zodat de beste oplossing gekozen kan worden. 1 Indien de lezer geïnteresseerd is in de programmacode, kan hij desgewenst een kijkje nemen op 13

24 2.3.1 Overzicht van de werking van de dynamische binaire vertaling 1 Bestudeer blok Nee 2 Installeer hypercall Start 0 Vertaald blok in logboek? Ja Haal vertaling uit logboek 1 3 Bewaar vertaling in logboek 3 6 Emuleer kritische instructie Controle terug Voer instructies uit 5 Controle weg Bewaar info in gastcontext 4 Figuur 2.4: Schematische weergave van de werking van dynamische binaire vertaling in de Manchester-hypervisor. Het schema uit figuur 2.4 duidt de werking van de dynamische binaire vertaling in de initiële hypervisor. Deze sectie maakt de verschillende stappen van het schema in de figuur duidelijk. Voor de uitleg die volgt, veronderstellen we dat een niet nader gedefinieerd gastbesturingssysteem wordt uitgevoerd door de hypervisor. De hypervisor gaat eerst na of de instructies die voor het gastbesturingssysteem moeten worden uitgevoerd al vertaald zijn. Indien niet bestudeert hij deze instructies. Deze studie van de instructies laat de hypervisor toe om te bepalen wat de eerste kritische instructie is. De hypervisor vervangt vervolgens deze kritische instructie door een hypercall. De hypercall is een instructie die bij uitvoering de controle terug aan de hypervisor geeft. Na het installeren van de hypercall slaat de hypervisor de nodige vertaalinformatie op in een logboek. Alvorens hij de vertaalde instructies op de hardware laat uitvoeren, slaat de hypervisor informatie op die hij later gebruikt om de kritische instructie te emuleren. Op het moment dat de hypervisor de vertaalde instructies op de hardware laat uitvoeren, verliest hij de controle over de hardware tot de hypercall is uitgevoerd. Wanneer de hypervisor de controle terugkrijgt, emuleert hij de kritische instructie waardoor hij weet wat het adres is van de instructie die eerstvolgend uitgevoerd moet worden. Met dit adres kan de hypervisor de volgende cyclus starten bij stap 0. Indien in stap 0 er reeds een vertaling aanwezig is, haalt de hypervisor deze vertaling op en kan hij de informatie die hij nodig heeft voor het emuleren van de kritische instructie direct opslaan. Hierdoor kunnen stappen één tot en met drie overgeslagen worden. 14