FR3121242A1 - Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé - Google Patents

Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé Download PDF

Info

Publication number
FR3121242A1
FR3121242A1 FR2103046A FR2103046A FR3121242A1 FR 3121242 A1 FR3121242 A1 FR 3121242A1 FR 2103046 A FR2103046 A FR 2103046A FR 2103046 A FR2103046 A FR 2103046A FR 3121242 A1 FR3121242 A1 FR 3121242A1
Authority
FR
France
Prior art keywords
instructions
instruction
critical
critical chain
chain
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2103046A
Other languages
English (en)
Other versions
FR3121242B1 (fr
Inventor
Mihail ASAVOAE
Mathieu Jan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Priority to FR2103046A priority Critical patent/FR3121242B1/fr
Priority to US17/655,243 priority patent/US20220308885A1/en
Priority to EP22163858.8A priority patent/EP4064087A1/fr
Publication of FR3121242A1 publication Critical patent/FR3121242A1/fr
Application granted granted Critical
Publication of FR3121242B1 publication Critical patent/FR3121242B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3838Dependency mechanisms, e.g. register scoreboarding
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/556Detecting local intrusion or implementing counter-measures involving covert channels, i.e. data leakage between processes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs
    • G06F11/3608Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/554Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577Assessing vulnerabilities and evaluating computer system security
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3893Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled in tandem, e.g. multiplier-accumulator
    • G06F9/3895Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled in tandem, e.g. multiplier-accumulator for complex operations, e.g. multidimensional or interleaved address generators, macros
    • G06F9/3897Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled in tandem, e.g. multiplier-accumulator for complex operations, e.g. multidimensional or interleaved address generators, macros with adaptable data path

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé Ce procédé de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, le code exécutable comportant une séquence d’instructions logicielles, est mis en œuvre par un dispositif électronique et comprend : - acquisition de la séquence d’instructions logicielles ; - génération, à partir de la séquence d’instructions, d’une première structure de modélisation d’un chemin d’exécution de la séquence, la première structure comportant une pluralité de premiers groupes de données, chacun associé à une instruction respective et comportant des identifiants d’une instruction précédente et d’une instruction suivante ; - calcul d’une deuxième structure de modélisation d’un fonctionnement de la séquence, la deuxième structure comportant une pluralité de deuxièmes groupes de données, chacun associé à une instruction respective et comportant un indicateur d’appartenance éventuelle à une chaîne critique, et le cas échéant, un identifiant d’une instruction initiale de ladite chaine critique ; la deuxième structure étant créée en parcourant les premiers groupes ; une chaîne critique correspondant à des instructions d’une même fonction logicielle et étant calculée en résolvant un problème de sous-graphes avec contraintes sur le degré, chaque chaîne critique correspondant à un sous-graphe, le nombre d’instructions incluses dans chaque chaîne critique étant inférieur à un nombre prédéfini, et un paramètre d’optimisation étant le nombre de relations entre les instructions de la chaîne critique respective, ledit nombre de relations correspondant à un nombre d’arcs dans le sous-graphe ; et - recherche d’anomalie(s) temporelle(s) à partir de chaîne(s) critique(s) déterminée(s) via la deuxième structure.

Description

Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé
La présente invention concerne un procédé de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, le code exécutable comportant une séquence d’instructions logicielles, le procédé étant mis en œuvre par un dispositif électronique de surveillance.
L’invention concerne aussi un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un tel procédé de surveillance.
L’invention concerne également un tel dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique.
L’invention concerne le domaine de la surveillance de codes exécutables comportant des séquences d’instructions logicielles aptes à être exécutés sur des plateformes informatiques, en particulier la surveillance de l’exécution de séquences d’instructions exprimées en langage machine, directement interprétables par la plateforme informatique.
L’article “Formal Executable Models for Automatic Detection of Timing Anomalies” de M. Asavoae, B. Ben Hedia et M. Jan, WCET 2018, enseigne qu’une anomalie temporelle (de l’anglaistiming anomaly) d’une séquence d’instructions est un comportement temporel contre-intuitif de cette séquence dans le sens où une exécution rapide locale ralentit une exécution globale. La présence de tels comportements est gênante pour une analyse de temps d’exécution de pire cas, ou analyse WCET (de l’anglaisWorst Case Execution Time), qui nécessite une certaine monotonie dans l’ordre d’exécution des instructions, pour pouvoir calculer ensuite des valeurs limites sûres.
Cependant, cet article n’enseigne pas comment détecter automatiquement des anomalies temporelles dans des conceptions d'architecture informatique données, en particulier dans des séquences données d’instructions en langage machine.
Le but de l’invention est alors de proposer un procédé, et un dispositif électronique associé, de surveillance d’un code exécutable comportant une séquence d’instructions logicielles, apte à être exécuté sur une plateforme informatique, permettant de détecter automatiquement des anomalies temporelles.
A cet effet, l’invention a pour objet un procédé de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, le code exécutable comportant une séquence d’instructions logicielles, le procédé étant mis en œuvre par un dispositif électronique de surveillance et comprenant les étapes suivantes :
- acquisition de la séquence d’instructions logicielles ;
- génération d’une première structure de modélisation d’un chemin d’exécution de la séquence d’instructions, la première structure étant générée à partir de la séquence d’instructions et comportant une pluralité de premiers groupes de données, chacun associé à une instruction logicielle respective ; chaque premier groupe comportant un identifiant d’une instruction précédente et un identifiant d’une instruction suivante ;
- calcul d’une deuxième structure de modélisation d’un fonctionnement de la séquence d’instructions, la deuxième structure comportant une pluralité de deuxièmes groupes de données, chacun associé à une instruction logicielle respective ; chaque deuxième groupe comportant un indicateur d’appartenance éventuelle à une chaîne critique d’instructions, et en cas d’appartenance à une chaîne critique respective, un identifiant d’une instruction initiale de ladite chaine critique ; la deuxième structure étant créée à partir de la première structure, en parcourant successivement les premiers groupes de la première structure ; une chaîne critique respective correspondant à des instructions d’une même fonction logicielle et étant calculée en résolvant un problème de sous-graphes avec contraintes sur le degré, chaque chaîne critique correspondant à un sous-graphe, le nombre d’instructions incluses dans chaque chaîne critique étant inférieur ou égal à un nombre maximal prédéfini, et un paramètre d’optimisation étant le nombre de relations entre les instructions de la chaîne critique respective, ledit nombre de relations correspondant à un nombre d’arcs dans le sous-graphe associé ; et
- recherche d’anomalie(s) temporelle(s) à partir de chaîne(s) critique(s) d’instructions déterminée(s) via la deuxième structure de modélisation.
Suivant d’autres aspects avantageux de l’invention, le procédé de surveillance comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles :
- lors de l’étape de calcul, pour chaque instruction logicielle appartenant à une chaîne critique respective, chaque deuxième groupe comporte en outre un champ de pré-contexte et un champ de post-contexte ; le champ de pré-contexte incluant l’identifiant de chaque instruction précédant l’instruction associée audit deuxième groupe et n’appartenant pas à la chaine critique dont fait partie ladite instruction, et le champ de post-contexte incluant l’identifiant de chaque instruction succédant à l’instruction associée audit deuxième groupe et n’appartenant pas à la chaine critique dont fait partie ladite instruction ;
- lors de l’étape de calcul, un champ d’étendue est ajouté pour chaque chaîne critique d’instructions respective dans la deuxième structure de modélisation, le champ d’étendue incluant un nombre d’accès mémoire de la part de l’ensemble des instructions de ladite chaîne critique ;
- lors de l’étape de calcul, une variable de pré-contexte et une variable de post-contexte sont ajoutées pour chaque chaîne critique d’instructions respective dans la deuxième structure de modélisation, la variable de pré-contexte étant égale à l’identifiant le plus fréquent parmi les identifiants d’instruction contenus dans les champs de pré-contexte pour ladite chaîne critique, et la variable de post-contexte étant égale à l’identifiant le plus fréquent parmi les identifiants d’instruction contenus dans les champs de post-contexte pour ladite chaîne critique ;
- chaque premier groupe comporte en outre une quantification temporelle d’une exécution de l’instruction logicielle respective, et chaque deuxième groupe comporte en outre au moins une quantification temporelle d’un chemin d’exécution de la séquence jusqu’à ladite instruction respective ;
la quantification temporelle de l’exécution de l’instruction logicielle respective étant de préférence un nombre de cycles d’horloge pour ladite exécution.
- chaque quantification temporelle d’un chemin d’exécution jusqu’à l’instruction logicielle respective est calculée à partir du champ de pré-contexte pour ladite instruction et des quantifications temporelles d’exécution pour ladite instruction respective et pour les instructions identifiées dans le champ de pré-contexte ;
- le procédé comprend en outre une étape de propagation de données de quantification temporelle d’une chaine critique précédente d’instructions à une chaine critique courante d’instructions, les quantifications temporelles associées à la chaine critique courante étant déterminées à partir de celles associées à la chaine critique précédente ;
- lors de l’étape de recherche, une anomalie temporelle est détectée en cas d’incohérence entre les quantifications temporelles associées à la chaine critique courante et celles associées à la chaine critique précédente ;
- une première quantification temporelle incluse dans le deuxième groupe est une quantification temporelle d’un plus court chemin d’exécution entre une instruction initiale de la séquence et l’instruction respective ; et une deuxième quantification temporelle incluse dans le deuxième groupe est une quantification temporelle d’un plus long chemin d’exécution entre ladite instruction initiale et l’instruction respective ;
- la plateforme informatique comporte plusieurs unités d’exécution d’instruction(s), et chaque premier groupe comporte en outre un identifiant de l’unité d’exécution associée à l’instruction logicielle respective ;
- chaque premier groupe comporte en outre une information d’éventuelle dépendance avec d’autres instructions, telle qu’un identifiant de registre commun avec lesdites autres instructions et/ou un identifiant de zone mémoire commune avec lesdites autres instructions ; et
- la séquence d’instructions logicielles est une séquence d’instructions exprimées en langage machine, directement interprétables par la plateforme informatique.
L’invention a aussi pour objet un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé de surveillance tel que défini ci-dessus.
L’invention a également pour objet un dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, le code exécutable comportant une séquence d’instructions logicielles, le dispositif comprenant :
- un module d’acquisition configuré pour acquérir la séquence d’instructions logicielles ;
- un module de génération configuré pour générer une première structure de modélisation d’un chemin d’exécution de la séquence d’instructions, la première structure étant générée à partir de la séquence d’instructions et comportant une pluralité de premiers groupes de données, chacun associé à une instruction logicielle respective ; chaque premier groupe comportant un identifiant d’une instruction précédente et un identifiant d’une instruction suivante ;
- un module de calcul configuré pour calculer une deuxième structure de modélisation d’un fonctionnement de la séquence d’instructions, la deuxième structure comportant une pluralité de deuxièmes groupes de données, chacun associé à une instruction logicielle respective ; chaque deuxième groupe comportant un indicateur d’appartenance éventuelle à une chaîne critique d’instructions, et en cas d’appartenance à une chaîne critique respective, un identifiant d’une instruction initiale de ladite chaine critique ; la deuxième structure étant créée à partir de la première structure, en parcourant successivement les premiers groupes de la première structure ; une chaîne critique respective correspondant à des instructions d’une même fonction logicielle et étant calculée en résolvant un problème de sous-graphes avec contraintes sur le degré, chaque chaîne critique correspondant à un sous-graphe, le nombre d’instructions incluses dans chaque chaîne critique étant inférieur ou égal à un nombre maximal prédéfini, et un paramètre d’optimisation étant le nombre de relations entre les instructions de la chaîne critique respective, ledit nombre de relations correspondant à un nombre d’arcs dans le sous-graphe associé ; et
- un module de recherche configuré pour rechercher une ou plusieurs anomalie(s) temporelle(s) à partir de chaîne(s) critique(s) d’instructions déterminée(s) via la deuxième structure de modélisation.
Ces caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels :
la est une représentation schématique d’une plateforme informatique apte à exécuter un code exécutable, et un dispositif électronique de surveillance dudit code exécutable ;
la est une illustration d’un exemple d’un graphe acyclique orienté représentant une séquence d’instructions logicielles formant le code exécutable surveillé par le dispositif de surveillance de la ;
la est une représentation schématique d’une propagation de données de quantification temporelle d’une chaine critique d’instructions à la suivante ;
la est une représentation schématique de quatre chronogrammes d’exécution d’une séquence de quatre instructions A à D, lors de différentes exécutions par la plateforme de la , comportant deux unités d’exécution en parallèle, le quatrième chronogramme correspondant à une anomalie temporelle ; et
la est un organigramme d’un procédé selon l’invention de surveillance d’un code exécutable comportant une séquence d’instructions logicielles, le procédé étant mis en œuvre par le dispositif électronique de surveillance de la .
Sur la , un dispositif électronique de surveillance 30 est configuré pour surveiller un code exécutable 32 apte à être exécuté sur une plateforme informatique 34, le code exécutable 32 comportant une séquence d’instructions logicielles.
Le dispositif électronique de surveillance 30 comprend un module 40 d’acquisition de la séquence d’instructions logicielles formant le code exécutable 32 à surveiller ; un module 42 de génération d’une première structure de modélisation d’un chemin d’exécution de la séquence d’instructions ; un module 44 de calcul d’une deuxième structure de modélisation d’un fonctionnement de la séquence d’instructions ; et un module 46 de recherche d’une ou plusieurs anomalies temporelles à partir de chaine(s) critique(s) d’instructions déterminée(s) via la deuxième structure de modélisation.
En complément facultatif, le dispositif électronique de surveillance 30 comprend un module 48 de propagation de données de quantification temporelle d’une chaine critique d’instructions à la suivante.
Dans l’exemple de la , le dispositif électronique de surveillance 30 comprend une unité de traitement d’informations 50 formée par exemple d’une mémoire 52 et d’un processeur 54 associé à la mémoire 52.
Le code exécutable 32 comporte la séquence d’instructions logicielles, et la séquence d’instructions logicielles est par exemple une séquence d’instructions exprimées en langage machine, directement interprétables par la plateforme informatique 34.
La plateforme informatique 34 comporte typiquement plusieurs unités d’exécution d’instructions, telles qu’une première unité d’exécution d’instructions, également appelée première unité fonctionnelle FU1, et une deuxième unité d’exécution d’instructions, également appelée deuxième unité fonctionnelle FU2.
Dans l’exemple de la , la plateforme informatique 34 présente une architecture en pipeline, ou encore en cascade. Dans cet exemple de la , la plateforme informatique 34 comporte six étages successifs ; à savoir un premier étage de lecture d’instructions IF (de l’anglais Instruction Fetch) ; un deuxième étage de décodage et ré-ordonnancement d’instructions DR (de l’anglais Decode Reorder) connecté en sortie du premier étage de lecture d’instructions IF ; un troisième étage de registre d’instructions IR (de l’anglais Instruction Register), connecté en sortie du deuxième étage DR ; un quatrième étage d’exécution d’instructions FU (de l’anglais Functional Unit), comportant les première et deuxième unités fonctionnelles FU1, FU2 et connecté en sortie du troisième étage de registre d’instructions IR ; un cinquième étage d’accès à la mémoire MEM (de l’anglais MEMory access), cet étage étant utile seulement pour l’exécution d’instructions de chargement et de rangement, et étant par exemple connecté seulement en sortie de la deuxième unité fonctionnelle FU2 dans l’exemple de la ; et un sixième étage de rangement du résultat WB (de l’anglais Write Back), le sixième étage étant connecté en sortie d’une part de la première unité fonctionnelle FU1, et d’autre part du cinquième étage d’accès à la mémoire MEM, lui-même connecté en sortie de la deuxième unité fonctionnelle FU2.
Le premier étage de lecture d’instructions IF est connu en soi, et est propre à recevoir, puis à lire successivement chacune des instructions de la séquence d’instructions formant le code exécutable 32 destiné à être exécuté par la plateforme informatique 34.
Le deuxième étage de décodage et ré-ordonnancement DR est également connu en soi, et est apte à préparer les arguments de l’instruction en vue de l’exécution ultérieure de l’instruction par l’une des unités fonctionnelles FU1, FU2.
Le troisième étage de registre d’instructions IR comporte typiquement un registre d’instructions pour chaque unité fonctionnelle du quatrième étage d’exécution .Dans l’exemple de la , le troisième étage IR comporte alors deux registres d’instructions, à savoir un premier registre d’instructions IR1 associé à la première unité d’exécution FU1 et connecté en entrée de celle-ci, et un deuxième registre d’instructions IR2 associé à la deuxième unité d’exécution d’instructions FU2 et connecté en entrée de celle-ci.
La première unité d’exécution FU1 est typiquement adaptée pour exécuter des instructions arithmétique et logique, également appelées instructions ALU (de l’anglaisArithmetical and Logical Unit), ou encore des instructions de branchement et de saut (de l’anglaisbranchetjump), et la deuxième unité d’exécution FU2 est par exemple adaptée pour exécuter des instructions de chargement et de rangement (de l’anglaisloadetstore), la deuxième unité d’exécution FU2 étant alors reliée à cet effet en entrée de l’étage d’accès à la mémoire MEM.
L’étage d’accès à la mémoire MEM est seulement utile pour les instructions de chargement et de rangement, et comme connu en soi permet de lire dans le registre concerné la valeur à ranger dans le cas d’une instruction de rangement, ou encore de mettre dans le registre concerné la valeur lue en mémoire dans le cas d’une instruction de chargement.
L’étage de rangement du résultat WB est enfin adapté pour ranger, dans le registre de destination, le résultat de l’exécution de l’instruction logicielle correspondante, par exemple pour ranger le résultat d’opérations arithmétiques et logiques effectuées par la première unité d’exécution FU1, ou encore pour ranger dans le registre de destination la valeur lue en mémoire par les instructions de chargement, ou encore une nouvelle adresse dans le cas d’instructions de branchement.
La séquence d’instructions logicielles est une succession d’instructions logicielles aptes à être exécutées successivement par la plateforme informatique 34. Dans l’exemple de la , la séquence d’instructions logicielles comporte vingt-deux instructions logicielles numérotées de 1 à 22, les instructions logicielles aptes à être exécutées par la première unité d’exécution FU1 étant représentées de manière circulaire, et les instructions logicielles aptes à être exécutées par la deuxième unité d’exécution FU2 étant représentées de manière rectangulaire. Les instructions aptes à être exécutées par la première unité d’exécution FU1 sont typiquement des instructions de type ALU, représentées sous forme d’un cercle à la , ou encore des instructions de branchement et de saut, représentées sous la forme d’un cercle entrecoupé d’un arc de cercle en partie inférieure droite sur la . Les instructions logicielles aptes à être exécutées par la deuxième unité d’exécution FU2 sont typiquement des instructions d’accès mémoire, telles que des instructions de chargement et de rangement, représentées sous la forme d’un rectangle à la .
Les instructions logicielles représentées à la correspondent alors par exemple aux instructions listées ci-après.
  1. jr ra FU1
  2. jal ra, -56 FU1
  3. addi sp, -32 FU1
  4. sdsp ra, 24(sp) FU2
  5. sdsp s0, 16(sp) FU2
  6. addi4spn s0, sp, 32 FU1
  7. sw zero -20(s0) FU2
  8. jal ra, -256 FU1
  9. addi sp, -32 FU1
  10. sdsp s0, 23(sp) FU2
  11. addi4spn s0, sp, 32 FU1
  12. sw zero, -20(s0) FU2
  13. li a5, -1 FU1
  14. sw a5, -24(s0) FU2
  15. li a5. -1 FU1
  16. sw a5, -28(s0) FU2
  17. j 62 FU1
  18. lw a5, -24(s0) FU2
  19. addiw a5, 0 FU1
  20. bnez a5, -66 FU1
  21. lw a4, -20(s0) FU2
  22. slli a4, 2 FU1
L’homme du métier observera que les instructions listées ci-dessus sont alors des instructions exprimées en langage machine, directement interprétables par la plateforme informatique 34. Les instructions listées ci-dessus sont en l’occurrence et comme connu en soi des instructions de type RISC-V.
L’homme du métier observera que dans l’exemple ci-dessus, les instructions jr, jal, j et bnez sont des instructions de branchement et de saut, aptes à être exécutées par la première unité d’exécution FU1 ; les instructions addi, li, addiw, slli et addi4spn sont des instructions de type ALU, aptes à être exécutées par la première unité d’exécution FU1 ; et que les instructions sdsp, sw et lw sont des instructions de chargement ou de rangement, aptes à être exécutées par la deuxième unité d’exécution FU2.
Dans l’exemple de la , les relations entre instructions logicielles sont représentées sous forme de flèches, ou encore sous forme d’arcs orientés, étant observé que les relations entre deux instructions logicielles successives ne sont pas nécessairement représentées par souci de simplification du dessin.
Dans l’exemple de la , le module d’acquisition 40, le module de génération 42, le module de calcul 44 et le module de recherche 46, ainsi qu’en complément facultatif le module de propagation 48, sont réalisés chacun sous la forme d’un logiciel, d’une brique logicielle, exécutables par le processeur 54. La mémoire 52 du dispositif électronique de surveillance 30 est alors apte à stocker un logiciel d’acquisition de la séquence d’instructions logicielles formant le code exécutable à surveiller ; un logiciel de génération de la première structure de modélisation du chemin d’exécution de la séquence d’instructions ; un logiciel de calcul de la deuxième structure de modélisation du fonctionnement de la séquence d’instructions ; et un logiciel de recherche d’anomalie(s) temporelle(s) à partir de chaine(s) critique(s) d’instructions déterminée(s) via la deuxième structure de modélisation. En complément facultatif, la mémoire 52 du dispositif électronique de surveillance 30 est apte à stocker un logiciel de propagation de données de quantification temporelle d’une chaine critique respective d’instructions à la suivante. Le processeur 54 est alors apte à exécuter chacun des logiciels parmi le logiciel d’acquisition, le logiciel de génération, le logiciel de calcul et le logiciel de recherche, ainsi qu’en complément facultatif le logiciel de propagation.
En variante non représentée, le module d’acquisition 40, le module de génération 42, le module de calcul 44 et le module de recherche 46, ainsi qu’en complément facultatif le module de propagation 48, sont réalisés chacun sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglaisField Programmable Gate Array), ou encore d’un circuit intégré, tel qu’un ASIC (de l’anglaisApplication Specific Integrated Circuit).
Lorsque le dispositif électronique de surveillance 30 est réalisé sous forme d’un ou plusieurs logiciels, c’est-à-dire sous forme d’un programme d’ordinateur, également appelé produit programme d’ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est par exemple un medium apte à mémoriser des instructions électroniques et à être couplé à un bus d’un système informatique. A titre d’exemple, le support lisible est un disque optique, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non-volatile (par exemple EPROM, EEPROM, FLASH, NVRAM), une carte magnétique ou une carte optique. Sur le support lisible est alors mémorisé un programme d’ordinateur comprenant des instructions logicielles.
Le module d’acquisition 40 est configuré pour acquérir la séquence d’instructions logicielles formant le code exécutable 32. La séquence d’instructions logicielles acquise est typiquement une séquence d’instructions exprimées en langage machine, directement interprétables par la plateforme informatique 34.
Le module de génération 42 est configuré pour générer la première structure de modélisation du chemin d’exécution de la séquence d’instructions, la première structure étant générée à partir de la séquence d’instructions acquise par le module d’acquisition 40 et comportant une pluralité de premiers groupes de données, chacun étant associé à une instruction logicielle respective.
Chaque premier groupe associé à une instruction logicielle respective comporte un identifiant d’une instruction logicielle précédente de ladite instruction respective et un identifiant d’une instruction logicielle suivante de ladite instruction respective, au sein de la séquence d’instructions formant le code exécutable 32.
Pour la génération de la première structure de modélisation, le module de génération 42 est par exemple configuré pour parcourir un chemin d’exécution de la séquence d’instructions, typiquement au niveau binaire, c’est-à-dire en langage machine, et pour déterminer, pour chaque instruction logicielle, l’identifiant de chaque instruction précédente, ainsi que l’identifiant de chaque instruction suivante.
En complément, chaque premier groupe comporte en outre une quantification temporelle d’une exécution de l’instruction logicielle respective, cette quantification temporelle étant par exemple exprimée sous forme d’un nombre de cycles d’horloge pour ladite exécution, ou encore sous forme d’un intervalle de valeurs de nombres de cycles d’horloge pour ladite exécution, compris entre une valeur minimale et une valeur maximale du nombre de cycles d’horloge possibles pour exécuter l’instruction logicielle respective. Autrement dit, cette quantification temporelle d’exécution de l’instruction logicielle respective, également appelée latence d’exécution, est exprimée sous forme d’une seule valeur du nombre de cycles d’horloge, ou encore sous forme d’un intervalle de valeurs du nombre de cycles d’horloge.
En complément facultatif, chaque premier groupe comporte en outre un identifiant de l’unité d’exécution associée à l’instruction logicielle respective, tel qu’un identifiant indiquant l’unité d’exécution concernée parmi la première unité d’exécution FU1 et la deuxième unité d’exécution FU2 dans l’exemple des figures 1 et 2.
En complément facultatif encore, chaque premier groupe comporte en outre une information d’éventuelle dépendance avec d’autres instructions logicielles, telle qu’un identifiant d’un registre commun avec lesdites autres instructions logicielles et/ou un identifiant d’une zone mémoire commune avec lesdites autres instructions logicielles.
Chaque premier groupe est par exemple en forme d’un mot de données, ou message, où chacun des identifiants ou informations inclus dans le premier groupe est alors en forme d’un champ respectif de ce mot de données.
Le module de calcul 44 est configuré pour calculer la deuxième structure de modélisation du fonctionnement de la séquence d’instructions, la deuxième structure comportant une pluralité de deuxièmes groupes de données, chacun étant associé à une instruction logicielle respective.
Chaque deuxième groupe est par exemple en forme d’un mot de données, ou message, où chacun des éléments inclus dans le deuxième groupe est alors en forme d’un champ respectif de ce mot de données.
Chaque deuxième groupe de données comporte typiquement un indicateur d’appartenance éventuelle à une chaine critique d’instructions, également appelée point chaud (de l’anglaish ot p oint), et en cas d’appartenance à une chaine critique respective, un identifiant d’une instruction initiale de ladite chaine critique. L’indicateur d’appartenance éventuelle à la chaine critique est par exemple repéré par l’acronyme anglaisis_local, et l’identifiant de l’instruction initiale de la chaine critique est par exemple repéré par le nom anglaisstart.
Le module de calcul 44 est typiquement configuré pour calculer la deuxième structure de modélisation à partir de la première structure de modélisation générée par le module de génération 42, en parcourant successivement les premiers groupes de la première structure.
Chaque chaine critique respective correspond à des instructions d’une même fonction logicielle, et le module de calcul 44 est configuré pour calculer chaque chaine critique respective en résolvant un problème de sous-graphes avec contraintes sur le degré, également appelé DCSP (de l’anglaisDegree Constrain ed Subgraph Problem )chaque chaine critique correspondant à un sous-graphe, les nombres d’instructions incluses dans chaque chaine critique étant inférieur à un nombre maximal prédéfini, et un paramètre d’optimisation dudit problème étant le nombre de relations entre les instructions de la chaine critique respective, ledit nombre de relations correspondant alors à un nombre d’arcs orientés dans le sous-graphe associé.
La résolution de problèmes DCSP est connue en soi, et est par exemple décrite dans l’article «Anoth er look at the degree constrain ed subgraph problem» de Y.Shiloach, publié en 1981, ou encore dans l’article «On the approx imability of some degree-constrain ed subgraph problems» de O. Amini et al., publié en 2012.
Le nombre maximal prédéfini d’instructions contenues dans chaque chaine critique est par exemple choisi en fonction d’un paramètre de l’architecture en pipeline de la plateforme informatique 34, par exemple en fonction d’un nombre d’instructions aptes à être contenues dans l’intégralité du pipeline de la plateforme informatique 34, ou encore en fonction du nombre d’instructions aptes à être contenues dans l’un des étages de ladite plateforme 34, par exemple dans le troisième étage de registre d’instructions IR ou encore dans le quatrième étage d’exécution d’instructions FU.
Dans l’exemple de la , le nombre maximal prédéfini d’instructions de la chaine critique est égal à 9, et la chaine critique Lj correspond aux instructions logicielles 8 à 16, et pour cette chaine critique d’instructions, le paramètre d’optimisation est ici égal 19 correspondant à la somme de toutes les relations entre les instructions 8 à 16 de ladite chaine, également appelées relations internes, des relations entrantes vers les instructions de ladite chaine, c’est-à-dire les relations entre des instructions en amont de ladite chaine et lesdites instructions de la chaine, et des relations sortantes de ladite chaine, c’est-à-dire des relations entre une instruction de ladite chaine et une instruction logicielle en aval de ladite chaine.
Pour chaque chaine critique déterminée via la résolution du problème DCSP, le module de calcul 44 est configuré pour positionner à une valeur vraie, telle que la valeur booléenne 1 ou encore la valeur TRUE, l’indicateur d’appartenanceis_localassocié à chacune des instructions logicielles incluses dans la chaine critique déterminée, et également pour renseigner, en tant qu’identifiant d’instruction initialestartet pour chaque instruction logicielle incluse dans la chaine critique déterminée, l’identifiant de la première instruction logicielle de la chaine critique ainsi déterminée.
Autrement dit, après avoir déterminé une chaine critique respective, le module de calcul 44 est configuré pour renseigner l’indicateur d’appartenanceis_localet l’identifiant d’instruction initialestartpour chacune des instructions logicielles formant la chaine critique déterminée, et ce de manière identique pour chacune de ces instructions, l’indicateur d’appartenanceis_localétant positionné à la valeur vraie, et l’identifiant d’instruction initialestartétant renseigné avec l’identifiant de la première instruction de la chaine respective.
En complément facultatif, le module de calcul 44 est, pour chaque instruction logicielle appartenant à une chaine critique respective, configuré en outre pour calculer un champ de pré-contexte, également notépre_v, et un champ de post-contexte, également notépost_v, le champ de pré-contextepre_vincluant l’identifiant de chaque instruction précédant l’instruction associée audit deuxième groupe et n’appartenant pas à la chaine critique dont fait partie ladite instruction, et le champ de poste-contextep ost _vincluant l’identifiant de chaque instruction succédant à l’instruction associée audit deuxième groupe et n’appartenant pas à la chaine critique dont fait partie ladite instruction.
En complément facultatif encore, le module de calcul 44 est configuré pour calculer, pour chaque instruction logicielle, au moins une quantification temporelle d’un chemin d’exécution jusqu’à ladite instruction respective, l’au moins une quantification temporelle de chemin d’exécution étant incluse dans le deuxième groupe associé à l’instruction respective.
Selon ce complément facultatif, le module de calcul 44 est typiquement configuré pour calculer chaque quantification temporelle de chemin d’exécution jusqu’à l’instruction logicielle respective à partir du champ de pré-contextepre_vpour ladite instruction et des quantifications temporelles d’exécution pour les instructions identifiées dans ce champ de pré-contextepre_v, et à partir de la quantification temporelle d’exécution de ladite instruction respective, c’est-à-dire de sa latence d’exécution.
Selon ce complément facultatif, le module de calcul 44 est par exemple configuré pour calculer, pour chaque instruction logicielle, une première quantification temporelle d’un plus court chemin d’exécution jusqu’à ladite instruction respective, c’est-à-dire une quantification temporelle du plus court chemin d’exécution entre une instruction initiale de la séquence et l’instruction respective, la première quantification temporelle étant également notéeshet incluse dans le deuxième groupe associé à ladite instruction.
Le module de calcul 44 est configuré pour calculer la première quantification temporelleshpour l’instruction respective à partir de premières quantifications temporelles préalablement calculées pour les instructions identifiées dans le champ de pré-contextepre_vde ladite instruction, c’est-à-dire pour les instructions précédant ladite instruction suivant les chemins d’exécution possibles, et à partir de la latence d’exécution de ladite instruction.
Le module de calcul 44 est par exemple configuré pour calculer la première quantification temporelleshpour ladite instruction respective à partir du minimum parmi les premières quantifications temporelles calculées pour les instructions identifiées dans le champ de pré-contextepre_vde l’instruction logicielle respective, et à partir de la latence d’exécution de ladite instruction. La première quantification temporelleshpour ladite instruction respective est de préférence égale à la somme du minimum parmi les premières quantifications temporelles calculées pour les instructions identifiées dans le champ de pré-contextepre_vde l’instruction logicielle respective et de la latence d’exécution de ladite instruction.
La première quantification temporelleshvérifie alors par exemple l’équation suivante :
sh(j)représente la première quantification temporelle pour l’instruction logicielle d’indice j,
min représente la fonction minimum,
sh(i)représente chaque première quantification temporelle pour une instruction logicielle d’indice i appartenant au champ de pré-contexte pre_v(j) de l’instruction d’indice j, chaquesh(i)correspondant alors à la première quantification temporelle pour une instruction respective précédant l’instruction d’indice j,
Inf représente la fonction borne inférieure, et
lat(j) représente la latence d’exécution de l’instruction d’indice j.
L’homme du métier observera que lorsque la latence d’exécution de l’instruction d’indice j est en forme d’un intervalle de valeurs de nombres de cycles d’horloge, alors la borne inférieure est égale à la valeur minimale de cet intervalle de valeurs, i.e. de cette plage de valeurs. En variante, lorsque la latence d’exécution de l’instruction d’indice j est exprimée sous forme d’un nombre donné de cycles d’horloge pour ladite exécution, alors la borne inférieure de cette latence d’exécution est égale audit nombre donné de cycles d’horloge.
Selon ce complément facultatif, le module de calcul 44 est également configuré pour calculer une deuxième quantification temporelle correspondant à la quantification temporelle d’un plus long chemin d’exécution jusqu’à ladite instruction respective, c’est-à-dire du plus long chemin d’exécution entre l’instruction initiale de la séquence et l’instruction respective, la deuxième quantification temporelle étant également notéeloet incluse dans le deuxième groupe associé à ladite instruction.
Le module de calcul 44 est configuré pour calculer la deuxième quantification temporelle pour l’instruction respective à partir de deuxièmes quantifications temporelles préalablement calculées pour les instructions identifiées dans le champ de pré-contextepre_vde ladite instruction, et à partir de la latence d’exécution de ladite instruction.
Le module de calcul 44 est par exemple configuré pour calculer la deuxième quantification temporellelopour ladite instruction respective à partir du maximum parmi les deuxièmes quantifications temporelles calculées pour les instructions identifiées dans le champ de pré-contextepre_vde l’instruction logicielle respective, et à partir de la latence d’exécution de ladite instruction. La deuxième quantification temporellelopour ladite instruction respective est de préférence égale à la somme du maximum parmi les deuxièmes quantifications temporelles calculées pour les instructions identifiées dans le champ de pré-contextepre_vde l’instruction logicielle respective et de la latence d’exécution de ladite instruction.
La deuxième quantification temporellelopour l’instruction respective vérifie alors par exemple l’équation suivante :
lo (j)représente la deuxième quantification temporelle pour l’instruction logicielle d’indice j,
Max représente la fonction maximum,
lo (i)représente chaque deuxième quantification temporelle pour une instruction logicielle d’indice i appartenant au champ de pré-contexte pre_v(j) de l’instruction d’indice j, chaquelo (i)correspondant alors à la deuxième quantification temporelle pour une instruction respective précédant l’instruction d’indice j,
Sup représente la fonction borne supérieure, et
lat(j) représente la latence d’exécution de l’instruction d’indice j.
L’homme du métier observera de manière analogue que lorsque la latence d’exécution de l’instruction d’indice j est en forme d’un intervalle de valeurs de nombres de cycles d’horloge, alors la borne supérieure est égale à la valeur maximale de cet intervalle de valeurs, i.e. de cette plage de valeurs. En variante, lorsque la latence d’exécution de l’instruction d’indice j est exprimée sous forme d’un nombre donné de cycles d’horloge pour ladite exécution, alors la borne supérieure de cette latence d’exécution est égale audit nombre donné de cycles d’horloge.
En complément facultatif, le module de calcul 44 est configuré pour calculer un champ d’étendue, également référencé par le nom anglaisscope, pour chaque chaine critique d’instructions déterminée, et pour inclure alors ledit champ d’étenduescopedans la deuxième structure de modélisation. Le module de calcul 44 est configuré pour calculer le champ d’étenduescopepour ladite chaine critique respective en fonction des accès mémoires effectués de la part de l’ensemble des instructions de ladite chaine critique, le champ d’étenduescopereprésentant une étendue, ou encore une amplitude, des accès mémoires effectués de la part de ladite chaine critique.
Selon ce complément facultatif, le champ d’étenduescopeinclut par exemple une valeur égale au nombre d’accès mémoire effectués de la part de l’ensemble des instructions de ladite chaine critique. En complément ou en variante, le champ d’étenduescopeest fonction de défauts de mémoire cache (de l’anglaiscache miss) associé aux instructions de ladite chaine critique, un défaut de mémoire cache étant alors comptabilisé comme un nombre prédéfini d’accès mémoire, ce nombre prédéfini d’accès mémoire étant typiquement de valeur strictement supérieure à 1, afin de tenir compte davantage dans ledit champ d’étenduescopede défaut(s) de mémoire cache que de simple accès mémoire. Un défaut de mémoire cache est par exemple comptabilisé comme étant égal à 10 cycles d’accès mémoires.
Le champ d’étenduescopepermet alors d’effectuer une priorisation entre plusieurs chaines critiques calculées, notamment lorsque plusieurs chaines critiques sont associées à une même fonction logicielle respective. La chaine critique sélectionnée est alors celle pour laquelle la valeur incluse dans le champ d’étenduescope, représentative de l’étendue des accès mémoires effectués par la chaine critique respective, est la plus élevée.
En complément facultatif encore, le module de calcul 44 est configuré pour calculer un champ de variabilitévarpour chaque chaine critique d’instructions respective, et pour inclure alors ledit champ de variabilitévardans la deuxième structure de modélisation. Le champ de variabilitévarcomporte une variable de pré-contexte égale à l’identifiant le plus fréquent parmi les identifiants d’instructions contenus dans les champs de pré-contextepre_vpour ladite chaine critique ; et une variable de post-contexte égale à l’identifiant le plus fréquent parmi les identifiants d’instructions contenus dans les champs de post-contextepost _vpour ladite chaine critique respective.
Le champ de variabilitévarpermet alors d’identifier un point d’entrée critique de la chaîne critique via le champ de pré-contextepre_vpour ladite chaine critique ; et/ou d’identifier un point de sortie critique de ladite chaîne critique via le champ de post-contextepost _v .Par exemple, le champ de pré-contextepre_vpermet d’établir des valeurs d'entrée qui sont utiles pour explorer complètement de la chaîne critique, en utilisant la procédure susmentionnée, et le champ de post-contextepost _vpermet d’avoir les valeurs de sortie observées de l'exploration complète de la chaîne critique. Ainsi, le champ de variabilitévarpermet de capturer des relations temporelles entrée-sortie au niveau de la chaîne critique.
En complément, le champ de variabilitévarest pris en compte lors de la propagation des données de quantification temporelle d’une chaine à la suivante. Selon ce complément, le champ de post-contextepost _vde la chaîne critique Ljest propagé à la chaîne critique suivante Lj+1, ce champ de post-contextepost _vde la chaîne critique Ljétant par exemple pris en compte pour la détermination du champ de pré-contextepre_vde la chaîne critique suivante Lj+1.
Le module de recherche 46 est configuré pour rechercher une ou plusieurs anomalies temporelles à partir de chaine(s) critique(s) d’instructions déterminée(s) via la deuxième structure de modélisation. Une anomalie temporelle est détectée en cas d’incohérence entre les quantifications temporelles associées à une chaine critique courante et les quantifications temporelles associées à une chaine critique suivante. Le module de recherche 46 est alors typiquement configuré pour rechercher des incohérences entre les quantifications temporellessh, lode deux chaines critiques successives. Une incohérence entre les quantifications temporelles associées à deux chaines critiques successives correspond par exemple au cas où le plus long chemin d’exécution correspondant à une deuxième quantification temporelle associée à une chaine critique respective ne comporte pas les instructions logicielles de la chaine critique précédente, c’est-à-dire ne passe pas par la chaine critique précédente.
Une anomalie temporelle lors de l’exécution de la séquence d’instructions logicielles est un comportement temporel contre-intuitif lors de l’exécution de cette séquence, correspondant typiquement à une rupture dans la monotonie de l’évolution temporelle de l’exécution de la séquence, ceci étant alors dû à une exécution rapide locale ralentissant une exécution globale.
Une rupture de la monotonie de l’évolution temporelle de l’exécution de la séquence d’instructions logicielles est typiquement due à la présence d’un ou plusieurs défauts de mémoire cache (de l’anglaiscache misses)associés à une ou plusieurs des instructions logicielles. Autrement dit, la présence de tels défauts de mémoire cache est susceptible d’entraîner l’apparition d’une anomalie temporelle.
Une rupture de monotonie de l’évolution temporelle est illustrée à titre d’exemple sur la . Dans l’exemple de la , quatre chemins d’exécution 60, à savoir un premier 60A, un deuxième 60B, un troisième 60C et un quatrième 60D chemins d’exécution, sont représentés en parallèle dans le cadre de l’exécution d’une séquence formée de quatre instructions logicielles A, B, C et D, où les instructions A et D sont destinées à être exécutées par la première unité d’exécution FU1, et les instructions logicielles B et C sont destinées à être exécutées par la deuxième unité d’exécution FU2.
Dans cet exemple de la , la durée d’exécution de la séquence augmente progressivement depuis le premier chemin d’exécution 60A représenté en haut de la , et pour lequel l’exécution de la séquence est effectuée en dix cycles d’horloge numérotés 1 à 10, jusqu’au troisième chemin d’exécution 60C, ce troisième chemin d’exécution 60C correspondant à une exécution de la séquence en douze cycles d’horloge numérotés 1 à 12. L’homme du métier observera alors que l’augmentation de la durée d’exécution entre les premier 60A et troisième 60C chemins est due à une augmentation progressive de la durée d’exécution de l’instruction logicielle A par la première unité d’exécution FU1, celle-ci étant égale à un cycle d’horloge pour le premier chemin d’exécution 60A, puis à deux cycles d’horloge numérotés 1 et 2 pour le deuxième chemin d’exécution 60B, et enfin à trois cycles d’horloge pour le troisième chemin d’exécution 60C. Le quatrième chemin d’exécution 60D, représenté en bas de la , présente alors une anomalie temporelle TA (de l’anglais Timing Anomaly), puisque la durée d’exécution globale de la séquence correspond alors à neuf cycles d’horloge, numérotés 1 à 9, c’est-à-dire la durée d’exécution de la séquence la plus courte parmi les quatre chemins d’exécution 60 représentés à la , alors que la durée d’exécution de l’instruction logicielle A pour ce quatrième chemin d’exécution 60D est égale à la durée d’exécution de l’instruction logicielle A pour le troisième chemin d’exécution 60C, et est strictement supérieure à la durée d’exécution de l’instruction logicielle A pour chacun des premier 60A et deuxième 60B chemins d’exécution.
On observe alors que dans cet exemple de la , l’anomalie temporelle TA est due au fait que, pour ce quatrième chemin d’exécution 60D, l’instruction logicielle C est exécutée avant l’instruction logicielle D par la deuxième unité d’exécution FU2, et que la dernière instruction logicielle D de la séquence est alors exécutée par la première unité d’exécution FU1 en parallèle de l’exécution de l’instruction logicielle B par la deuxième unité d’exécution FU2. L’exécution de la dernière instruction logicielle D s’achève alors à la fin du cycle 9, en même temps que celle de l’instruction logicielle B, et ce raccourcissement de la durée d’exécution globale de la séquence engendre alors une rupture de la monotonie de l’évolution de la durée de l’exécution de ladite séquence, caractéristique de l’anomalie temporelle TA à détecter.
En complément facultatif, le module de propagation 48 est configuré pour propager des données de quantifications temporelles d’une chaine critique courante d’instructions à une chaine critique suivante d’instructions, les quantifications temporelles associées à la chaine critique suivante étant alors déterminées à partir de celles associées à la chaine critique courante.
Pour la propagation des données de quantification temporelle d’une chaine à la suivante, le module de propagation 48 est par exemple configuré pour calculer au moins une valeur limite 70, 80 représentative d’une quantification temporelle d’exécution globale de la chaine critique courante, telle que la chaine critique Lj, afin de la propager ensuite à la chaine critique suivante, telle que la chaine critique Lj+1.
Le module de propagation 48 est par exemple configuré pour calculer une première valeur limite 70 correspondant à un plus court chemin d’exécution globale de la chaine critique, cette première valeur limite 70 étant par exemple notée Lj.sh pour la chaine critique Lj; et une deuxième valeur limite 80 correspondant à un plus long chemin d’exécution globale pour la chaine critique, cette deuxième valeur limite 80 étant par exemple notée Lj.lo pour la chaine critique Lj.
Selon ce complément facultatif, le module de propagation 48 est par exemple configuré pour calculer l’au moins une valeur limite 70, 80 en appliquant un algorithme de vérification de modèle (de l’anglaism odel c hecking) à la chaine critique courante, telle que la chaine critique Lj , c’est-à-dire en mettant en œuvre ledit algorithme de vérification de modèle pour ladite chaine critique courante.
L’algorithme de vérification de modèle est connu en soi, et est par exemple décrit dans le document intitulé «Model checking (second edition)» de E. Clarke et al., MIT Press, 2018, et est basé sur une structure de Kripke permettent de modéliser un système de transition, tel que la chaine critique respective. La structure de Kripke est typiquement en forme d’un 4-uplet (S, S0, R, L), où S est un ensemble d’un nombre fini d’états ; S0 est l’ensemble des valeurs initiales des états de l’ensemble S ; R est une relation de transition sur les états de l’ensemble S ; et L est une fonction d’étiquetage (de l’anglaisl abelling f unction) des états de l’ensemble S en formules logiques, c’est-à-dire une fonction d’interprétation desdits états de l’ensemble S en formules logiques.
Pour l’application de l’algorithme de vérification de modèle à la chaine critique respective, et en particulier pour la mise en œuvre de la structure de Kripke pour ladite chaine critique, le module de propagation 48 est alors configuré pour renseigner le uplet S0 correspondant à l’ensemble des valeurs initiales des états avec le champ de pré-contextepre_v, et l’algorithme de vérification de modèle permet alors d’explorer l’ensemble des chemins d’exécution pour ladite chaine critique, cet ensemble des chemins d’exécution correspondant au uplet S, ou autrement dit chaque état de l’ensemble S correspondant à une exécution possible des instructions logicielles de la chaine critique, tel que décrit par exemple dans l’article «Formal executable models for automatic detection of timing anomalies» de M. Asavoae et al., WCET 2018.
Le module de propagation 48 est alors configuré pour calculer les première et deuxième valeurs limites 70, 80 pour la chaine critique courante, telles que les valeurs Lj.sh et Lj.lo pour la chaine critique Lj, via la mise en œuvre de l’algorithme de vérification de modèle pour ladite chaine critique courante, telle que la chaine critique Lj; puis pour propager la ou les valeurs limites 70, 80 ainsi calculées jusqu’à la chaine critique suivante, telle que la chaine critique Lj+1.
Le module de propagation 48 est configuré pour effectuer ladite propagation de données de quantification temporelle en déterminant un chemin d’exécution reliant la fin de la chaine critique courante, telle que la chaine critique Lj, au début de la chaine critique suivante, telle que la chaine critique Lj +1, ce chemin d’exécution étant de préférence unique. Le module de propagation 48 est alors par exemple configuré pour additionner, à la ou aux valeurs limites 70, 80, la latence d’exécution de chacune des instructions logicielles formant ledit chemin entre la fin de la chaine critique courante et le début de la chaine critique suivante.
Le module de propagation 48 est alors configuré pour mettre à jour le champ de pré-contextepre_vpour la chaine critique suivante, telle que la chaine critique Lj +1, avec le résultat de cette propagation, c’est-à-dire avec la somme de la ou des valeurs limites 70, 80 de la chaine critique qui la précède, c’est-à-dire de la chaine critique courante, telle que la chaine critique Lj, et des latences d’exécution pour les instructions logicielles entre ladite chaine critique courante et la chaine critique suivante, lesdites instructions entre deux chaines critiques successives étant également appelées instructions intermédiaires.
En complément encore, le module de propagation 48 est alors configuré pour appliquer l’algorithme de vérification de modèle à la chaine critique suivante, telle que la chaine critique Lj+1, en utilisant le résultat de cette propagation contenue dans le champ de pré-contextepre_vmis à jour, afin de calculer l’au moins une valeur limite 70, 80 pour la chaine critique suivante, et par exemple la première valeur limite 70 pour ladite chaine critique suivante, telle que la valeur Lj+1.sh, et la deuxième valeur limite 80 pour ladite chaine critique suivante, telle que la valeur Lj+1.lo.
Cette propagation de données de quantification temporelle est illustrée sur la où lors d’une première itération, notée iteri, le module de calcul 44 est configuré pour calculer des chaines critiques successives notées Lj, Lj+1, Lj+2 via la résolution de problèmes DCSP. Puis, lors d’une itération suivante notée iteri+1, le module de propagation 48 est configuré pour calculer les valeurs limites 70, 80 associées à la chaine critique courante, telles que les valeurs limites Lj.sh, Lj.lo pour la chaine critique Lj, via la mise en œuvre de l’algorithme de vérification de modèle pour ladite chaine critique courante, telle que la chaine critique Lj. Ensuite, lors d’une itération subséquente, notée iteri+2, le module de propagation 48 est configuré - d’une part - pour effectuer la somme des latences d’exécution pour les instructions logicielles se trouvant entre la fin de la chaine critique courante, telle que la chaine critique Lj, et le début de la chaine critique suivante, , telle que la chaine critique Lj+1, et additionner cette somme aux valeurs limites 70, 80 afin de propager ces valeurs 70, 80 de la chaine critique courante jusqu’à la chaine critique suivante, puis d’autre part - pour mettre en œuvre l’algorithme de vérification de modèle pour la chaine critique suivante, telle que la chaine critique Lj+1, afin de calculer la ou les valeurs limites 70, 80, telles que les valeurs limites Lj+1.sh, Lj+1.lo, et en prenant alors en compte le résultat de la propagation temporelle préalablement effectuée et contenue dans le champ de pré-contexte pre_v mis à jour pour la chaine critique suivante, telle que la chaine critique Lj+1.
Selon ce complément facultatif, le module de recherche 46 est alors configuré en outre pour rechercher une éventuelle anomalie temporelle entre la chaine critique courante et la chaine critique suivante, en vérifiant si la ou les valeurs limites 70, 80 calculées pour la chaine critique suivante sont cohérentes avec la chaine critique qui la précède, c’est-à-dire avec la chaine critique courante, et typiquement pour vérifier si le plus long chemin d’exécution globale jusqu’à la chaine critique suivante correspondant à la deuxième valeur limite 80 calculée pour la chaine critique suivante, telle que la valeur Lj+1.lo pour la chaine critique Lj +1, inclut les instructions logicielles de la chaine critique qui la précède, c’est-à-dire de la chaine critique courante, telle que la chaine critique Lj.
Si le plus long chemin d’exécution globale jusqu’à la chaine critique suivante contient les instructions logicielles de la chaine critique qui la précède, c’est-à-dire de la chaine critique courante, ou autrement dit si le plus long chemin d’exécution globale jusqu’à la chaine critique suivante passe par la chaine critique courante, alors le module de recherche 46 est configuré pour déterminer une absence d’anomalie temporelle entre la chaine critique courante et la chaine critique suivante. Sinon, si le plus long chemin d’exécution globale jusqu’à la chaine critique suivante ne contient pas les instructions logicielles de la chaine critique qui la précède, c’est-à-dire de la chaine critique courante, alors le module de recherche 46 est configuré pour détecter la présence d’une anomalie temporelle entre la chaine critique courante et la chaine critique suivante.
En complément encore, en cas de détermination d’une absence d’anomalie temporelle entre la chaine critique courante et la chaine critique suivante par le module de recherche 46, le module de propagation 48 est configuré en outre pour poursuivre la propagation des données de quantification temporelle d’une chaine critique à la suivante, et alors pour effectuer une opération de propagation en propageant les données de quantification temporelle de la chaine critique Lj +1jusqu’à la chaine critique Lj + 2,et ainsi de suite.
Le fonctionnement du dispositif électronique de surveillance 30 selon l’invention va être à présent décrit en regard de la représentant un organigramme du procédé, selon l’invention, de surveillance du code exécutable 32 apte à être exécuté sur la plateforme informatique 34.
Lors d’une étape initiale 100, le dispositif électronique de surveillance 30 acquiert, via son module d’acquisition 40, la séquence d’instructions logicielles formant le code exécutable 32 destiné à être surveillé. La séquence d’instructions logicielles acquise lors de cette étape initiale 100 est typiquement une séquence d’instructions exprimées en langage machine et qui sont alors directement interprétables par la plateforme informatique 34. Ces instructions logicielles sont par exemple des instructions de type RISC, comme dans l’exemple décrit précédemment.
Le dispositif de surveillance 30 passe ensuite à l’étape suivante 110 lors de laquelle le module de génération 42 génère la première structure de modélisation modélisant le ou les chemins d’exécution de la séquence d’instructions, la première structure de modélisation étant générée à partir de la séquence d’instructions et comportant un premier groupe de données respectif pour chacune des instructions logicielles de ladite séquence. Chaque premier groupe respectif comporte l’identifiant de l’instruction précédente et l’identifiant de l’instruction suivante pour l’instruction logicielle respective associée audit premier groupe.
Lors de cette étape de génération 110, chaque premier groupe généré comporte en outre la latence d’exécution de l’instruction logicielle respective, cette latence d’exécution étant typiquement exprimée sous forme d’un intervalle de valeurs de nombres de cycles d’horloges nécessaires pour l’exécution de ladite instruction, ou encore sous forme d’un nombre donné de cycles d’horloges nécessaires pour ladite exécution.
En complément facultatif, chaque premier groupe respectif comporte en outre l’identifiant de l’unité d’exécution associé à l’instruction logicielle respective, tel que l’identifiant de l’unité d’exécution mise en œuvre parmi la première unité fonctionnelle FU1 et la deuxième unité fonctionnelle FU2 pour la plateforme informatique 34 de l’exemple de la .
Selon ce complément, l’identifiant de l’unité d’exécution est utilisé pour modéliser l'exécution d’instructions logicielles sur une unité d’exécution donnée, la vitesse d’exécution des instructions par une unité d’exécution respective, ou corollairement le temps d’exécution, ou encore la latence d’exécution, dépendant de l’unité d’exécution considérée. Selon ce complément, l’identifiant de l’unité d’exécution est alors pris en compte en outre lors de la résolution du problème de sous-graphes avec contraintes sur le degré ou DCSP, pour le calcul de la chaîne critique respective.
En complément encore, chaque premier groupe respectif comporte en outre l’information d’éventuelle dépendance avec d’autres instructions, telle que l’identifiant de chaque registre en commun entre l’instruction logicielle respective et lesdites autres instructions et/ou l’identifiant de chaque zone mémoire commune avec lesdites autres instructions, c’est-à-dire de chaque zone mémoire utilisée en commun par l’instruction logicielle respective et lesdites autres instructions.
Selon ce complément, l’information d’éventuelle dépendance est utilisée pour améliorer encore la modélisation du chemin d’exécution, en particulier en permettant d’indiquer quand les instructions logicielles sont exécutées au sein de la séquence d’instructions.
L’homme du métier observera en outre que lors de l’exploration complète d’une chaîne critique, la séquence d’instructions considérées est exécutée suivant le mode d’exécution de la plate-forme informatique, par exemple suivant un mode hors-ordre (de l’anglaisout of order), l’ordre d’exécution de la séquence d’instructions de la chaîne critique n’étant, autrement dit, pas nécessairement un ordre séquentiel.
Aussi, lorsque le mode d’exécution de la plate-forme informatique n’est pas un mode d’exécution séquentielle, et que les instructions logicielles ne sont alors pas exécutées selon un ordre séquentiel, l’information d’éventuelle dépendance est prise en compte en outre lors de la résolution du problème de sous-graphes avec contraintes sur le degré ou DCSP, pour le calcul de la chaîne critique respective, afin de permettre l’exploration des différents chemins d’exécution possibles.
Lors de l’étape suivante 120, le dispositif de surveillance 30 calcule, via son module de calcul 44, la deuxième structure de modélisation modélisant le fonctionnement de la séquence d’instructions, la deuxième structure étant calculée à partir de la première structure de modélisation et comportant un deuxième groupe de données respectif pour chacune des instructions logicielles de la séquence.
Chaque deuxième groupe comporte notamment l’indicateur d’appartenanceis_localindiquant une appartenance éventuelle de l’instruction respective à une chaine critique correspondante de la séquence, c’est-à-dire indiquant l’appartenance ou non de ladite instruction logicielle à un point chaud respectif, cet indicateur étant typiquement positionné la valeur vraie si l’instruction logicielle respective appartient à une chaine critique, et à la valeur faux, telle que la valeur booléenne 0 ou encore la valeur FALSE, si ladite instruction logicielle respective n’appartient à aucune chaine critique. Chaque deuxième groupe comporte en outre, en cas d’appartenance à une chaine critique respective, l’identifiant d’instruction initialestart¸ c’est-à-dire l’identifiant de la première instruction logicielle de la chaine critique respective.
Lors de cette étape de calcul 120, la deuxième structure de modélisation est obtenue à partir de la première structure, en parcourant successivement les premiers groupes de la première structure. Chaque chaine critique respective correspond à des instructions d’une même fonction logicielle, et est typiquement calculée en résolvant un problème DCSP, c’est-à-dire un problème de sous-graphes avec contraintes sur le degré, comme décrit précédemment.
En complément, pour chaque instruction logicielle appartenant à une chaine critique respective, le module de calcul 44 calcule en outre le champ de pré-contextepre_vet le champ de post-contextepost_v, le champ de pré-contextepre_vincluant l’identifiant de chaque instruction précédant l’instruction logicielle respective et n’appartenant pas à la chaine critique dont fait partie ladite instruction, et le champ de post-contextepost_vincluant l’identifiant de chaque instruction succédant à l’instruction logicielle respective et n’appartenant pas à la chaine critique dont fait partie ladite instruction.
En complément encore, le module de calcul 44 calcule, lors de cette étape 120, l’au moins une quantification temporellesh, lodu chemin d’exécution jusqu’à l’instruction logicielle respective, et de préférence à la fois la première quantification temporelleshégale à la quantification temporelle du plus court chemin d’exécution jusqu’à l’instruction logicielle respective, et la deuxième quantification temporelleloégale à la quantification temporelle du plus long chemin d’exécution jusqu’à ladite instruction respective.
Selon ce complément, chaque quantification temporelle de chemin d’exécutionlo, shest typiquement calculée à partir du champ de pré-contextepre_vet des quantifications temporelles d’exécution des instructions identifiées dans ledit champ de pré-contexte, et également à partir de la latence d’exécution de ladite instruction respective.
En complément facultatif encore, lors de l’étape 120, le module de calcul 44 calcule en outre le champ d’étenduescopepour chaque chaine critique d’instructions respective, ce champ d’étenduescopepermettant notamment d’effectuer une priorisation entre plusieurs chaines critiques éventuelles associées à la même fonction logicielle, afin de sélectionner alors la chaine critique la plus prioritaire pour cette fonction logicielle, typiquement la chaine critique pour laquelle le champ d’étenduescopeprésente la valeur la plus élevée, caractéristique d’une plus grande utilisation des ressources mémoires de la plateforme informatique 34.
En complément facultatif encore, le module de calcul 44 calcule en outre lors de cette étape 120, le champ de variabilitévarpour chaque chaine critique respective. Ce champ de variabilitévarincluant par exemple la variable de pré-contexte égale à l’identifiant le plus fréquent parmi les identifiants d’instructions contenus dans les champs de pré-contextepre_vpour ladite chaine critique et permettant alors d’identifier l’instruction logicielle la plus susceptible d’être exécutée préalablement à ladite chaine critique, et/ou la variable de post-contexte égale à l’identifiant le plus fréquent parmi les identifiants d’instructions contenus dans les champs de post-contextepost_vpour la dite chaine critique, permettant de manière analogue d’identifier l’instruction logicielle la plus susceptible d’être exécutée postérieurement à ladite chaine critique.
Lors d’une étape optionnelle 130 suivante, le module de propagation 48 propage les données de quantification temporelle d’une chaine critique courante d’instructions à la chaine critique suivante, et par exemple de la chaine critique Ljà la chaine critique Lj +1. Cette propagation de données de quantification temporelle est par exemple effectuée en mettant tout d’abord en œuvre l’algorithme de vérification de modèle pour la chaine critique courante, telle que la chaine critique Lj,afin de calculer la ou les valeurs limites 70, 80, telles que la première valeur limite 70, également notée Lj.sh et correspondant au plus court chemin d’exécution globale jusqu’à la chaine critique Lj,et la deuxième valeur limite 80, également notée Lj.lo et correspondant au plus long chemin d’exécution jusqu’à la chaine critique Lj.Le module de propagation 48 propage ensuite la ou les valeurs limites 70, 80 ainsi calculées jusqu’à la chaine critique suivante, telle que la chaine critique Lj +1, en leur additionnant les latences d’exécution des instructions logicielles intermédiaires comprises entre la fin de la chaine critique courante, telle que la chaine critique Lj,et le début de la chaine critique suivante, telle que la chaine critique Lj +1.
Le dispositif de surveillance 30 recherche enfin, lors de l’étape 140 et via son module de recherche 46, une ou plusieurs anomalies temporelles à partir des chaines critiques d’instructions déterminées via la deuxième structure de la modélisation lors de l’étape de calcul 120. Cette recherche d’anomalie(s) temporelle(s) est typiquement effectuée en recherchant des incohérences éventuelles entre les quantifications temporelles associées à la chaine critique courante et celles associées à la chaine critique suivante, par exemple en recherchant les éventuelles incohérences entre les quantifications temporelles des chaines critiques Ljet Lj +1, puis lors d’une itération suivante entre celles des chaines critiques Lj+1et Lj + 2.
En complément, lorsque les données de quantification temporelle ont été propagées d’une chaine critique courante à la suivante lors de l’étape optionnelle 130, par exemple de la chaine critique Lj à la chaine critique Lj+1 comme représenté sur la , le module de recherche 46 va de préférence rechercher la présence d’anomalie(s) temporelle(s) éventuelle(s) en vérifiant si le plus long chemin d’exécution globale jusqu’à une chaine critique respective, telle que la chaine Lj+1, contient les instructions logicielles de la chaine critique précédente, telle que la chaine critique Lj, et détermine alors le cas échéant une absence d’anomalie temporelle. Cette vérification est typiquement effectuée via une comparaison d’une liste triée des identifiants des instructions logicielles formant le plus long chemin global d’exécution jusqu’à la chaine critique Lj+1 avec la liste des instructions logicielles formant la chaine critique Lj qui la précède.
Selon ce complément, si le module de recherche 46 conclut au contraire, suite à cette vérification, que le plus long chemin d’exécution globale jusqu’à la chaine critique Lj +1ne passe pas par la chaine critique Ljqui la précède, c’est-à-dire ne contient pas toutes les instructions logicielles de ladite chaine critique Lj, alors le module de recherche 46 détermine la présence d’une anomalie temporelle entre les chaines critiques Ljet Lj +1. Le cas échéant, le module de recherche 46 génère de préférence une alerte, afin de signaler ladite anomalie temporelle.
Si aucune anomalie temporelle n’a été trouvée lors de l’étape de recherche 140 entre les chaines critiques Ljet Lj +1, alors le dispositif de surveillance 30 retourne par exemple à l’étape optionnelle 130 afin d’effectuer une nouvelle propagation de données de quantification temporelle d’une chaine critique à la suivante, en l’occurrence de la chaine critique Lj +1 à la chaine critique Lj + 2,puis passe ensuite à nouveau à l’étape de recherche 140 afin de rechercher la présence d’anomalie(s) temporelle(s) éventuelle(s) entre les chaines critiques Lj +1et Lj + 2,et ainsi de suite.
Ainsi, le dispositif de surveillance 30 et le procédé de surveillance selon l’invention permettent de déterminer automatiquement la ou les chaines critiques d’instructions, également appelées points chauds, pour la séquence d’instructions logicielles formant le code exécutable 32 surveillé, ceci à partir de la deuxième structure de modélisation calculée par le module de calcul 44, cette deuxième structure étant elle-même obtenue à partir de la première structure de modélisation générée par le module de génération 42.
Le dispositif de surveillance 30 et le procédé de surveillance selon l’invention permettent ensuite de rechercher en outre la présence d’une ou plusieurs anomalies temporelles éventuelles associées à l’exécution de la séquence d’instructions formant ledit code exécutable 32, ceci à partir des chaines critiques d’instructions déterminées via la deuxième structure de modélisation, et typiquement à partir des quantifications temporelles des chemins d’exécution associés à chacune de ces chaines critiques d’instructions.
On conçoit ainsi que le dispositif de surveillance 30 et le procédé de surveillance selon l’invention permettent de détecter automatiquement et facilement d’éventuelles anomalies temporelles.

Claims (14)

  1. Procédé de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, le code exécutable comportant une séquence d’instructions logicielles,
    le procédé étant mis en œuvre par un dispositif électronique de surveillance et caractérisé en ce qu’il comprend les étapes suivantes :
    - acquisition (100) de la séquence d’instructions logicielles ;
    - génération (110) d’une première structure de modélisation d’un chemin d’exécution de la séquence d’instructions, la première structure étant générée à partir de la séquence d’instructions et comportant une pluralité de premiers groupes de données, chacun associé à une instruction logicielle respective ; chaque premier groupe comportant un identifiant d’une instruction précédente et un identifiant d’une instruction suivante ;
    - calcul (120) d’une deuxième structure de modélisation d’un fonctionnement de la séquence d’instructions, la deuxième structure comportant une pluralité de deuxièmes groupes de données, chacun associé à une instruction logicielle respective ; chaque deuxième groupe comportant un indicateur d’appartenance éventuelle à une chaîne critique d’instructions, et en cas d’appartenance à une chaîne critique respective, un identifiant d’une instruction initiale de ladite chaine critique ; la deuxième structure étant créée à partir de la première structure, en parcourant successivement les premiers groupes de la première structure ; une chaîne critique respective correspondant à des instructions d’une même fonction logicielle et étant calculée en résolvant un problème de sous-graphes avec contraintes sur le degré, chaque chaîne critique correspondant à un sous-graphe, le nombre d’instructions incluses dans chaque chaîne critique étant inférieur ou égal à un nombre maximal prédéfini, et un paramètre d’optimisation étant le nombre de relations entre les instructions de la chaîne critique respective, ledit nombre de relations correspondant à un nombre d’arcs dans le sous-graphe associé ; et
    - recherche d’anomalie(s) temporelle(s) à partir de chaîne(s) critique(s) d’instructions déterminée(s) via la deuxième structure de modélisation.
  2. Procédé selon la revendication 1, dans lequel lors de l’étape de calcul, pour chaque instruction logicielle appartenant à une chaîne critique respective, chaque deuxième groupe comporte en outre un champ de pré-contexte et un champ de post-contexte ; le champ de pré-contexte incluant l’identifiant de chaque instruction précédant l’instruction associée audit deuxième groupe et n’appartenant pas à la chaine critique dont fait partie ladite instruction, et le champ de post-contexte incluant l’identifiant de chaque instruction succédant à l’instruction associée audit deuxième groupe et n’appartenant pas à la chaine critique dont fait partie ladite instruction.
  3. Procédé selon la revendication 2, dans lequel lors de l’étape de calcul, un champ d’étendue est ajouté pour chaque chaîne critique d’instructions respective dans la deuxième structure de modélisation, le champ d’étendue incluant un nombre d’accès mémoire de la part de l’ensemble des instructions de ladite chaîne critique.
  4. Procédé selon la revendication 2 ou 3, dans lequel lors de l’étape de calcul, une variable de pré-contexte et une variable de post-contexte sont ajoutées pour chaque chaîne critique d’instructions respective dans la deuxième structure de modélisation, la variable de pré-contexte étant égale à l’identifiant le plus fréquent parmi les identifiants d’instruction contenus dans les champs de pré-contexte pour ladite chaîne critique, et la variable de post-contexte étant égale à l’identifiant le plus fréquent parmi les identifiants d’instruction contenus dans les champs de post-contexte pour ladite chaîne critique.
  5. Procédé selon l’une quelconque des revendications précédentes, dans lequel chaque premier groupe comporte en outre une quantification temporelle d’une exécution de l’instruction logicielle respective, et chaque deuxième groupe comporte en outre au moins une quantification temporelle d’un chemin d’exécution de la séquence jusqu’à ladite instruction respective ;
    la quantification temporelle de l’exécution de l’instruction logicielle respective étant de préférence un nombre de cycles d’horloge pour ladite exécution.
  6. Procédé selon les revendications 2 et 5, dans lequel chaque quantification temporelle d’un chemin d’exécution jusqu’à l’instruction logicielle respective est calculée à partir du champ de pré-contexte pour ladite instruction et des quantifications temporelles d’exécution pour ladite instruction respective et pour les instructions identifiées dans le champ de pré-contexte.
  7. Procédé selon la revendication 5 ou 6, dans lequel le procédé comprend en outre une étape de propagation de données de quantification temporelle d’une chaine critique précédente d’instructions à une chaine critique courante d’instructions, les quantifications temporelles associées à la chaine critique courante étant déterminées à partir de celles associées à la chaine critique précédente.
  8. Procédé selon la revendication 7, dans lequel lors de l’étape de recherche, une anomalie temporelle est détectée en cas d’incohérence entre les quantifications temporelles associées à la chaine critique courante et celles associées à la chaine critique précédente.
  9. Procédé selon l’une quelconque des revendications 5 à 8, dans lequel une première quantification temporelle incluse dans le deuxième groupe est une quantification temporelle d’un plus court chemin d’exécution entre une instruction initiale de la séquence et l’instruction respective ; et une deuxième quantification temporelle incluse dans le deuxième groupe est une quantification temporelle d’un plus long chemin d’exécution entre ladite instruction initiale et l’instruction respective.
  10. Procédé selon l’une quelconque des revendications précédentes, dans lequel la plateforme informatique comporte plusieurs unités d’exécution d’instruction(s) (FU1, FU2), et chaque premier groupe comporte en outre un identifiant de l’unité d’exécution (FU1, FU2) associée à l’instruction logicielle respective.
  11. Procédé selon l’une quelconque des revendications précédentes, dans lequel chaque premier groupe comporte en outre une information d’éventuelle dépendance avec d’autres instructions, telle qu’un identifiant de registre commun avec lesdites autres instructions et/ou un identifiant de zone mémoire commune avec lesdites autres instructions.
  12. Procédé selon l’une quelconque des revendications précédentes, dans lequel la séquence d’instructions logicielles est une séquence d’instructions exprimées en langage machine, directement interprétables par la plateforme informatique.
  13. Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon l’une quelconque des revendications précédentes.
  14. Dispositif électronique (30) de surveillance d’un code exécutable (32) apte à être exécuté sur une plateforme informatique (34), le code exécutable (32) comportant une séquence d’instructions logicielles, le dispositif (30) étant caractérisé en ce qu’il comprend :
    - un module d’acquisition (40) configuré pour acquérir la séquence d’instructions logicielles ;
    - un module de génération (42) configuré pour générer une première structure de modélisation d’un chemin d’exécution de la séquence d’instructions, la première structure étant générée à partir de la séquence d’instructions et comportant une pluralité de premiers groupes de données, chacun associé à une instruction logicielle respective ; chaque premier groupe comportant un identifiant d’une instruction précédente et un identifiant d’une instruction suivante ;
    - un module de calcul (44) configuré pour calculer une deuxième structure de modélisation d’un fonctionnement de la séquence d’instructions, la deuxième structure comportant une pluralité de deuxièmes groupes de données, chacun associé à une instruction logicielle respective ; chaque deuxième groupe comportant un indicateur d’appartenance éventuelle à une chaîne critique d’instructions, et en cas d’appartenance à une chaîne critique respective, un identifiant d’une instruction initiale de ladite chaine critique ; la deuxième structure étant créée à partir de la première structure, en parcourant successivement les premiers groupes de la première structure ; une chaîne critique respective correspondant à des instructions d’une même fonction logicielle et étant calculée en résolvant un problème de sous-graphes avec contraintes sur le degré, chaque chaîne critique correspondant à un sous-graphe, le nombre d’instructions incluses dans chaque chaîne critique étant inférieur ou égal à un nombre maximal prédéfini, et un paramètre d’optimisation étant le nombre de relations entre les instructions de la chaîne critique respective, ledit nombre de relations correspondant à un nombre d’arcs dans le sous-graphe associé ; et
    - un module de recherche (46) configuré pour rechercher une ou plusieurs anomalie(s) temporelle(s) à partir de chaîne(s) critique(s) d’instructions déterminée(s) via la deuxième structure de modélisation.
FR2103046A 2021-03-25 2021-03-25 Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé Active FR3121242B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2103046A FR3121242B1 (fr) 2021-03-25 2021-03-25 Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé
US17/655,243 US20220308885A1 (en) 2021-03-25 2022-03-17 Method and electronic device for monitoring executable code adapted to be executed on a computer platform, and computer program implementing such a method
EP22163858.8A EP4064087A1 (fr) 2021-03-25 2022-03-23 Procédé et dispositif électronique de surveillance d'un code exécutable apte à être exécuté sur une plateforme informatique, et programme d'ordinateur mettant en oeuvre un tel procédé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2103046A FR3121242B1 (fr) 2021-03-25 2021-03-25 Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé
FR2103046 2021-03-25

Publications (2)

Publication Number Publication Date
FR3121242A1 true FR3121242A1 (fr) 2022-09-30
FR3121242B1 FR3121242B1 (fr) 2023-03-24

Family

ID=77021406

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2103046A Active FR3121242B1 (fr) 2021-03-25 2021-03-25 Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé

Country Status (3)

Country Link
US (1) US20220308885A1 (fr)
EP (1) EP4064087A1 (fr)
FR (1) FR3121242B1 (fr)

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
ARAVINDH ANANTARAMAN ET AL: "Virtual simple architecture (VISA): exceeding the complexity limit in safe real-time systems", PROCEEDINGS OF THE 30TH. INTERNATIONAL SYMPOSIUM ON COMPUTER ARCHITECTURE. ISCA 2003. SAN DIEGO, CA, JUNE 9 - 11, 2003; [INTERNATIONAL SYMPOSIUM ON COMPUTER ARCHITECTURE.(ISCA)], LOS ALAMITOS, CA : IEEE COMP. SOC, US, 9 June 2003 (2003-06-09), pages 350 - 361, XP010796942, ISBN: 978-0-7695-1945-6, DOI: 10.1109/ISCA.2003.1207013 *
GABOW HAROLD N: "An efficient reduction technique for degree-constrained subgraph and bidirected network flow problems", PROCEEDINGS OF THE SEVENTH SYMPOSIUM ON DATA COMMUNICATIONS, ACMPUB27, NEW YORK, NY, USA, 1 December 1983 (1983-12-01), pages 448 - 456, XP058567224, ISBN: 978-1-4503-7457-6, DOI: 10.1145/800061.808776 *
LU SIXING ET AL: "Data-driven Anomaly Detection with Timing Features for Embedded Systems", ACM TRANSACTIONS ON DESIGN AUTOMATION OF ELECTRONIC SYSTEMS., vol. 24, no. 3, 1 June 2019 (2019-06-01), US, pages 1 - 27, XP055866943, ISSN: 1084-4309, Retrieved from the Internet <URL:https://dl.acm.org/doi/pdf/10.1145/3279949> [retrieved on 20211129], DOI: 10.1145/3279949 *
M. ASAVOAE ET AL.: "Formai executable models for automatic détection of timing anomalies", WCET, 2018
M. ASAVOAEB. BEN HEDIAM. JAN: "Fonnal Exécutable Models for Automatic Detection of Timing Anomalies", WCET, 2018
O. AMINI ET AL., ON THE APPROXIMABILITY OF SOME DEGREE-CONSTRAINED SUBGRAPH PROBLEMS, 2012
Y.SHILOACH, ANOTHER LOOK AT THE DEGREE CONSTRAINED SUBGRAPH PROBLEM, 1981

Also Published As

Publication number Publication date
US20220308885A1 (en) 2022-09-29
EP4064087A1 (fr) 2022-09-28
FR3121242B1 (fr) 2023-03-24

Similar Documents

Publication Publication Date Title
CA2970551A1 (fr) Procede d&#39;ajustement de la precision d&#39;un programme d&#39;ordinateur manipulant au moins un nombre a virgule
RU2447486C2 (ru) Представление переходов цикла в регистре предыстории переходов с помощью множества бит
EP3371719B1 (fr) Procede de simulation parallele de niveau systeme electronique avec detection des conflits d&#39;acces a une memoire partagee
US8612944B2 (en) Code evaluation for in-order processing
US20200225921A1 (en) Lookup table optimization for programming languages that target synchronous digital circuits
FR2865047A1 (fr) Systeme de generation automatique de codes optimises
EP3182292B1 (fr) Procédé de prédiction d&#39;une donnée a précharger dans une mémoire cache
EP3314420B1 (fr) Procédé d&#39;exécution d&#39;un programme d&#39;ordinateur comportant une fonction paramétrée
EP4042277A1 (fr) Procédé de simulation parallèle reproductible de niveau système électronique mis en oeuvre au moyen d&#39;un système informatique multi-coeurs de simulation à événements discrets
FR2997774A1 (fr) Procede, dispositif et programme d&#39;ordinateur de placement de taches dans un systeme multi-cœurs
FR3121242A1 (fr) Procédé et dispositif électronique de surveillance d’un code exécutable apte à être exécuté sur une plateforme informatique, et programme d’ordinateur mettant en œuvre un tel procédé
US20160239305A1 (en) Branch target buffer column predictor
EP2836913B1 (fr) Dispositif pour générer une signature à l&#39;exécution d&#39;une tâche de programme et méthode de comparaison de flots d&#39;exécution
EP3314421B1 (fr) Procédé d&#39;exécution d&#39;un programme d&#39;ordinateur comportant une fonction paramétrée
Doglio Mastering Python High Performance
EP1082656A1 (fr) Procede generique d&#39;aide au placement d&#39;applications de traitement de signal sur calculateurs paralleles
FR3012896A1 (fr) Procede de validation du temps de reponse d&#39;une application, procede de deploiement d&#39;une application comportant un tel procede de validation, programme d&#39;ordinateur et dispositifs correspondants
CA2154852A1 (fr) Procede de detection des sequences completes et des sequences d&#39;echec dans un systeme de reconnaissance de situations
CN115391793B (zh) 一种基于FlowDroid工具的实时漏洞检测系统、方法与存储介质
US10902169B1 (en) Functional coverage enhancement in portable stimulus graphs
EP4293564A1 (fr) Calendrier de fautes pour accélération de l&#39;analyse de fiabilité des circuits intégrés
Jing et al. A precision-tunable CFG reconstruction algorithm
CN114003275A (zh) 一种代码克隆的检测方法、装置及存储介质
FR3103590A1 (fr) Procédé de construction d’une signature caractéristique des accès, par un microprocesseur, à une mémoire
EP2737424A1 (fr) Procédé de caractérisation de sensibilité d&#39;un composant électronique pour procédé de conception d&#39;équipement électronique

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20220930

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4