De Java security architectuur op embedded systemen. Chris Vanden Berghe

Transcriptie

1 De Java security architectuur op embedded systemen Chris Vanden Berghe 3 mei 2001

2 Dankwoord Allereerst bedank ik mijn promotor, Prof. Dr. ir. Frank Piessens, voor zijn bereidheid om deze thesis te begeleiden. Ik apprecieer zowel de steun, als de kritische bedenkingen die hij mij bezorgde. Mijn begeleider bij Acunia, ir. Vincent Nollet, wil ik in de eerste plaats bedanken voor het boeiende onderwerp waarmee hij mij in contact heeft gebracht. Tevens ben ik hem dankbaar voor de talrijke interessante gesprekken, en zijn feedback op de code. Gregor wens ik te bedanken voor de vele uren die hij gespendeerd heeft aan het nalezen van deze tekst. Ik kan me geen betere vriend voorstellen. Tenslotte zijn er nog mijn ouders, die ik dankbaar ben omdat ze me steunen door dik en dun, en omdat ze me de kans hebben gegeven om te studeren. 1

3 Inhoudsopgave 1 Inleiding Situering Overzicht Voertuigentelematica Wat is voertuigentelematica?[15] Evolutie van de voertuigentelematica[2] Acunia Open Telematica Platform[2][14][15] Bedenkingen omtrent beveiliging[7][8][12] De Java Virtuele Machine Java architectuur[11] De logische structuur van de JVM[4] De methodenruimte De objectenruimte De Java virtuele machine stapel De native method stack De instructieset[4][11] Argumenten en operanden Data types Instructie categorieën Methode aanroepen Behandeling van uitzonderingen en finally constructie Creatie en manipulatie van objecten Java en embedded systemen[3][12][19] Voordelen van Java Nadelen van Java Java beveiliging voor mobiele code Evolutie van mobiele code[12] Gevaren van mobiele code[7][8][12][13] Schending van integriteit Schending van de privacy

4 4.2.3 Beschikbaarheids aanvallen Het oorspronkelijke Java beveiligingsmodel: de zandbak[8][12] De verifier De class loader De security manager Een eerste stap naar een minder restrictief beveligingsmodel: JDK 1.1[8][12] Een volledig configureerbaar beveiligingsmodel: het Java 2 Platform[8][12] Waarom dit nieuwe beveiligingsmodel? De nieuwe en aangepaste onderdelen Samengevat De verifier Het laadproces[11] Laden Linken Initialisatie De eerste verificatie stap[4][6][11][23] De tweede verificatie stap[4][6][11][23] De derde verificatie stap[4][11][23] Control-flow analyse Data-flow analyse Uitbreidingen op het data-flow algoritme De vierde verificatie stap[4][11][23] Invloed op de beveiliging[4][12] Faalt enkel gevaarlijke code voor de verifier?[4] Implementatie Inleiding Overzicht van het programma De eerste verificatie stap De tweede verificatie stap Control-flow analyse[1] Control-flow graphs Algoritme Voorbeeld Data-flow analyse Aangepast algoritme Voordelen Implementatie Acunia Pre-verificatie[18] Testen[18]

5 7 Besluit 95 4

6 Lijst van figuren 2.1 Acunia s open telematica concept Het beveiligingsmodel in JDK Het beveiligingsmodel in JDK Policy Protection Domains Laden van klassen via delegatie Het beveiligingsmodel in JDK De initiële operanden stapel en lokale variabelen De operanden stapel en lokale variabelen na uitvoering van de ifne instructie De operanden stapel en lokale variabelen aan het einde van de data-flow analyse De initiële operanden stapel en lokale variabelen De operanden stapel en lokale variabelen na uitvoering van de goto instructie Klasse hiërarchie De operanden stapel en lokale variabelen aan het einde van de data-flow analyse Control-flow graph Opeenvolgende stappen bij het aanmaken van de control-flow graph Vergelijking van het aantal bytes en basic blocks voor ca methodes

7 Hoofdstuk 1 Inleiding 1.1 Situering In onze huidige maatschappij, die volledig draait rond kennis en informatie, zijn netwerken niet meer weg te denken. Informatie dient overal en altijd beschikbaar te zijn. Momenteel is de computer daarbij nog ons belangrijkste hulpmiddel, maar dit belooft snel te veranderen ten voordele van allerlei consumentenelektronica. Verwacht wordt dat er zich over enkele jaren meer mensen met een GSM of zakcomputer op het Internet zullen begeven, dan met een gewone computer. Gelijktijdig met de nood aan informatie, neemt ook de nood aan beveiliging van informatie toe. Java werpt zich op als een platform dat informatie overal en altijd op een veilige manier beschikbaar maakt. Het is voornamelijk dit veiligheidsapect dat we in deze thesis zullen belichten. Daartoe bekijken we eerst de Java beveiligingsarchitectuur in zijn geheel. Deze architectuur is opgebouwd uit een aantal onderdelen die gezamenlijk voor de veiligheid instaan. Vervolgens gaan we een van deze onderdelen, met name de verifier, grondiger bestuderen. Wat de taak van de verifier is, bespreken we verder. De studie van de verifier zal gebeuren uit het oogpunt van embedded systemen. Het begrip embedded systeem is heel ruim, en de grens tussen wat we wel of niet tot deze categorie rekenen zeer vaag. Een eigenschap die veel embedded systemen gemeenschappelijk hebben, is de beperkte beschikbaarheid van systeembronnen. Het zal dan ook in dit kader zijn dat we de verifier bekijken. Om deze studie een concrete toepassing te geven, hebben we ons toegespitst op een bestaand systeem, met name het Acunia Open Telematica Platform. 6

8 Telematica is het gebruik van informatica voor gegevensverwerking en - besturing, waarbij de fysische lokatie van de gegevens en het te bestuderen systeem niet van belang zijn. Acunia richt zich op telematica toepassingen voor voertuigen. Op deze manier brengen zij het overal en altijd beschikbaar zijn van informatie een stap dichterbij. Het is een zeer interessant platform voor deze studie, omdat het volledig op Java gebaseerd is en de beveiligingsvereisten, onder andere door de integratie met vitale delen van de wagen, bijzonder hoog liggen. Als praktisch resultaat van deze thesis stellen we de implementatie van een geheugenvriendelijke verifier voorop. Het primaire doelplatform van deze verifier is het Acunia platform, maar we wensen ook de mogelijkheid om deze als een alleenstaande applicatie te gebruiken. In hoofdstuk 6 gaan we uitgebreid in op deze implementatie. 1.2 Overzicht We zullen nu kort de volgende hoofdstukken uit deze thesistekst toelichten. Hoofdstuk 2: Voertuigentelematica De bedoeling van dit hoofdstuk is om de lezer van enige achtergrond te voorzien over voertuigentelematica in het algemeen en het Acunia platform in het bijzonder. We gaan ook in op de veiligheidsaspecten gerelateerd aan deze technologie. Hoofdstuk 3: De Java Virtuele Machine We leggen hier kort enkele begrippen van de Java virtuele machine uit. We benadrukken hierbij de aspecten die relevant zijn voor de verifier. We gaan ook na in hoeverre Java geschikt is als platform voor embedded systemen. Hoofdstuk 4: Java beveiliging voor mobiele code We bespreken hier het begrip mobiele code, en de gevaren die eraan verbonden zijn. Java biedt enkele technieken die het mogelijk maken om mobiele code op een veilige manier te gebruiken. We bespreken deze technieken, gezamenlijk de Java beveiligingsarchitectuur genaamd, en hun evolutie sinds het ontstaan van Java. Hoofdstuk 5: De verifier In dit hoofdstuk belichten we de verifier als een van de onderdelen van de Java beveiligingsarchitectuur, meer gedetailleerd. We overlopen de taak van 7

9 de verifier doorheen het laden van een klasse, de verschillende stappen van het verificatie algoritme en hun relevantie voor de geboden beveiliging. Hoofdstuk 6: Implementatie Als praktisch resultaat van deze thesis is de implementatie van een geheugenvriendelijke verifier vooropgesteld. In hoofdstuk 6 gaan we de kenmerken van deze verifier na, en lichten we het aangepaste algoritme toe. Hoofdstuk 7: Besluit Tenslotte is er nog het algemene besluit, waar we het afgeleverde resultaat kritisch bekijken en mogelijke verbeteringen of uitbreidingen suggereren. 8

10 Hoofdstuk 2 Voertuigentelematica 2.1 Wat is voertuigentelematica?[15] Voertuigentelematica 1 is de technologie die informatica-toepassingen in voertuigen introduceert en via diverse telecommunicatietoepassingen een schier onbeperkt aantal diensten ontsluit. Het vormt als het ware een brug tussen de service provider en de gebruiker van de diensten. Mogelijke toepassingen van deze informatie- en assistentiediensten zijn: Lokalisatie van voertuigen: maakt het mogelijk om gestolen voertuigen terug te vinden, of een wagenpark efficiënt te beheren. Navigatiehulp: gebruikmakend van recente elektronische wegenkaarten, kan men navigatiehulp bekomen die weers- en verkeersinformatie incorporeert. Ook toeristische informatie kan op deze wijze opgevraagd worden. Mobiele communicatie: diensten als , internet toegang, instant messaging,... kunnen aan de inzittenden aangeboden worden. Verkeers management: door real-time informatie te verzamelen van een groot aantal voertuigen, kunnen verkeersproblemen nauwkeurig gedetecteerd, geanalyseerd en eventueel zelfs voorspeld worden. Veiligheid: automatische snelheidsaanpassing afhankelijk van de verkeerssituatie en weersomstandigheden. Identificatie: voertuigen kunnen op een eenvoudige én correcte wijze geïdentificeerd worden. 1 Engelse benaming: vehicle telematics (Europa), intelligent transportation systems (Verenigde Staten) 9

11 Interne diagnostiek: maakt detectie van technische problemen vanop afstand mogelijk. Elektronische betalingen: automatische betaling van verkeersbelasting, tol en parking. Flexibele verzekeringen: verzekeringspremies kunnen periodiek aangepast worden aan het profiel van de bestuurder. Dit profiel kan factoren omvatten zoals het rijgedrag, en de omvang en aard van de gemaakte verplaatsingen. Dit moet uiteraard met expliciete instemming van de bestuurder in kwestie gebeuren, en met in acht name van zijn privacy. 2.2 Evolutie van de voertuigentelematica[2] In de evolutie van de voertuigentelematica worden drie generaties onderscheiden: Eerste generatie Deze systemen zijn rond 1995 geïntroduceerd. Elke telematicatoepassing wordt gerealiseerd door een autonoom systeem. Er is nog geen sprake van onderling compatibele hardware, waardoor de hardware componenten voor elke dienst afzonderlijk voorzien moeten worden. Dit maakt een eerste generatie systeem bijzonder duur. In het voorbeeld van een after-theft systeem betekent dit bijvoorbeeld dat het communicatiemiddel (bv. een GSM 2 ) en het lokalisatiemiddel (GPS 3 ) onder ideale omstandigheden nooit gebruikt zullen worden. Tweede generatie Systemen van de tweede generatie lossen dit probleem op door meerdere diensten te integreren in één toestel. De beschikbare hardware wordt op deze manier beter benut, zodat de kosten gedrukt worden. Deze toestellen bieden onder andere toeristische- en verkeersinformatie, navigatie hulp en after-theft systemen aan. Het toevoegen van nieuwe diensten is echter moeilijk, omdat de bestaande tweede generatie systemen gepatendeerde producten zijn. Derde generatie Systemen van de derde generatie gaan nog een stap verder. Zij bieden een platform, met een breed spectrum aan telecommunicatie middelen voor 2 Global System for Mobile communications 3 Global Positioning System 10

12 zowel bidirectionele (bv. GPRS 4, UMTS 5, Bluetooth 6 ) als unidirectionele communicatie (bv. DAB 7 ), waarop allerlei diensten kunnen aangeboden worden. Wil de bestuurder van een nieuwe dienst gebruik maken, dan kan hij die automatisch laten installeren. Er wordt ook gestreefd naar compatibiliteit met bestaande hardware standaarden. Dit maakt het toevoegen van extra hardware goedkoop, eenvoudig en gestandaardiseerd. Het Acunia Open Telematica Platform is een voorbeeld van een derde generatie voertuigentelematica systeem. 2.3 Acunia Open Telematica Platform[2][14][15] Acunia is in 1996 onder de naam SmartMove opgericht als een spin-off van de onderzoeksinstelling IMEC 8. De oorspronkelijke doelstelling was het ontwikkelen van een after-theft systeem dat, gebruik makend van pagingtechnologie, gestolen wagens kan opsporen en vanop afstand stilleggen. Uit de ervaring die men hierbij opdeed, en het besef dat voertuigentelematica heel wat meer mogelijkheden biedt, onstond het idee om een open standaard voor voertuigentelematica te creëren. Voor de aanbieder van deze diensten is de vrije beschikbaarheid van de standaard een belangrijk gegeven, omdat dit de mogelijkheid biedt om op uniforme wijze diensten aan te bieden aan alle gebruikers. Acunia streeft naar volledige compatibiliteit met de standaard gedefinieerd door het Open Services Gateway Initiative. OSGi is een industriële groepering die zich de definitie en voorspraak van een open standaard voor interconnectie van de komende generatie consumptie-elektronica tot doel stelt. De centrale OSGi component is de services gateway, een embedded server die de aanbieders van diensten via een Wide Area Network verbindt met een lokaal netwerk van gebruikers. Om deze flexibiliteit te kunnen bieden is een modulaire aanpak noodzakelijk. Het Acunia Open Telematica Platform bestaat uit volgende drie lagen: 4 General Packet Radio System 5 Universal Mobile Telephone Service 6 Standaard voor draadloze netwerktechnologie. Genoemd naar de Deense koning Harald Blåtand ( AD), die Denemarken en Noorwegen verenigde, omdat deze standaard als doel had de telecom- en computerindustrie te verenigen. 7 Digital Audio Broadcast 8 Interuniversity Micro-Electronics Center 11

13 service provider service provider service provider communicatie - en controle centrum publiek netwerk voertuig Figuur 2.1: Acunia s open telematica concept Een gestandaardiseerde omgeving voor het aanbieden van diensten: Acunia biedt een toolkit of API 9 aan die het mogelijk maakt voor service providers om zelf diensten te ontwikkelen of pasklare diensten aan te kopen van zogenaamde application providers. Deze diensten kunnen dan probleemloos in het systeem geïntegreerd worden. Een communicatie- en controlecentrum: Het communicatie- en controlecentrum, ook wel CCC genoemd, is het centrale aanspreekpunt van het platform. Alle communicatie tussen service providers en gebruikers loopt via het CCC. Het biedt uiteenlopende administratieve diensten aan zoals logging, facturatie, beveiliging, toegangscontrole, databank management,... Een gestandaardiseerde on-board module: De on-board module maakt het platform compleet. Acunia ontwikkelt een hardware module, gebaseerd op de StrongARM processor, die compatibel is met verschillende standaarden voor de fysieke aansluiting van randapparatuur, waaronder USB 10 en CAN 11. Door deze standaarden te ondersteunen wordt het ontwikkelen van extra randapparatuur veel goedkoper. Het 9 Application Programming Interface 10 Universal Serial Bus 11 Controller Area Network 12

14 ontwerp van deze hardware module zal gebruikt worden als referentie, ook apparatuur van andere fabrikanten kan als on-board module fungeren. Gelijktijdig wordt een gestandaardiseerd software platform, gebaseerd op het Java 2 Platform, ontwikkeld. Ook hier is het mogelijk om voor een Java omgeving afkomstig van een andere fabrikant te kiezen. Het software platform ondersteunt diverse protocollen voor logische toegang tot randapparatuur waaronder UPnP 12 en Jini. Deze protocollen zorgen voor het probleemloos toevoegen, beheren en verwijderen van hardware. De door Acunia ontwikkelde Java omgeving werd Wonka gedoopt, dit is het onderdeel waarmee ik het meest in aanraking gekomen ben. 2.4 Bedenkingen omtrent beveiliging[7][8][12] Derde generatie telematica systemen bieden uitermate interessante perspectieven, waarvan we de reële impact slechts kunnen vermoeden. Het is in dit verband aangewezen om ook eens stil te staan bij de risico s die deze technologie met zich meebrengt, met name op het gebied van veiligheid. Beveiliging gaat over het voorkomen van ongewenste zaken. Dit is een zeer eenvoudige definitie, maar de implicaties zijn minder eenvoudig en erg afhankelijk van de situatie. Enkele vuistregels zijn echter altijd toepasbaar: Beveiliging en de menselijke factor Bij de ontwikkeling van een beveiligingsarchitectuur mag de gebruiker nooit uit het oog verloren worden. Het ideale beveiligingsconcept is volledig transparant voor de doorsnee gebruiker. Ontwikkelt men daarentegen een systeem dat te omslachtig of te complex is, dan hebben mensen de neiging om de veiligheidsmaatregelen naast zich neer te leggen. Gebuikers verplichten om regelmatig hun wachtwoord te veranderen is vanuit beveiligingsoogpunt een goed idee. Wanneer dit echter tot gevolg heeft dat de gebruiker zijn wachtwoord niet kan onthouden, en het bijvoorbeeld op een briefje aan zijn scherm hangt, mist deze maatregel duidelijk zijn doel. Voertuigentelematica richt zich tot een ruime gebruikersgroep. Deze vuistregel is hier dus zeker van toepassing, en maakt de ontwikkeling van een afdoende beveiliging niet bepaald eenvoudiger. In dit verband kan het zinnig zijn om een gedragsstudie bij zijn doelpubliek te organiseren, zodat men gevaarlijke situaties zoals in bovenstaand voorbeeld tijdig ontdekt. 12 Universal Plug and Play 13

15 Beveiliging is relatief tot de bedreiging Vermits volledige veiligheid meestal onmogelijk is, zal een veiligheidsarchitect voor iedere situatie moeten bepalen wat een afdoende beveiliging is. De vereisten voor de beveiliging van staatsgeheimen zijn duidelijk verschillend van die voor de gegevens van de doorsnee gebruiker. De te nemen maatregelen worden dan ook best op deze vereisten afgestemd. De veiligheidsvereisten voor een voeruigentelematica systeem kunnen moeilijk overschat worden, vermits zo n systeem met vitale functies van de wagen geïntegreerd wordt. Als de veiligheid van het systeem gecompromitteerd wordt, kunnen talloze doemscenario s realiteit worden. Enkele voorbeelden: het ongewenst stilleggen van wagens, omzeilen van anti- en after-theft systemen, beschadiging van wagens door installatie van foutieve firmware,... Ook het mobile agent concept toegepast in het telematica systeem, roept vele vragen op. Hierbij wordt code, al dan niet uit vertrouwde bron, over een publiek netwerk gedownload om lokaal op het telematica platform uitgevoerd te worden. Hoe kunnen we een misdragen van deze code voorkomen? Deze vraag trachten we te beantwoorden in hoofdstuk 4. Beveiliging mag functionaliteit niet in de weg staan Een goede beveiligingsarchitectuur heeft een slechts zeer beperkte invloed op de functionaliteit. Zo is de eenvoudigste oplossing om een auto-ongeval te vermijden, de auto altijd in de garage te laten staan. Het is duidelijk dat deze oplossing niet aanvaardbaar is, daar deze de functionaliteit van de auto te fel beperkt. We zullen nog op deze vuistregel terugkomen wanneer we het hebben over de beveiligingsarchitectuur van Java. Beveiliging is maar zo sterk als de zwakste schakel Tenslotte moet veiligheid altijd uit het oogpunt van het volledige systeem beschouwd worden. In het geval van de voertuigentelematica moeten de gebruiker, de voertuigenmodule, het communicatie netwerk, het communicatie- en controlecentrum én de service providers bij de ontwikkeling van de beveiligingsarchitectuur betrokken worden. Besluit Deze vuistregels maken duidelijk dat het ontwikkelen van een goede beveiligingsarchitectuur complexer is dan de hoger gegeven definitie doet vermoeden, en een grondige kennis van het systeem als geheel vereist. In het geval van de voertuigentelematica maken de zware consequenties van een falende beveiliging de situatie er niet eenvoudiger op. 14

16 Het beveiligingsmodel waarop Acunia steunt is grotendeels gebaseerd op de beveiligingskenmerken van het Java 2 Platform. Deze thesis heeft als doelstelling om een deelaspect van dit beveiligingsmodel uit te werken. 15

17 Hoofdstuk 3 De Java Virtuele Machine De betrachting van dit hoofdstuk is de lezer van enige achtergrond te voorzien omtrent de interne werking van een Java virtuele machine (JVM). We streven hier geenszins naar een volledige beschrijving 1, maar wensen toch voldoende achtergrond te verschaffen om het in hoofdstuk 5 beschreven verificatie algoritme in de juiste context te kunnen plaatsen. 3.1 Java architectuur[11] De Java architectuur bestaat uit drie grote onderdelen: 1. de Java programmeertaal, 2. de Java Application Programming Interface, en 3. de Java Virtuele Machine. De twee laatste delen vormen samen het Java platform ; vanaf versie 1.2 spreken we over het Java 2 Platform. Het Java platform biedt een uitvoeringsomgeving die onafhankelijk is van de onderliggende architectuur. Het grootste deel van de Java programma s beschikbaar voor het Java platform zijn geschreven in de Java programmeertaal, maar dit is geen vereiste. Het Java platform kent immers slechts één formaat, dit formaat noemen we het class file formaat. Compilers die zulke class files genereren zijn beschikbaar voor diverse programmeertalen, waaronder (uiteraard) Java, maar ook Scheme, Eiffel, Python, Tcl, Ada, en anderen. Het is zelfs mogelijk om rechtstreeks, of met behulp van een assembler taal, programma s te schrijven die door het Java platform uitgevoerd kunnen worden. 1 Daarvoor kan de geïnteresseerde lezer terecht bij de officiële JVM specificatie opgesteld door Sun: The Java Virtual Machine Specification, Second Edition - Tim Lindholm & Frank Yellin 16

18 Java is in 1995 geïntroduceerd, en kende zijn doorbraak onder de vorm van applets. De Java virtuele machine is gebaseerd op een in 1992 ontwikkeld uitvoeringsplatform voor de programmeertaal Oak, dat de wereld van embedded systemen als focus had. Java is desondanks populair geworden op de PC, maar kent nu tegelijk een expansie naar zowel kleinere als grotere systemen. Zo richt de Java 2 Micro Edition zich op allerlei consumentenelektronica, van netwerk computers tot mobiele telefoons. De Java 2 Enterprise Edition daarentegen, spitst zich toe op grotere systemen, zoals webservers. Tenslotte is er nog de Java Card Edition, bedoeld als platform voor smart cards. Ons interesseert voornamelijk de Java 2 Micro Edition, vanwege de focus op embedded systemen zoals het Acunia platform. De Java 2 Micro Edition wordt op basis van de beschikbare systeembronnen nogmaals opgedeeld in een Connected Device Configuration (CDC) en een Connected, Limited Device Configuration (CLDC). Sommige systemen, waaronder het Acunia platform, ondersteunen een volledig Java platform, waarvan de minimale vereisten in de CDC gespecifieerd zijn. Voor andere systemen, met stringentere beperkingen op het gebied van beschikbare bronnen, is de CLDC specificatie opgesteld. De minimale vereisten hiervan zijn ook haalbaar voor systemen met slechts enkele honderden kilobytes geheugen beschikbaar. CLDC systemen zijn gebaseerd op een aangepaste virtuele machine en een erg beperkte API. De officiële specificatie van de Java virtuele machine wordt beschreven in The Java Virtual Machine Specification door Tim Lindholm en Frank Yellin. De gegeven specificatie beschrijft volgende aspecten: de logische structuur van de JVM, de instructieset, het class file formaat, de verifier, en het laadproces van klassen. De eerste twee onderdelen worden in dit hoofdstuk besproken, de andere delen komen verder in de tekst aan bod. Zo bespreken we het class file formaat en de verifier wanneer we het verificatie algoritme toelichten. Het laadproces wordt gedeeltelijk beschreven in het hoofdstuk over Java beveiliging, en ook weer gedeeltelijk wanneer we dieper ingaan op het verificatie algoritme. 17

19 3.2 De logische structuur van de JVM[4] De JVM specificatie beschrijft de virtuele machine op conceptuele wijze, en laat zo een bijzonder grote implementatievrijheid. Zo is het mogelijk om een virtuele machine te maken die beter is dan de referentie implementatie van Sun; zelfs een volledig in hardware geïmplementeerde JVM is mogelijk. In de eerste plaats bespreken we de werking van de virtuele machine aan de hand van de conceptuele geheugenopmaak. We onderscheiden daarbij de volgende delen: de methodenruimte, de objectenruimte, de Java virtuele machine stapel, en de native method stack De methodenruimte De methodenruimte, of method area, is de geheugenruimte waar klassen (en interfaces) geladen door de virtuele machine in bewaard worden. Deze geheugenruimte wordt aangemaakt bij het opstarten van de virtuele machine, en is gemeenschappelijk aan alle threads. De klassen die hier worden geladen dienen als een template voor het construeren van objecten. Per klasse worden er structuren opgebouwd met een runtime constant pool, gegevens over velden en methodes, en de eigenlijke code van methodes en constructoren. Deze eigenschappen van klassen zijn statisch; ze kunnen niet meer gewijzigd worden eenmaal de klasse geladen is. Er bestaan twee soorten velden: statische en niet-statische. Voor statische velden is er slechts één exemplaar per klasse, voor niet-statische velden daarentegen is er één exemplaar per instantie van deze klassen. Iedere klasse, met java.lang.object als uitzondering, heeft een superklasse, en geen of meerdere interfaces. Wanneer een klasse geladen wordt, worden tegelijk ook haar superklasse en al haar interfaces geladen. Om een methode aan te roepen, of om naar een variabele te verwijzen, worden symbolische namen gebruikt. Bij uitvoering moeten deze symbolische namen eerst naar concrete referenties worden omgezet. Deze omzetting gebeurt typisch bij de eerste verwijzing naar de symbolische naam. Wanneer deze concrete referentie bepaald is, dan wordt die in de runtime constant pool bewaard. Op deze manier moet een symbolische naam maar één keer omgezet worden. 18

20 3.2.2 De objectenruimte In de objectenruimte, of heap worden alle objecten bewaard. Al deze objecten zijn instanties van klassen, gedefinieerd in de methodenruimte. In alle objecten is plaats voorzien voor ieder niet-statisch veld in de bijbehorende klasse en alle superklassen. Indien een klasse en haar superklasse een veld met dezelfde naam bevatten, dan zal dit veld dus tweemaal aanwezig zijn in het object. Deze velden kunnen toch onderscheiden worden, omdat steeds de volledige naam, van de vorm pakket/klasse naam/veld naam, gebruikt wordt. Ieder object neemt een zekere hoeveelheid geheugen in, waarvan er een eindige hoeveelheid beschikbaar is. Daarom wordt het geheugen ingenomen door objecten teruggevorderd wanneer de objecten niet meer in gebruik zijn. De Java specificatie legt op dat dit automatisch moet gebeuren door een garbage collector, maar laat de keuze van het algoritme vrij. Een object wordt als in gebruik beschouwd, als ernaar gerefereerd wordt vanuit: de stack of een lokale variabele, een statisch veld, een niet statisch veld van een object dat zelf nog in gebruik is, of de JVM zelf. In alle andere gevallen wordt het object als ongebruikt beschouwd. Speciale voorzieningen moeten getroffen worden indien een object een finalize() method heeft. In dat geval kan het ongebruikte object zichzelf immers terug tot leven wekken De Java virtuele machine stapel Bij iedere methode aanroep wordt een nieuwe stack frame aangemaakt. Al deze stack frames, behorende tot een bepaalde thread, vormen samen een Java virtuele machine stapel, of Java virtual machine stack. De Java virtuele machine stapel wordt aangemaakt bij creatie van een nieuwe thread. Deze geheugenruimte is enkel een logische stapel, in het fysische geheugen is er meestal geen continue allocatie. Een stack frame bevat volgende onderdelen: de operanden stapel, de lokale variabelen lijst, een verwijzing naar de runtime constant pool, en 19

21 de programma teller. Een stack frame wordt gebruikt om gegevens en tussenresultaten te bewaren, alsook om resultaatwaarden van methodes door te geven, uitzonderingen af te handelen en dynamisch linken mogelijk te maken. Het bovenste frame wordt het actieve frame genoemd, en bevat een momentopname van de methode in uitvoering. Wanneer deze methode een andere methode aanroept, zal een nieuw frame aangemaakt worden dat bovenaan de stapel komt. Bij het beëindigen van de methode wordt het actieve frame van de stapel gehaald, en wordt de oproepende methode opnieuw het actieve frame. Ieder frame bevat een lijst van variabelen die we de lokale variabelen noemen. Deze worden gebruikt om tussenresultaten te bewaren, maar ook om parameters door te geven bij een methode aanroep. De lokale variabelen van een nieuw frame bevatten de parameters en, als het geen statische methode is, een referentie naar het object waarop de methode inwerkt. De grootte van de lokale variabelen lijst wordt tijdens het compileren bepaald, en verandert niet tijdens de uitvoering. Een frame bevat ook een last-in-first-out, of LIFO, operanden stapel. Bij de aanmaak van een nieuw stack frame zal deze operanden stapel leeg zijn. De JVM voorziet instructies om gegevens tussen de lokale variabelen lijst en de operanden stapel uit te wisselen. Andere instructies werken rechtstreeks met de operanden op de stapel. De operanden stapel wordt ook gebruikt om parameters klaar te zetten voor een methode aanroep. Deze parameters worden dan in de lokale variabelen lijst van het nieuw gecreëerde stack frame geplaatst. De maximale grootte van de operanden stapel wordt ook weer tijdens het compileren bepaald. De programma teller is een verwijzing naar de eigenlijke code van een methode in de method stack. Normaal wordt de programmateller verhoogd met de lengte van de instructie. Control flow instructies en uitzonderingen kunnen het normale verloop van de programma teller echter wijzigen De native method stack Sommige dingen, zoals bijvoorbeeld het aanroepen van platform specifieke hardware, kunnen niet in JVM instructies beschreven worden. Daarom biedt Java de mogelijkheid om methodes in platform specifieke code te implementeren. Deze native methods, zoals ze genoemd worden, gebruiken ook een stapel om hun status te bewaren. De JVM voorziet daarvoor de native method stack, ook wel de C stapel genoemd. 20

22 3.3 De instructieset[4][11] De JVM is een virtuele computer met een eigen instructieset. We gaan hier in op het onderscheid tussen argumenten en operanden, de verschillende datatypes en instructie categorieën. Elke categorie in detail bespreken zou ons te ver leiden. We beperken ons daarom tot een bondige uitleg over methode aanroepen, behandeling van uitzonderingen, en object manipulatie Argumenten en operanden Instructies bestaan uit twee delen: een uit één byte bestaande opcode en een aantal argumenten. Afhankelijk van de instructie, zijn er geen, één of meerdere, of een variabel aantal argumenten. Vermits deze argumenten in de bytecode verweven zitten, zijn ze onveranderlijk. Dikwijls verwijzen deze argumenten naar een bepaalde gegevenslocatie, zoals een plaats in de constant pool of een lokale variabele. Indien een argument uit meer dan één byte bestaat, dan worden de opeenvolgende bytes in big-endian volgorde geplaatst. Zo wordt de tekenloze 16-bit index naar een lokale variabele voorgesteld door twee bytes, byte1 en byte2; de index wordt dan berekend uit (byte1 8) byte2. Operanden zijn daarentegen gegevens die zich op de operanden stapel bevinden. Zo haalt de iadd instructie de twee bovenste elementen van de operanden stapel, en plaatst vervolgens de som bovenaan de stapel Data types De JVM ondersteunt volgende datatypes: int (32-bit integer), long (64-bit integer), float (32-bit drijvende komma getal), double (64-bit drijvende komma getal), reference, en returnaddress. De eerste vier types komen overeen met de gelijknamige types uit de Java programmeertaal. Voor de ontbrekende numerieke types, met name boolean, byte, short en char, is er slechts een beperkte JVM ondersteuning. In de meeste gevallen worden die als int behandeld. 21

23 Een reference is een verwijzing naar een object in de objectenruimte. Er zijn drie types te onderscheiden: class reference, array reference, en interface reference. De null reference is een speciale reference zonder type. References in de JVM zijn gelijkaardig aan C pointers, maar er zijn toch enkele vermeldenswaardige verschillen. Zo is bijvoorbeeld rekenen met references niet mogelijk. Ook verwijzen references enkel naar objecten, en niet naar lokale variabelen, stapel elementen,... Het laatste type, het returnaddress, wordt enkel gebruikt door de jsr, ret en jsr w instructies. Deze instructies zijn bedoeld om de finally constructie te implementeren. Dit type heeft geen tegenhanger in de Java programmeertaal. Int, float, reference, en returnaddress operanden worden types van categorie 1 genoemd, en nemen juist één plaats in op de operanden stapel of in de lokale variabelen. Operanden van het long of double type vormen de types van categorie 2 en nemen twee plaatsen in Instructie categorieën JVM instructies kunnen in volgende categorieën onderverdeeld worden: aritmetische instructies, laad- en bewaarinstructies, stapel manipulaties, methode aanroepen, behandeling van uitzonderingen, type conversies, creatie en manipulatie van objecten, control-flow instructies, synchronisatie, en instructies ter implementatie van de finally constructie. De mnemotechnische benaming van instructies heeft als conventie dat de eerste letter het type aangeeft waarop de instructie van toepassing is. Zo staat i voor een operatie op een int, l voor long, b voor byte, s voor short, c voor char, f voor float, d voor double en a voor reference. Een voorbeeld is de add instructie, die bestaat als iadd, ladd, fadd en dadd. Sommige operaties zijn niet typespecifiek, en hebben dan ook geen typevermelding in hun naam. 22

24 3.3.4 Methode aanroepen Een methode kan met 4 verschillende instructies worden aangeroepen, afhankelijk van de aard van de methode en de klasse waartoe ze behoort. Zo onderscheiden we invokevirtual, invokeinterface, invokespecial, en invokestatic. De eerste stap van een methode aanroep, is het klaarzetten van de parameters. Zo zal voor een niet-statische methode eerst een referentie naar het object waarop de methode inwerkt op de stapel geplaatst worden. Vervolgens worden de nodige parameters op de stapel geplaatst, in de volgorde zoals gespecifieerd in de methode beschrijving. Deze methode beschrijving kan in de constant pool gevonden worden. Ter illustratie, de standaard methode beschrijving van de main methode is ([Ljava/lang/String;)V. Het deel tussen de haakjes beschrijft de parameters; hier wordt een referentie naar een rij van String objecten verwacht. Het deel na de haakjes specifieert het return type, in dit geval is dat void. Bij de volgende stap wordt een nieuwe stack frame gecreëerd. De lokale variabelen lijst wordt gedeeltelijke geïnitialiseerd met de methode parameters die van de operanden stapel gehaald worden. De nieuwe operanden stapel is initieel leeg. Wanneer er geen uitzondering is opgetreden, zal de methode eindigen met een return instructie. Deze instructie vereist dat zich op de operanden stapel een operand van het return type van de methode bevindt. Het stack frame wordt vervolgens verwijderd, en de return waarde wordt dan op de operanden stapel van de aanroepende methode geplaatst. Het stack frame van deze methode wordt opnieuw actief, en de uitvoering hervat. De normale manier om een methode aan te roepen is de invokevirtual instructie. De naam is afgeleid van virtual dispatch, het mechanisme gebruikt om de uit te voeren methode te selecteren. Eerst zal gekeken worden of er in het object, waarop de methode inwerkt, een methode bestaat met exact dezelfde naam en beschrijving. Indien dit het geval is, zal deze methode worden uitgevoerd. In het andere geval past men hetzelfde mechanisme toe op de superklasse. De invokespecial instructie wordt daarentegen enkel gebruikt voor het aanroepen van constructoren en methodes van de klasse zelf of haar superklasse. Hier wordt geen virtual dispatch mechanisme toegepast om de methode te selecteren, maar het is exact de gespecifieerde methode die uitgevoerd wordt. Constructoren krijgen in de JVM een speciale benaming: <init> voor object initialisatie en <clinit> voor klasse initialisatie. 23

25 Tenslotte zijn er nog de invokestatic en invokeinterface instructies. Deze instructies worden respectievelijk gebruikt voor het aanroepen van statische methodes en methodes gespecifieerd in interfaces Behandeling van uitzonderingen en finally constructie Uitzonderingen, of exceptions, worden gebruikt om een abnormale situatie te signaleren. Uitzonderingen hebben drie verschillende oorzaken: 1. De JVM merkt een synchrone abnormale uitvoeringssituatie op. Zulke situatie treedt niet op een willekeurig moment op, maar als gevolg van de uitvoering van een instructie. Voorbeelden zijn: optreden van een fout tijdens het laad- of linkproces te veel geheugen gealloceerd deling door nul Een uitzondering werd expliciet geworpen. Dit gebeurt via de athrow instructie. 3. Er doet zich een asynchrone abnormale uitvoeringssituatie voor. Bijvoorbeeld: Het aanroepen van de stop methode van een bepaalde Thread of ThreadGroup. Interne JVM error. Een uitzondering is een instantie van een subklasse van java.lang.throwable. We zullen nu aan de hand van een klein voorbeeldje zien hoe uitzonderingen kunnen opgevangen worden in de JVM. Onderstaande methode wordt aan de rechterkant in bytecode vertaald. void tweehandlers(){ try{ 0: ALOAD_0 eenmethode(); 1: INVOKEVIRTUAL } 4: RETURN catch (EenUitzondering e) 5: ASTORE_1 { 6: ALOAD_0 handler(); 7: INVOKEVIRTUAL } 10: RETURN catch (Exception e) 11: ASTORE_1 { 12: ALOAD_0 handler(); 13: INVOKEVIRTUAL } 16: RETURN } 24

26 Bij de bytecode hoort nog een exception table: from to handler exception EenUitzondering Exception Indien eenmethode() geen uitzondering gooit, dan zullen enkel de instructies van byte 0 tot 4 uitgevoerd worden. Indien wel een uitzondering gegooid wordt, dan zal de JVM in de exception table van voor naar achter zoeken naar een handler voor dat bepaalde stuk bytecode. De uitvoering gaat dan verder bij de eerste handler die de juiste uitzondering behandelt. Hier zal dus EenUitzondering door instructies van byte 5 tot 10 worden behandeld; Exceptions daarentegen hebben de instructies van byte 11 tot 16 als handler. Indien het uitzonderingsobject een instantie is van een subklasse van java.lang.throwable, maar geen subklasse van java.lang.exception, dan zal er geen handler gevonden worden. De JVM zal de methode dan beëindigen, en de uitzondering verder naar de oproepende methode gooien. Indien de oproepende methodes ook geen handler voor deze uitzondering hebben, zal de uncaughtexception methode van de ThreadGroup aangeroepen worden, waarna de Thread beëindigd wordt. Voor de try-finally constructie gebruikt men de jsr (Jump to subroutine) en ret (return from subroutine) instructies. Een voorbeeldje maakt de constructie duidelijk. 0: ALOAD_0 1: INVOKEVIRTUAL 4: JSR 14 void finallyvoorbeeld(){ 7: RETURN try{ 8: ASTORE_1 eenmethode(); 9: JSR 14 } finally{ 12: ALOAD_1 handler(); 13: ATHROW } 14: ASTORE_2 } 15: ALOAD_0 16: INVOKEVIRTUAL 19: RET 2 De bijhorende exception table is als volgt: from to handler exception any 25

27 In de eerste situatie, waar geen uitzondering gegooid wordt door de opgeroepen methode, wordt vóór de return een jsr instructie ingevoegd. Deze zorgt ervoor dat de finally handler als een subroutine wordt aangeroepen. Wanneer die klaar is, zorgt de ret instructie dat de normale uitvoering vervolgd wordt. Voor situaties waar er wel een uitzondering gegooid wordt door de opgeroepen methode, wordt een extra exception handler voorzien die alle mogelijke uitzonderingen behandelt. Deze handler heeft als enige taak een jsr te maken naar de finally handler en bij terugkeer de oorspronkelijke uitzondering opnieuw te gooien. Om te kunnen bepalen waarheen moet teruggekeerd worden na de subroutine, plaats de jsr instructie een returnaddress op de operanden stapel. Dit returnaddress wordt door de subroutine in een lokale variabele bewaard; de ret instructie krijgt als argument de index mee waar het returnaddress te vinden is. In het geval van een try-catch-finally constructie wordt de situatie iets ingewikkelder, maar de toegepaste techniek blijft dezelfde Creatie en manipulatie van objecten Objecten worden aangemaakt door de new instructie. Deze instructie zorgt ervoor dat er geheugen in de objectenruimte gealloceerd wordt, en er een referentie naar het nieuwe object op de operanden stapel geplaatst wordt. Na het uitvoeren van de new instructie is het object nog niet bruikbaar; eerst moet nog een constructor worden aangeroepen. Nadien is het object geïnitialiseerd en volledig bruikbaar. Arrays worden ook als objecten beschouwd, maar de bijbehorende klassen worden door de JVM zelf gegenereerd. De instructies om een array aan te maken zijn verschillend van die van een normaal object: newarray, anewarray, en multianewarray. Tenslotte kunnen velden gemanipuleerd worden met volgende instructies: getfield, putfield, getstatic, en putstatic. De eerste twee instructies worden op niet-statische velden gebruikt, de laatste twee op statische velden. 3.4 Java en embedded systemen[3][12][19] We gaan hier even in op de voor- en nadelen van Java, voornamelijk in het licht van embedded systemen Voordelen van Java Java heeft verschillende interessante eigenschappen, zoals platform onafhankelijkheid, mogelijkheid tot veilige uitvoering van mobiele code, dynamisch 26

28 laden van klassen, ingebouwde ondersteuning voor threads en synchronisatie,... Hier willen we het voornamelijk hebben over die kenmerken die verband houden met de correcte werking van systemen. Correctheid en beveiliging zijn nauw met elkaar verbonden. Denken we in dit opzicht maar aan buffer overflows, die verantwoordelijk zijn voor een zeer groot percentage van de beveiligingsgaten in diverse systemen. Om een veilig systeem te ontwerpen, moeten we dus eerst een correcte werking garanderen. In de wereld van de embedded systemen is correctheid zo mogelijk nog belangrijker. Veel van de toepassingsgebieden van embedded systemen laten immers geen ruimte voor fouten, denken we hier maar aan de sturing van chemische processen of productielijnen. We overlopen nu even de kenmerken van Java die de correcte werking van programma s bevorderen. We noemen ze de beveiligingsgerelateerde kenmerken, omdat ze een onrechtstreekse invloed hebben op de beveiliging van een systeem. Eenvoud Een van de doelstellingen van Java is ontwikkeling en onderhoud van code eenvoudiger maken. Daartoe heeft men enkele van de mogelijkheden van C en C++, die vaak tot fouten leiden en code moeilijker te begrijpen maken, uit Java geweerd. Zo zijn templates, unions, structures, en operator overloading niet in Java terug te vinden. Pointers zijn dan weer vervangen door references. Deze maatregelen leiden samen tot eenvoudigere code, en bijgevolg tot minder programmeerfouten. Type safe Een taal is type-safe indien men op gegevens enkel die operaties kan toepassen, die voor dat type van gegevens bedoeld zijn. Het is eenvoudig in te zien dat dit de correcte werking van programma s bevordert. Eén manier om dit mogelijk te maken, is alle gegevens voorzien van een etiket met het datatype. Dit mechanisme wordt dynamische type controle genoemd, en heeft als nadeel dat het weinig efficiënt is. Java biedt type-safety via een ander mechanisme, namelijk statische type controle. Hierbij tracht men nog vóór uitvoering te bewijzen dat het programma enkel operaties zal uitvoeren op gegevens van het juiste type. Inefficiënte controles tijdens de uitvoering worden zo overbodig. Deze statische controle wordt door de verifier uitgevoerd als onderdeel van het laadproces van een klasse. 27

29 Objectgericht Java is intrinsiek een objectgerichte taal, waardoor het mogelijk is om gegevens enkel toegankelijk te maken via een goed gedefinieerde, publieke interface. Interne gegevens kunnen op deze manier privaat gehouden worden. Dit principe wordt data encapsulatie genoemd, en is een van de hoekstenen van de verder besproken Java beveiligingsarchitectuur. Data encapsulatie steunt op type-safety, vermits dit ervoor zorgt dat willekeurige toegang tot het geheugen onmogelijk is. Robuust Robuustheid heeft te maken met hoe goed een systeem reageert op fouten. Controleren of een rij niet buiten zijn grenzen wordt benaderd, is een voorbeeld van zo n maatregel die zorgt voor een robuuster systeem. Ook de aanwezigheid van een garbage collector draagt hiertoe bij, vermits het problemen gerelateerd met dangling pointers aanpakt. Merk op dat zowel de aangehaalde controle op rijen, als de garbage collector een performantiekost hebben. Bij het afwegen van robuustheid en performantie, heeft men dus resoluut voor het eerste gekozen. Geïntegreerde behandeling van uitzonderingen Uitzonderingen zorgen voor een elegante behandeling van fouten. Een programma krijgt de mogelijkheid om de situatie te corrigeren. Indien dit niet gebeurt, wordt de thread afgesloten en krijgt de gebruiker melding van de opgetreden fout. Strikt gedefinieerd In programmeertalen zoals C, zijn datatypes en bit-operaties, zoals verschuivingen, platform afhankelijk, waardoor werking en resultaten van een programma afhankelijk zijn van het onderliggende systeem. Java voorkomt deze onverwachte situaties door een strikte definitie van de datatypes en operaties op te leggen; de resultaten van een programma zullen dus onafhankelijk zijn van het systeem waarop gewerkt wordt Nadelen van Java Embedded systemen hebben vaak heel andere beperkingen en vereisten dan de normale PC omgeving waarop Java populair geworden is. Zo hebben embedded systemen in vele gevallen belangrijke restricties op het gebied van geheugen en beschikbare rekencapaciteit, en is real-time gegevensverwerking vaak een vereiste. We gaan hier na of Java aan deze beperkingen en vereisten voldoet. 28

30 Geheugenvereisten Om de geheugenvereisten van het Java platform te kennen, moeten we drie aspecten bekijken: de JVM, de API s en de applicaties. De vereisten van de JVM zijn afhankelijk van de instructieset van de onderliggende architectuur en het al dan niet aanwezig zijn van thread support in het bestuuringssysteem. Voor systemen uit de eerder besproken CLDC categorie zijn virtuele machines ontwikkeld met minimale geheugenvereisten. Dit gaat echter wel ten koste van de performantie, zo zullen deze virtuele machines meestal niet over een Just-in-time compiler beschikken. De vereiste statische geheugencapaciteit voor de standaard API is in de grootteorde van 10 megabyte. De meeste embedded systemen voldoen niet aan deze eis, vandaar de ontwikkeling van alternatieve API s, die enkel de strikt noodzakelijke functionaliteit bevatten. Tenslotte zijn er de geheugenvereisten voor applicaties. Hier maakt Java een goede beurt, Java programma s zijn namelijk vaak kleiner dan hun C en C++ tegenhangers. Een eerste reden kan gevonden worden in het compacte bytecode formaat, dat vaak kleinere programma s oplevert dan overeenkomstige machinecode. Ten tweede wordt dit ook bewerkstelligd door het dynamisch linken. Ter illustratie, een HelloWorld programma in Java neemt minder dan 1 kilobyte in, de C++ versie meer dan 100 kilobyte. Het gebruik van deze aangepaste JVM en API maken de geheugenvereisten voor embedded systemen heel wat realistischer. Reeds met een minimum van 128 kilobyte dynamisch geheugen beschikbaar, is het mogelijk om een beperkt Java platform te gebruiken. Performantie Buiten stringente geheugenbeperkingen, heeft een embedded systeem meestal ook geen overvloed aan rekencapaciteit. Enkele typische kenmerken van Java hebben daarenboven consequenties op de performantie. Zo is er bijvoorbeeld de platform onafhankelijkheid van Java. Vermits bytecode niet rechtstreeks kan uitgevoerd worden, moet die ofwel geïnterpreteerd ofwel vóór uitvoering naar machinecode omgezet worden. Terwijl de eerste Java versies nog bijna 40 maal trager waren dan overeenkomstige C++ programma s, heeft men ondertussen deze achterstand grotendeels weggewerkt. Technieken zoals Just-in-time compilers (JIT) zijn hier niet vreemd aan. Vanwege de grote geheugenvereisten die een JIT stelt, zijn deze niet of nauwelijks beschikbaar voor embedded systemen. Deze systemen kunnen dus niet profiteren van de grote performantiewinst die hiermee bereikt wordt. Ook andere kenmerken van Java hebben een negatieve invloed op de performantie. Denken we maar aan de overhead gegenereerd door de automatische garbage collector en bound checks. 29