maps

Micro-Architectural Power Simulator (MAPS) pour Cortex-M3

Aperçu

Simulator Fast Cortex-M3 qui crée des traces de puissance. Plus d'informations peuvent être trouvées dans https://eprint.iacr.org/2017/1253.pdf

• Écrit en C ++ pour la vitesse
• lit et simule un fichier .bin créé à partir d'une source d'assemblage / c avec une chaîne d'outils GNU ARM

Seules les instructions généralement trouvées dans le codage des primitives cryptographiques sont prises en charge. Des instructions non soutenues peuvent être ajoutées dans CPU.CPP.

Compilation

1. Simulator de compilation: le simulateur (y compris) la fonction principale, est stocké dans une bibliothèque statique.
2. CD Libsim / Build
3. faire
4. faire l'installation
5. Compiler un firmware d'implémentation. Nous utilisons SEC_ADD_V05 comme exemple:
6. cd sec_add_v05 / fw / build
7. faire
8. Compilez un simulateur d'implémentation (toujours en utilisant SEC_ADD_V05 comme exemple):
9. cd sec_add_v05 / sim / build
10. faire

Utilisation du simulateur

Le simulateur a lu un fichier .bin qui doit être situé dans le répertoire actuel. Le nom du fichier .bin dépend de ce qui a été spécifié dans les sources du simulateur.

Le simulateur est censé être utilisé lors du développement du firmware, de sorte que la façon habituelle d'exécuter une simulation est de

1. Modifier le répertoire dans le répertoire du firmware: CD SEC_ADD_V05 / FW / BUILD
2. Exécutez le simulateur: ../../sim/build/sim_sec_add_v05 -n 1000

L'option '-H' affiche les options et paramètres valides.

Codage d'une nouvelle implémentation FW

Une implémentation FW est simplement une fonction C (contenant éventuellement le code d'assemblage), suivant le bras ABI (1er paramètre en R0, etc ...) il n'y a pas de fonction principale. Toutes les fonctionnalités C et pré-processeurs peuvent être utilisées.

Le firmware peut être compilé par n'importe quel compilateur ARM prenant en charge le Cortex-M3. Seul ARM GCC a été testé. Le chemin d'accès à l'exécutable du compilateur ARM peut être modifié dans scripts / fw.mak en modifiant la variable "dir".

Codage d'un nouveau simulateur

Il est préférable de démarrer et de modifier un simulateur déjà existant. Le simulateur doit contenir 3 fonctions:

1. void check_sec_algo (void): Cette fonction applique certains vecteurs de test et imprime si le test passe ou non.
2. void t_test_sec_algo (options et options): cette fonction exécute le t_test en générant des entrées et en collectant des traces
3. Un wrapper pour appeler la fonction FW (qui sera simulé). Cet emballage (dont la signature dépend de la fonction FW) doit écrire les arguments dans la mémoire du simulateur et définir les registres du processeur en conséquence. Ensuite, cela commence la simulation. Après la simulation, il doit copier les résultats de la mémoire simulée.

Soutenir plus d'instructions ARM V7-M

Suivez ces étapes pour prendre en charge une instruction dans le simulateur:

1. Ajoutez les valeurs de décodage et de masque dans le fichier libsim / src / opcodes.h
2. Décoder l'instruction dans l'étape de fonction () dans libsim / src / cpu.cpp
3. Ajouter l'exécution de la fonction dans le même fichier
4. N'oubliez pas d'ajouter cette nouvelle fonction à la liste des méthodes dans CPU.H

Les macros test_ins32 et test_ins16 simplifient également le décodage de l'instruction, n'oubliez pas de valider le comportement de la nouvelle instruction simulée, en particulier le comportement des registres du pipeline Reg_a et Reg_B!

Validations

Chaque instruction soutenue par le simulateur doit être validée par rapport à la simulation RTL. L'arbre RTL n'est pas stocké dans ce référentiel car il appartient à Arm Limited. La majeure partie de la procédure décrite ci-dessous n'est là que pour ma propre documentation.

1. Ajoutez la nouvelle instruction dans le fichier Experiment.c dans l'arbre du simulateur
2. Exécuter Faire vérifier> sim_trace.log 2> & 1 dans la direction FW Build dans l'arborescence du simulateur
3. Ajoutez la nouvelle instruction dans le fichier fuite.c dans l'arborescence RTL
4. Compiler: faire un test de test de test = fuite
5. Simuler: Faire Run TestName = fuite
6. Convertir le fichier de trace tarmac.log en fichier de trace de registre: ../../../../../python/gen_trace.py> Verilog_trace.log
7. Copiez le fichier de trace de registre dans l'arborescence du simulateur: CP ~ / Documents / Repos / Maps / Rendered / SSE050 / Logical / TestBench / Execution_TB / Verilog_Trace.log.
8. Comparez la trace du simulateur et la trace RTL. Soit visuellement à l'aide de gvim -d sim_trace.log verilog_trace.log, soit en utilisant: ./../../python/compare_traces.py

Bogues / limitations

Les limitations savent que les limitations sont:

• Le pipeline pour les instructions LDRB / STRB est plus complexe que ce qui est implémenté dans le simulateur. Par exemple, pour le code suivant:

 ldrb r2, [r0]
strb r2, [r0]

Reg_a et Reg_b ne seront pas simulés correctement par le simulateur. La fonctionnalité est toujours correcte cependant. Lorsqu'une autre instruction est insérée entre le LDRB et les instructions STRB, la simulation est correcte.