Moniteur de SDA

CREATE_NOTEPAD : MAX_MESSAGE_SIZE

— Nombre de ports de communication :Pour cette vérification, il suffit de

compter le nombre d’utilisation des services CREATE_SAMPLING_PORT

etCREATE_QUEUING_PORT.

CREATE_SAMPLING_PORT : 1 CREATE_QUEUING_PORT : 1

— Services spécifiques :Dans ce cas particulier, l’outil utilise une liste

corres-pondant aux services spécifiques autorisés, et affiche l’ensemble des services utilisés n’étant pas dans la liste.

4.1.2.3 Limitations

Cet outil n’a été évalué que sur un seul cas d’étude, et n’a pas été évalué en cas de binaire malveillant. Il reste donc très limité, mais propose une réflexion sur la réutilisation des documents déjà disponibles lors du développement d’une appli-cation avionique afin de réaliser des vérifiappli-cations statiques relatives à la sécurité, comme la vérification de l’usage correct des ressources par le binaire de l’applica-tion, au regard des ressources déclarées dans le contrat d’insertion. Cette étude n’a pas été poussée plus loin, le coeur de ces travaux étant plus focalisé sur la suite de l’approche (Définition du SDA et mise en place de la partie embarquée).

4.1.3 Moniteur de SDA

Le moniteur de SDA est utilisé pour surveiller l’exécution de l’application et collecter les données correspondantes. Ce moniteur est développé à l’aide de l’outil dedebugGDB, qui permet un accès sans restriction aux informations du calculateur, tout en conservant une exécution temps-réel locale dans le calculateur. Concernant le niveau d’observation, le choix s’est porté sur les appels API ARINC 653 effectués

par l’application. A chaque appel effectué, le type de l’appel et son horodatage sont enregistrés. Deux versions de ce moniteur ont été développées au cours des travaux : 1. Utilisation du debugger : seul le debugger est utilisé pour enregistrer les

in-formations choisies.

2. Insertion d’un code d’instrumentation : un code d’instrumentation est utilisé pour enregistrer en temps-réel les données d’observation dans une zone mé-moire dédiée, et le debugger n’est utilisé que pour enregistrer ces données sur le contrôleur, après chaque slot d’exécution de l’application sous surveillance. Dans les deux cas, les données sont enregistrées dans un fichier de log sur le contrôleur au format suivant :

12, 4003 14, 4451 1, 4808 7, 5133 8, 6107 ...

La première colonne correspond à un identifiant relatif au type d’appel API utilisé. La deuxième colonne indique la valeur de l’horloge interne du RTOS, indiquée par le registre TBL.

4.1.3.1 Version 1 : Utilisation dudebugger

La première version du moniteur consiste à placer des points d’arrêt dans le code de chaque appel API à surveiller. Dès que le point d’arrêt est atteint, l’infor-mation correspondante est écrite dans le fichier de log courant. Ces points d’arrêt sont placés à l’aide d’un script de debug ou script DBG. L’extrait de code suivant correspond à la partie du script DBG permettant de placer un point d’arrêt à l’ap-pelCREATE_PROCESS et à enregistrer les informations voulues (type de l’appel, représenté ici par le numéro 1, et horodatage, contenu dans le registre tbl) :

b CREATE_PROCESS commands silent printf "1,%i\n", $tbl c end

Cette première version permet une grande souplesse dans le choix des informations à enregistrer. En particulier, cette version est intéressante pour tester rapidement différents choix de données à observer. Cependant, chaque point d’arrêt introduit un retard dû à l’échange d’information entre la cible et le contrôleur. Sur nos cas d’étude, l’observation de 20 secondes d’exécution de l’application prenait au final

4.1. Implémentation de l’approche 75

Figure 4.3 – Structure du code d’une application et insertion du code d’instru-mentation

presque 30 minutes dû à l’accumulation de ces retards. La version suivante pro-pose de réduire le nombre de points d’arrêt pour réduire cet écart entre la durée d’exécution sur le calculateur et la durée réelle de l’observation.

4.1.3.2 Version 2 : Insertion d’un code d’instrumentation

Dans la deuxième version, un code d’instrumentation est inséré directement dans le code de l’application. L’insertion de ce code est effectuée à l’initialisation du calculateur, via une commande GDB. Ce code est inséré directement dans la librairie d’appels API attachée à la partition surveillée. Plus précisément, chaque appel fait appel à un morceau de code commun, qui s’occupe ensuite d’appeler l’OS. La Figure 4.3 présente la structure du binaire de l’application, composé de son code applicatif (en gris), de la librairie API ARINC 653 (en bleu), et du code commun d’appel à l’OS (en jaune).

C’est dans cette fonction commune qu’est inséré le code d’instrumentation dé-crit par le Listing 4.1. Pour insérer ce morceau de code supplémentaire, l’instruction à l’adresse 0x50001000 est écrasée par un saut vers une zone de code non utilisée (ici, à l’adresse 0x10000000). Le code d’instrumentation est placé à cette adresse (0x10000000), et se termine par l’exécution de l’instruction écrasée (ici, l’instruc-tion mflr r12), puis un saut vers l’instruction normale suivante, ici à l’adresse 0x50001004.

Le code additionnel d’instrumentation vérifie dans un premier temps si l’appel est dans la liste des appels exclus. C’est le cas des appelsLOCK_PREEMPTION,

UNLOCK_PREEMPTION et TIMED_WAIT, qui étaient appelés extrèmement souvent et engendraient donc une grande quantité de données. Ensuite, le code écrit dans une zone mémoire dédiée la valeur du registre R4, qui est utilisé comme identifiant de l’appel API, et la valeur du registreTBL, qui donne la valeur d’hor-loge interne du calculateur. Cette zone mémoire est composée de deux pointeurs

# Exclusion de certains appels API selon leur identifiant 0x10000000: cmpwi r4,3 0x10000004: beq- 0x10000064 0x10000008: cmpwi r4,12 0x1000000c: beq- 0x10000064 0x10000010: cmpwi r4,13 0x10000014: beq- 0x10000064 0x10000018: cmpwi r4,15 0x1000001c: beq- 0x10000064

# Sauvegarde des valeurs des registres R5 et R6 0x10000020: stwu r5,-4(r1)

0x10000024: stwu r6,-4(r1)

# Récupération du pointeur de logs courant, enregistré à l'adresse 0x18000004

,→

0x10000028: li r5,4 0x1000002c: addis r5,r5,6144 0x10000030: lwz r5,0(r5)

# Enregistrement de l'identifiant de l'appel, donné par le registre R4 0x10000034: stw r4,0(r5) 0x10000038: addi r5,r5,4 # Enregistrement de l'horodatage 0x1000003c: mftb r6 0x10000040: stw r6,0(r5) 0x10000044: addi r5,r5,4 # Mise à jour du pointeur de logs 0x10000048: li r6,4 0x1000004c: addis r6,r6,6144 0x10000050: stw r5,0(r6) # Restauration des registres R5 et R6 0x10000054: lwz r6,0(r1) 0x10000058: addi r1,r1,4 0x1000005c: lwz r5,0(r1) 0x10000060: addi r1,r1,4

# Exécution de l'instruction écrasée par le saut vers le code d'instrumentation

,→

0x10000064: mflr r12

0x10000068: b 0x50001004 <SYSCALL+4>

4.1. Implémentation de l’approche 77

représentant la première et la dernière case remplie de la fenêtre de logs, et d’une fenêtre de logs.

L’enregistrement des logs dans un fichier sur le contrôleur est effectué à l’aide d’un script DBG. Un point d’arrêt est placé au moment où l’OS reprend la main après le slot d’exécution de l’application surveillée. Le script parcourt ensuite la fenêtre de logs, d’après les valeurs des pointeurs de début et de fin, pour enregistrer chaque log dans le fichier de données sur le contrôleur. Il réinitialise ensuite la fenêtre de logs pour le prochain slot d’exécution.