Notre approche : regroupement d'accès au cache

Notre approche part du constat, que nous montrerons, que les principaux leviers de per- formance d'un cache dans notre contexte ne sont ni la politique de remplacement, ni la gestion anticipée des défauts de cache. De plus, nous montrerons également que le goulot d'étranglement se situe dans le nombre d'accès au cache et non sur une gestion optimale de l'alimentation du cache.

Néanmoins, un cache, dont la forme reste à dénir pour notre contexte, est indéniable- ment un composant qui permet de résoudre une bonne partie de notre problématique. Les usages qui en sont fait dans des cas similaires et depuis des décennies le prouvent.

Malheureusement, une carte à puce n'a ni cache d'instructions, ni susamment de mémoire vive pour adopter pleinement les approches de la section 3.3.1, page 29. La conception d'une interface d'exécution en place dans une carte à puce doit donc être encore plus radicale, et doit prioritiser dans l'ordre : empreinte mémoire, ecacité, et accessibilité. Bien que cette dernière soit déjà facilement réalisable, comme cela a déjà été discuté.

Fort de nos constats sur l'état de l'art et sur les lacunes des caches, il nous est apparu que l'idée de grouper des requêtes pour eectuer un seul accès au cache permettrait de mutualiser des cycles CPU. Cette approche par regroupement d'accès pose de nouveaux problèmes que nous allons décrire ici. Nous donnons ensuite des pistes susceptibles de les résoudre.

3.3.3.1 Contraintes structurelles d'un cache

L'intuition est qu'un premier accès au cache pour une instruction de tête permet l'accès direct aux autres instructions du bloc de base sans autres interventions du gestionnaire de cache. Ce qui revient à accéder au contenu du cache en outre-passant son interface logicielle. Hélas, il n'est pas possible de rester cohérent dans la durée avec une telle approche.

Prenons comme point de départ un opérateur d'exécution - un processeur, ou une JVM - , ayant besoin d'accéder à une valeur K à l'adresse virtuelle @virt. Imaginons ensuite que le cache, au lieu de renvoyer K, renvoie l'adresse physique @phy{P0+8}, un oset dans la page n◦0 du cache, en RAM, où se trouve une copie de la valeur K. Si maintenant le pointeur d'instruction (IP) courant de l'opérateur d'exécution est redirigé vers @phy{P0+ 8}plutôt que @virt, on peut penser  naïvement  que le programme puisse continuer son exécution sans devoir à nouveau requêter le cache, simplement en incrémentant IP comme il se doit. Or, ce principe de fonctionnement est invalide car, de fait, rien n'indique que IP continue à lire et exécuter du code valide au-delà de @phy{P0+ 8}. Tout simplement parce que cette adresse est une adresse dans une page de cache, et que @virt+ 1peut en réalité se trouver dans une autre page de cache, à l'adresse @phy{P5+ 0} par exemple, et non à @phy{P0+ 9}. Ce phénomène est dû à la politique de remplacement et aux branchements dans le programme qui font que deux pages de cache adjacentes physiquement se retrouvent inévitablement6 _{à contenir des copies de blocs de données non-contigües du binaire du} programme.

Dans ce cas, l'opérateur d'exécution ne sait pas qu'il n'évolue plus sur une plage d'adresses physiques continues et son comportement devient alors indéterminé. À ce stade, la seule parade est donc d'eectuer un accès au cache par son interface logicielle pour chaque in- struction ou opérande à récupérer.

3.3.3.2 Vers une découverte dynamique de groupes d'accès

La seule lacune de l'approche décrite ci-dessus est l'absence d'une information de termi- naison claire et précise qui indiquerait à l'opérateur d'exécution que l'incrément de IP sort d'une plage d'adresses physiques continues. Cette information de terminaison est soumise à de deux cas de gures.

• Le premier cas de gure intervient lorsque IP pointe vers un rupteur de ot de contrôle sortant de la page de cache courante.

• Le second cas de gure est la détection d'une n de page de cache. C'est-à-dire détecter que IP nit par pointer vers l'adresse physique du dernier octet de la page de cache courante, qui peut ne pas être un rupteur de ot de contrôle.

Ces deux informations de terminaison ne sont détectables que par l'analyse du graphe de ot de contrôle. En cherchant à identier des plages d'adresses physiques continues à l'intérieur du cache, nous cherchons implicitement à former des groupes d'instructions qui pourrait être exécutés de manière séquentielle. La découverte de plages d'adresses continues peut être résolue en cherchant à reconstituer articiellement un bloc de base par analyse du graphe de ot de contrôle, information perdue une fois que le binaire est compilé. - Recherche de groupes hors-ligne - Réaliser cette analyse hors-ligne est envisage- able simplement, car elle s'apparente aux travaux sur le pré-chargement et l'injection d'informations à la compilation. À ce stade de la vie d'un programme, bon nombre d'informations requises sont disponibles. Le premier inconvénient de cette approche est l'augmentation de l'empreinte mémoire dûe aux nouvelles données accompagnant le binaire exécutable. Le second, plus important, est que le cas de gure n◦2 ne peut être entièrement satisfait sans une connaissance globale de la conguration et du type de cache, ainsi que les propriétés de la mémoire secondaire. Ce qui implique que dans la post-issuance, une application téléchargeable doit être compilée autant de fois que de couples cache/matériel possibles. Ce qui est une contrainte impossible à mettre en application, et qui n'est pas du tout l'approche et l'esprit de Java et JavaCard par exemple.

- Recherche de groupes en-ligne - Réaliser l'analyse en-ligne du graphe de ot de contrôle est donc une meilleure approche, car les informations sur le cache et les propriétés de la mémoire secondaire sont ici connues. Tout comme dans les travaux déjà présentés sur la sécurité, elle peut être de deux natures : soit réalisée statiquement à l'installation de l'application dans la carte à puce, soit dynamiquement pendant son exécution.

L'analyse statique à l'installation rejoint les propositions de l'état de l'art sur la prob- lématique de sécurité posée par la post-issuance (section 2.1.5.1, page 9). Si le domaine d'application est diérent, elles montrent que l'analyse de code en-ligne est une solution encartable. Ce qui permet de conclure qu'il n'y a donc a priori pas de frein à d'autres usages de l'analyse du graphe de ots de contrôle en-ligne, si ce n'est bien-sûr l'eort à fournir pour la rendre viable dans une carte.

Appliquer l'analyse statique dès l'installation à notre approche ore les même avantages mais aussi les même inconvénients que dans le cadre de la sécurité. Toutefois, à la diérence de la vérication du code par exemple, nous avons par contre besoin de garder l'information produite par l'analyse, ce qui va à l'encontre d'une empreinte mémoire attendue faible. Sans connaître pour l'instant la taille unitaire d'une de ces informations à mémoriser, on peut déjà noter que leur somme sera proportionnelle au nombre de blocs de base, voire plus, pour pouvoir mémoriser également les blocs tronqués par des n de pages. À titre d'information,

le nombre moyen de blocs de base dans une application JavaCard est de 54 (sans les ns de pages), qui est lui-même à multiplier par le nombre d'applications encartées. Ce qui peut facilement doubler l'empreinte mémoire d'un cache de 512 octets.

C'est pourquoi nous proposons plutôt une approche de recherche d'informations sans mémorisation par une analyse statique en-ligne du graphe de ot de contrôle mais eectuée dynamiquement pendant l'exécution des programmes.

3.3.3.3 Méthode de découverte dynamique des groupes

Notre approche pour combler les lacunes d'un cache repose donc sur une analyse du code, en-ligne. Le but est d'identier des plages d'adresses physiques continues, exécutables séquentiellement, et sans accès intermédiaire à l'interface du cache. Comme discuté, cette identication correspond à la découverte de groupes d'instructions qui sont soit des blocs de base complets, soit des blocs de base tronqués lorsqu'ils sont répartis dans plusieurs pages de cache.

Le principe est donc de ne réaliser qu'un seul accès au cache, sur l'instruction de tête, et trouver par analyse de quoi garantir que le bloc de base courant peut être exécuté sans autres accès à l'interface du cache. De plus, dans cette approche, une fois la garantie trouvée, le bénéce s'étend au fait que seules les instructions de tête sont susceptibles de déclencher des défauts de cache.

Principe de fonctionnement Dans notre approche, une analyse de code est déclenchée à chaque exécution d'une instruction de tête. Elle est utilisée pour rechercher les ns de blocs de base et donc les deux types de terminaisons de plages d'adresses mentionnée précédem- ment. Notre approche ore une autre optimisation en permettant de greer facilement à l'analyse un mécanisme de pré-chargement de pages. Elle permet en eet de découvrir de manière précoce si une information est présente en cache ou non et donc d'anticiper sa récupération.

Guides de conception Une telle approche pose les mêmes problèmes que tout algorithme dynamique d'analyse, à savoir le rapport entre son coût et son gain. Ici, le gain espéré est la réduction du coût total des accès au cache en ne l'utilisant qu'avec plus de parcimonie. Tandis que le coût principal de notre approche est celui de l'analyse de code. Le rapport gain/coût s'articule donc autour du nombre d'analyses eectuées et du nombre d'accès au cache évités, rapport décrit sous forme d'inéquation dans la formule ci-dessous.

Inéquation 1. Seuil de rentabilité de notre approche 





CoˆutAnalyses < CoˆutAcc`es−´evit´es

CoˆutAnalyses = TAnalyse∗ NAnalyse+ ∆

CoˆutAcc`es = NAcc`es∗ (TRecherche+ TGestionHit)

De manière générale, concevoir une méthode de découverte dynamique d'informations dépend fondamentalement du type d'informations à collecter. Elle dépend bien entendu également du type de données à analyser, et enn et surtout, du contexte dans lequel évolue d'une part l'analyse elle-même et d'autre part les données analysées.

Le type d'informations à analyser et leurs contextes d'utilisation seront étudiés dans les chapitre 4 pour du code compilé, et chapitre 5 pour des méta-données Java, qui sont les deux types de données en jeu dans l'exécution de code dans une carte à puce. Ces deux

chapitre seront également l'occasion d'évaluer l'utilisation d'un cache logiciel, qui reste le socle de notre approche.

L'élaboration, la conception et l'implémentation de notre approche, ainsi que la mesure de ses bénéces sont ensuite détaillées dans le chapitre 6.