Du point de vue de la machine virtuelle, un programme est une repr´ e-sentation structur´ee du code source ´ecrit par le programmeur. Pour Java Card, ce code source a suivi diverses phases, dont les plus importantes sont la compilation et la conversion (voir section 3.6.1). `A l’issue de ces phases restent les composantes essentielles du langage `a object qu’est Java Card: les types, les m´ethodes, les classes et les interfaces.
La figure 3.1 donne une vue synth´etique de la repr´esentation d’un pro-gramme.
Applette
Gestionnaires Code
d’exception Divers Méthodes
Interfaces Classes Divers
Fig. 3.1 –Organisation des applettes.
3.2.1 Le système de types
Comme la plupart des langages de programmation moderne,Java Card dispose d’un syst`eme de types afin d’assurer une utilisation correcte des valeurs. Java Card diff´erencie, comme Java, les types primitifs des types r´ef´erence.
Les types primitifs englobent les types arithm´etiques (Byte, Short et Int, qui se distinguent par la plage de valeurs possibles), le type des va-leurs bool´eennes (Boolean), le type des adresses de retour des sous-routines (ReturnAddress), et enfin le type Void des fonctions sans valeur de re-tour. Ces types se traduisent en Coqavec l’utilisation d’un type inductif :
Inductive type_prim : Set :=
Byte : type_prim | Short : type_prim |
Int : type_prim |
Boolean : type_prim | ReturnAddress : type_prim | Void : type_prim.
Les types r´ef´erence regroupent quant `a eux le type des instances de classe, des interfaces, des tableaux et des r´ef´erences nulles. Notons que l’on pr´ecise pour le type des instances de classe la classe `a laquelle on fait r´ef´erence (de mˆeme pour les interfaces) et pour le type des tableaux le type des ´el´ements du tableau. Le type des ´el´ements du tableau ´etant lui-mˆeme un type Java Card (primitif ou r´ef´erence), on est conduit `a d´efinir simultan´ement les types Java Card et les types r´ef´erence. On utilise alors la construction de types mutuellement inductifs deCoq:
Mutual Inductive type : Set :=
Prim : type_prim→type | Ref : type_ref→type with type_ref : Set :=
Ref_null : type_ref |
Ref_array : type →type_ref | Ref_instance : class_idx→type_ref | Ref_interface : interf_idx→type_ref.
Cette d´efinition des types, en particulier des types de tableaux, permet de contruire le type des tableaux dont les ´el´ements sont eux-mˆemes des tableaux alors que les tableaux de tableaux ne sont pas permis dans Java Card (ils le sont dans Java). N´eanmoins, il est facile de montrer (par une analyse statique du programme et de l’instruction de cr´eation de tableaux anewarray) qu’un tel type ne sera pas utilis´e.
3.2.2 Les méthodes
Une m´ethode est le nom donn´e aux fonctions d´efinies `a l’int´erieur d’une classe (voir 3.2.4). Une m´ethode est caract´eris´ee par son statut (statique ou non, constructeur ou non), sa signature (pour la v´erification du typage de ses arguments lors d’un appel de m´ethode), son nombre de variables locales (pour l’initialisation de son contexte d’ex´ecution), son code `a ex´ecuter (le code octet, sous forme de liste d’instructions), ses gestionnaires d’exception (pour la gestion dynamique des erreurs), sa taille maximum de pile d’op´ e-rande lors de son ex´ecution (pour contrˆoler les d´ebordements de pile) et enfin la classe `a laquelle elle appartient. On obtient alors l’enregistrement suivant :
Record Method : Set := { (∗ s t a t i c method or n ot ∗) statusstatic : bool;
(∗ i n i t method or n ot ∗) statusinit : bool;
(∗ s i g n a t u r e , p a i r o f domain / codomain ∗) signature : ((list type)*type);
(∗ number o f l o c a l v a r i a b l e s ∗)
local : nat;
(∗ i n s t r u c t i o n s t o be e x e c u t e d ∗) bytecode : (list Instruction);
(∗ e x c e p t i o n h a n d l e r s ∗)
handler_list : (list handler_type);
(∗ maximum operand s t a c k s i z e ∗)
m_max_opstack_size : class_idx;
(∗ owner c l a s s i n d e x ∗) owner : class_idx;
(∗ method i d e n t i f i c a t i o n ∗) method_id : method_idx }.
o`u class_idx correspond au type des index vers des classes dans le fichier capfile etmethod_idx`a celui des m´ethodes (ces index sont des entiers natu-rels). Le type handler_type est quant `a lui d´ecrit dans la section 3.5.3 sur le traitement des exceptions.
Enfin, le type Instruction ´enum`ere sous forme d’un type inductif, les diff´erents codes octet du langageJava Card avec leurs op´erandes :
Inductive Instruction : Set :=
nop : Instruction |
push : type_prim→Z→Instruction | ret : locvars_idx→Instruction | invokespecial : nat→method_idx→Instruction | invokestatic : nat→method_idx→Instruction |
getfield : type→instance_field_idx →Instruction | inc : type_prim→Z→nat →Instruction | ...
Certains codes octet du langages Java Card `a la s´emantique similaire ont
´et´e factoris´es. Par exemple, le code octet inc prend ici comme op´erande suppl´ementaire un type primitif et sert ainsi `a repr´esenter les codes octet iinc et sinc de Java Card (pour l’incr´ementation d’une variable locale de type Int et Short respectivement). De mˆeme, des codes octet comme
getfieldexistent normalement sous les formesgetfieldetgetfield_w qui correspondent `a des tailles diff´erentes d’index (_w pour wide) dans la zone des constantes, mais la r´esolution de celui-ci par le JCVM Tools (voir section 3.6.2) permet de n’en conserver qu’un seul.
On peut ainsi repr´esenter les 185 codes octet Java Card par seulement 44 codes octet dans notre formalisation.
3.2.3 Les interfaces
Les interfaces d´efinissent un ensemble de signatures nomm´ees de m´ e-thodes et de valeurs constantes. Elles servent principalement au d´ eveloppe-ment de librairies. Une classe peut impl´ementer une interface (´ eventuelle-ment plusieurs) si elle d´efinit un corps, sous forme de m´ethode, `a chacune des signatures de l’interface.
La plupart des informations sur les interfaces sont inutiles `a notre usage.
En effet, le v´erificateur de liens assure qu’une classe impl´emente correcte-ment une interface. Les renseignecorrecte-ments sur les m´ethodes impl´ement´ees sont int´egr´es directement dans le descripteur de classe. La seule information n´ e-cessaire sur les interfaces est la relation d’h´eritage entre ces derni`eres, pour v´erifier par exemple la compatibilit´e entre deux tableaux d’interfaces. On utilise la structure suivante pour repr´esenter les interfaces :
Record Interface : Set := { (∗ s u p e r i n t e r f a c e s ∗)
super_int : (list interf_idx);
(∗ i n t e r f a c e i d e n t i f i c a t i o n ∗) int_id : interf_idx
}.
o`u interf_idx correspond au type des index vers des interfaces du fichier capfile. Ces index sont des entiers naturels.
Parmi les interfaces Java Card, l’interface Shareable, joue un rˆole particulier dans le syst`eme de s´ecurit´e Java Card (voir section 2.2.3).
3.2.4 Les classes
Les classes d´ecrivent dans les langages `a objet les caract´eristiques d’ob-jets par un ensemble de donn´ees et le moyen, au travers de m´ethodes, de les manipuler. De plus, les classes traduisent avec les notions d’h´eritage et d’interface les relations entre objets.
Dans notre repr´esentation, une classe est naturellement d´ecrite par le type de ses variables, par l’ensemble des classes dont elle h´erite – ses super-classes –, par les m´ethodes qu’elle contient (dont ses constructeurs), par les interfaces qu’elle impl´emente et par le paquettage (voir ci-dessous) auquel elle appartient. Enfin, on garde trace de l’identifiant de la classe dans notre repr´esentation finale du programme. Formellement, enCoq, cela conduit `a la repr´esentation suivante, sous forme d’enregistrement :
Record Class : Set := { (∗ s u p e r c l a s s e s ∗)
super : (list class_idx);
(∗ p u b l i c methods ∗)
public_methods : (list method_idx);
(∗ p a c k a g e methods ∗)
package_methods : (list method_idx);
(∗ implemented i n t e r f a c e s and c o r r e s p o n d i n g implemented methods ∗) int_methods : (list interf_idx*(list class_pbmethod_idx));
(∗ l i s t o f c l a s s v a r i a b l e s ∗) class_var : (list type);
(∗ owner p a c k a g e ∗)
package : Package;
(∗ c l a s s i d e n t i f i c a t i o n ∗) class_id : class_idx }.
o`uclass_pbmethod_idxcorrespond au type des index du contenu du champ
public_methods (les m´ethodes impl´ementant une interface sont d´eclar´ees publiques).
Notons que le champsuper, qui est une liste, rassemble non pas la classe dont la classe consid´er´ee h´erite directement (puisqu’en Java il n’y a pas d’h´eritage multiple) mais la fermeture transitive de la relation d’h´eritage. Par convention, la super-classe imm´ediate se trouve en premi`ere position dans la liste et celle-ci existe toujours : il s’agit par d´efaut dejava.lang.Object.
Cette repr´esentation a ´et´e choisie pour ´eviter d’avoir `a d´efinir des fonctions par r´ecurrence bien-fond´ee sur la relation de sous-typage.
Notons aussi que l’on distingue parmi les m´ethodes celles marqu´ees avec les attributs public ou protected de celles marqu´ees avec les attributs
packageou private et que cette distinction est d´ej`a pr´esente dans le fichier capfile.
Enfin, le type Package est un identifiant unique de paquettage, c’est-` a-dire dans la terminologie Java un ensemble de classes et d’interfaces for-mant un programme. Puisque plusieurs paquettages peuvent cohabiter sur la mˆeme carte `a puce, l’identifiant est utile pour le contrˆole d’acc`es aux classes, champs statiques et m´ethodes statiques. Pour des raisons de s´ ecu-rit´e, chaque classe appartient donc `a un seul paquettage. L’identifiant de paquettage est appel´e Applet IDentifier (AID).
3.2.5 Les programmes
Notre mod`ele de programmes ne poss`ede pas de zone des constantes, contrairement `a la repr´esentation d’un fichiercapfile. On suppose les phases de liaison d´ej`a effectu´ees (par le JCVM Tools, voir section 3.6.2). Ainsi, la d´efinition d’un programme Java Card pour notre formalisation se limite quasi exclusivement `a une collection de classes, d’interfaces et de m´ethodes :
Record jcprogram : Set := { classes : (list Class);
methods : (list Method);
interfaces : (list Interface);
sheap_type : (list type)
}.
On remarquera simplement l’ajout le champsheap_typequi d´etaille les types des valeurs statiques du programmes et qui servira lors de l’initialisation du programme.
Dans cette repr´esentation de programme, toutes les classes n´ecessaires `a l’ex´ecution sont incluses (il n’y a pas de chargement dynamique de classes en Java Card). En particulier, on y retrouve par d´efaut les interfaces et classes du paquettagejava.lang.