Partitionnement de la mémoire et mécanismes de sécurité fonctionnelle mis en œuvre

1. Logiciel d'application

Dans l'architecture AUTOSAR, le logiciel d'application est situé au-dessus du RTE et se compose de SWC AUTOSAR interconnectés. Ces composants encapsulent atomiquement divers composants de la fonctionnalité du logiciel d'application.

Figure 1 : Logiciel d'application

AUTOSAR SWC est indépendant du matériel et peut donc être intégré sur n'importe quel matériel ECU disponible. Pour faciliter l'échange d'informations au sein et au sein du calculateur, AUTOSAR SWC communique uniquement via RTE.

AUTOSAR SWC contient de nombreuses fonctions et variables qui fournissent des fonctionnalités internes. La structure interne d'AUTOSAR SWC, à savoir ses variables et ses appels de fonction, est cachée au public via les fichiers d'en-tête. Seuls les appels RTE externes prendront effet sur l'interface publique.

Figure 2 : SWC

AUTOSAR SWC contient également des fonctions qui doivent être appelées au moment de l'exécution. Ces fonctions C sont appelées Runnables dans AUTOSAR.

Les Runnables ne peuvent pas être exécutés par eux-mêmes ; ils doivent être affectés à une entité exécutable du système d'exploitation. De telles allocations peuvent être effectuées en insérant des appels de fonction de Runnables dans le corps de la tâche du système d'exploitation.

Les Runnables sont ensuite exécutés en boucle et/ou pilotés par des événements dans le contexte de la tâche OS appelante. L'allocation des tâches par Runnables est effectuée selon les figures 3 et 4.

​

Figure 3 : Architecture logicielle en couches AUTOSAR - cartographie des Runnables

2 OS-Applications

La figure 4 montre l'explication de la relation dans la figure 3. Selon ce diagramme, les Runnables dans AUTOSAR SWC sont affectés aux tâches du système d'exploitation.

Figure 4 : Mappage SWC vers les applications du système d'exploitation

Les applications du système d'exploitation AUTOSAR sont un ensemble d'objets du système d'exploitation (tels que des tâches, des ISR, des planifications, des compteurs et des alarmes) qui forment un ensemble cohérent. unité fonctionnelle. Tous les objets appartenant aux mêmes applications OS peuvent accéder les uns aux autres.

Les objets OS dans les applications OS peuvent appartenir à différents SWC AUTOSAR. RTE implémente une zone mémoire à laquelle tous les membres des applications OS ont un accès illimité pour faciliter une communication efficace entre les SWC.

Les applications OS sont de deux catégories :

1. Applications OS de confiance : "Les applications OS de confiance sont autorisées à s'exécuter avec des fonctionnalités de surveillance ou de protection désactivées au moment de l'exécution. Elles peuvent fonctionner sans restriction avec les API qui accèdent à la mémoire et Les modules du système d'exploitation. Les applications du système d'exploitation approuvées ne sont pas tenues d'appliquer leur comportement de synchronisation au moment de l'exécution, et elles sont autorisées à s'exécuter en mode privilégié lorsqu'elles sont prises en charge par le processeur. avec des fonctionnalités de surveillance ou de protection désactivées au moment de l’exécution n’est pas autorisé. Ils restreignent l'accès à la mémoire, restreignent l'accès à l'API du module du système d'exploitation et appliquent son comportement de synchronisation au moment de l'exécution. Ils ne sont pas autorisés à s'exécuter en mode privilégié lorsque le processeur le prend en charge.
2. 3. Communication et partage de code

Selon la figure 4 et la figure 3, une application du système d'exploitation peut contenir plusieurs SWC AUTOSAR et les exécutables associés. Seuls les Runnables sont autorisés à accéder directement aux variables et à effectuer des appels de fonction dans leurs SWC respectifs.

Les appels de fonctions internes et les variables de SWC ne sont pas accessibles publiquement aux autres SWC car leurs définitions ne sont pas fournies par les fichiers d'en-tête des interfaces externes, il n'est donc pas possible de prévoir de communiquer directement via des variables et d'exécuter le code d'autres SWC.

Dans la figure 5, l'exemple de partage de code illustre cela. Le partage de code n'est autorisé qu'au sein d'un SWC et ne peut pas être partagé entre les SWC d'une application OS. La communication avec les autres SWC doit s'effectuer via RTE. Runnable4 peut ne pas être en mesure d'exécuter les fonctions appartenant à SWC2.2.

​

Figure 5 : Partage de code dans les applications du système d'exploitation

4. Partition de mémoire dans le logiciel d'application

Le logiciel d'application dans l'ECU AUTOSAR peut être composé de SWC et de non-liés à la sécurité. composants SWC liés à la sécurité. L'absence d'interférence entre les SWC avec différents niveaux ASIL doit être garantie conformément aux exigences de la norme ISO26262.

AUTOSAR OS est immunisé contre les pannes liées à la mémoire en plaçant les applications du système d'exploitation dans des zones de mémoire exclusives. Ce mécanisme est appelé partitionnement de la mémoire. Les applications OS sont protégées les unes des autres car le code exécuté dans la partition mémoire d'une application OS ne peut pas modifier les autres zones de mémoire. Les exigences correspondantes dans la spécification AUTOSAR OS sont présentées dans le tableau 1.

Tableau 1 : Partition de mémoire des applications AUTOSAR OS-OS

Le logiciel d'application peut être composé de SWC avec différents niveaux ASIL. Cependant, les SWC avec des classifications ASIL différentes ne doivent pas être attribués aux mêmes applications OS. Le partitionnement de la mémoire n'offre pas d'immunité aux interférences entre les SWC affectés aux mêmes applications de système d'exploitation. Le système d'exploitation empêche uniquement d'autres applications du système d'exploitation d'effectuer un accès incorrect. N'empêche pas un SWC défectueux de modifier les zones de mémoire d'autres SWC dans les mêmes applications OS.

REMARQUE : Voir le partitionnement ultérieur pour plus de détails sur le partitionnement au niveau des tâches.

5. Partitionnement de la mémoire dans SWC

ASIL SWC mixte peut être constitué de Runnables avec différentes classifications ASIL, donc un environnement d'exécution qui ne prend en charge aucune interférence entre ces Runnables est requis. Il n'est pas possible d'exécuter différents Runnables d'un SWC dans différentes partitions de mémoire pour les raisons suivantes :

Les partitions de mémoire sont exécutées au niveau des applications du système d'exploitation. Comme le montrent les figures 3 et 4, un SWC ne peut être alloué qu'à une seule application du système d'exploitation, il n'y a donc qu'une seule partition de mémoire. De plus, les SWC Runnables ne peuvent être appelés que par une tâche des applications OS.

Comme le montre la figure 6, les SWC Runnables ne peuvent pas être distribués aux tâches de plusieurs applications OS.

Figure 6 : SWC et partitions

Les partitions de mémoire ne peuvent pas être utilisées pour séparer les Runnables dans le même SWC. S'il est nécessaire que le SWC contienne des Runnables avec différents ASIL et que ces Runnables doivent être exécutés indépendamment sans interférence, alors le partitionnement de la mémoire au niveau des applications du système d'exploitation n'est pas suffisant, le partitionnement de la mémoire doit être effectué au niveau des tâches. La méthode est illustrée à la figure 7.

Figure 7 : Partitionnement au niveau des tâches

Les exigences liées au partitionnement de la mémoire au niveau des tâches sont répertoriées dans la spécification du système d'exploitation AUTOSAR dans le tableau 2. L'utilisation du mot faible « peut » indique que la mise en œuvre du partitionnement au niveau des tâches est facultative pour AUTOSAR OS. Par conséquent, toutes les implémentations du système d’exploitation AUTOSAR ne prennent pas en charge le partitionnement de la mémoire au niveau des tâches.

Tableau 2 : Exigences du système d'exploitation AUTOSAR – Partitionnement de la mémoire au niveau des tâches

6. Implémentation du partitionnement de la mémoire

Divers concepts de sécurité techniques peuvent être implémentés au niveau du système et du logiciel en utilisant le partitionnement de la mémoire mécanisme .

La figure 8 montre une implémentation possible, tandis que tous les modules logiciels sous-jacents sont exécutés dans une partition mémoire en mode sécurisé/surveillé (surlignée en rouge dans la figure 8). Certains SWC sont regroupés logiquement et placés dans des partitions de mémoire distinctes non approuvées/en mode utilisateur (surlignées en vert). Le module logiciel sélectionné appartient à la même partition mémoire en mode sécurisé/géré que le module logiciel de base (voir le quatrième SWC surligné en rouge dans la figure 8). Il peut y avoir plusieurs partitions non fiables/en mode utilisateur, chacune contenant un ou plusieurs SWC.

L'exécution de SWC dans des partitions de mémoire non fiables/en mode utilisateur sera restreinte et ne pourra pas modifier d'autres zones de mémoire, tandis que l'exécution de SWC dans des partitions de mémoire de programme fiables/surveillées n'est pas restreinte.

Les microcontrôleurs modernes utilisés pour les applications liées à la sécurité prennent en charge le partitionnement de la mémoire via un matériel dédié (Memory Protection Unit (MPU)).

REMARQUE : Il est supposé que le découpage de la mémoire sera implémenté sur un microcontrôleur doté d'un MPU ou de capacités matérielles similaires.

Avec les implémentations MPU typiques, une application non fiable peut être autorisée à accéder à plusieurs partitions de l'espace d'adressage du microcontrôleur. Le contrôle d'accès est défini comme une combinaison d'accès en lecture, en écriture et en exécution. La configuration du MPU n'est autorisée qu'en mode moniteur.

REMARQUE : Dans certaines implémentations de microcontrôleurs, le MPU est intégré au cœur du processeur. Par conséquent, le MPU contrôle uniquement l’accès au cœur associé. Les autres maîtres de bus (tels que les contrôleurs DMA et autres cœurs) ne sont pas contrôlés par cette instance MPU segmentée.

Le tableau et les cas d'utilisation ci-dessous illustrent un ensemble de scénarios possibles lorsque la configuration de l'unité de protection de la mémoire est dérivée de la configuration système requise. REMARQUE : Ce tableau peut ne pas être complet en ce qui concerne les capacités du périphérique matériel spécifique utilisé.

Tableau 3 : Schéma de configuration de la protection de la mémoire ​

Description de l'icône :

Remarque : du point de vue des performances, il peut y avoir des effets secondaires dus à un conflit de bus ou à l'interface. arbitrage, etc.

Cas d'utilisation 1 : SWC est dans la même partition.

Les SWC d'une même partition peuvent accéder aux zones RAM de chacun et peuvent donc corrompre le contenu de la mémoire de chacun.

Par définition, les SWC ne peuvent pas accéder aux périphériques car ils ne devraient pas connaître l'architecture sous-jacente du microcontrôleur. Lorsque SWC est autorisé à accéder directement aux périphériques, un système non sécurisé peut être créé.
• Cas d'utilisation 2 : SWC dans différentes partitions.
• Les SWC de différentes partitions ne peuvent pas accéder aux zones RAM les uns des autres et ne peuvent donc pas corrompre le contenu de la mémoire de chacun.
  
Par définition, les SWC ne peuvent pas accéder aux périphériques car ils ne devraient pas connaître l'architecture sous-jacente du microcontrôleur. Lorsqu'un SWC bénéficie d'un accès direct à un périphérique, un système potentiellement non sécurisé peut être créé.
• Cas d'utilisation 3 : Pilote MCAL
• Le pilote MCAL est un ensemble de fonctions telles que la lecture/écriture/initialisation. Ils doivent être exécutés par une autre entité, telle que BSW ou CDD. Voir la figure 8 pour plus de détails.
  
Le pilote MCAL nécessite un accès en lecture/écriture à l'espace périphérique du module matériel périphérique correspondant. Selon l'architecture matérielle, un mode moniteur du processeur peut également être requis.
2.1.3 Détection et réponse
• Mécanisme de sécurité fonctionnel Le partitionnement de la mémoire offre une protection en limitant l'accès à la mémoire et au matériel mappé en mémoire. Le code exécuté dans une partition ne peut pas modifier la mémoire d'une autre partition. Les partitions de mémoire peuvent protéger les segments de mémoire en lecture seule, ainsi que le matériel mappé en mémoire. De plus, les SWC exécutés en mode utilisateur ont un accès restreint aux instructions du processeur, telles que la reconfiguration.

Le mécanisme de partitionnement de la mémoire peut être mis en œuvre avec le support du matériel du microcontrôleur (tel qu'une unité de protection de la mémoire ou une unité de gestion de la mémoire). Le matériel du microcontrôleur doit être correctement configuré par le système d'exploitation pour détecter et empêcher les accès incorrects à la mémoire. Surveillez ensuite l'exécution de SWC dans la partition mémoire non fiable/en mode utilisateur.

S'il y a une violation d'accès à la mémoire ou un conflit d'instructions CPU dans une partition non approuvée/en mode utilisateur, l'accès erroné sera bloqué et le matériel du microcontrôleur lèvera une exception. OS et RTE éliminent les partitions logicielles erronées en effectuant un arrêt de la partition ou en redémarrant toutes les partitions logicielles de cette partition.

REMARQUE : La réponse réelle du système d'exploitation peut être configurée via l'implémentation du hook de protection. Consultez la documentation du système d'exploitation SWS[i] pour plus de détails.

REMARQUE : Le document AUTOSAR « Instructions de gestion des erreurs au niveau de l'application »[ii] fournit des informations supplémentaires sur la gestion des erreurs. La documentation explique comment le traitement des erreurs est effectué et où les données requises (par exemple les valeurs de remplacement) peuvent être obtenues. De plus, ce document fournit des instructions détaillées (Manuel d'utilisation) sur la façon d'effectuer la terminaison et le redémarrage des applications du système d'exploitation/partition dans AUTOSAR.

2.1.4 Limitations

1. Partitions de mémoire des SWC avec le même classement ASIL.

La norme ISO26262 exige l'absence d'interférences entre les SWC de différents niveaux ASIL [iii]. Cependant, la norme n'exige pas l'immunité aux interférences entre les SWC ayant le même classement ASIL.

Permet l'utilisation d'applications OS composées d'un grand nombre de SWC. Si un seul SWC provoque un conflit entraînant l'arrêt ou le redémarrage d'une partition de mémoire entière, tous les autres SWC fonctionnels pour cette partition de mémoire seront également affectés.

2. Le partitionnement de la mémoire n'est pas disponible pour les applications de système d'exploitation fiables.

L'exécution des partitions de mémoire en mode sécurisé/surveillé n'est pas contrôlée par le système d'exploitation et certaines implémentations matérielles MMU/MPU.

3. Le niveau de tâche ne prend pas en charge le partitionnement de la mémoire.

La mise en œuvre du partitionnement au niveau des tâches n'est pas nécessaire pour la mise en œuvre du système d'exploitation AUTOSAR. Par conséquent, l'immunité aux interférences dans les applications OS peut ne pas être prise en charge.

4. Perte de performances due au partitionnement de la mémoire.

En fonction de l'architecture du logiciel d'application et de la mise en œuvre du matériel du microcontrôleur et du système d'exploitation, l'utilisation de partitions de mémoire peut réduire les performances. Cette pénalité augmente avec le nombre de changements de contexte effectués par unité de temps.

5. Pas de partition logicielle de base.

La spécification actuelle du logiciel de base ne spécifie pas le partitionnement de la mémoire pour les SWC de base avec différents niveaux ASIL provenant de différents fournisseurs.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!