Blog 10 min de lecture

Maîtriser MISRA C++ : top 10 des règles critiques de sécurité pour les systèmes embarqués

Share this article
Maîtriser MISRA C++ : top 10 des règles critiques de sécurité pour les systèmes embarqués

Dans les systèmes embarqués et temps réel, les défaillances logicielles ne sont pas de simples pannes techniques : elles peuvent entraîner des blessures physiques, des violations de données catastrophiques ou la perte complète d'une mission. Parce que C++ donne aux développeurs un accès bas niveau aux registres matériels et aux pointeurs, il offre aussi de nombreuses occasions d'introduire des comportements indéfinis, des corruptions de mémoire et des vulnérabilités de sécurité subtiles.

Pour éliminer ces risques, les responsables d'ingénierie et les industries critiques en matière de sécurité s'appuient sur MISRA C++.

Qu'est-ce que MISRA C++ ?

MISRA (Motor Industry Software Reliability Association) a initialement développé des normes de codage C et C++ pour garantir une exécution logicielle sûre, fiable et prévisible dans les ECU de véhicules critiques. Aujourd'hui, MISRA C++ est la référence internationale pour restreindre rigoureusement le langage C++ — en éliminant les fonctionnalités dangereuses, la syntaxe ambiguë et les comportements indéfinis.

Plutôt que de servir de simple guide de formatage, les règles MISRA ciblent les causes profondes des bogues logiciels :

  • Sécurité mémoire : élimination des débordements de tampon, de l'use-after-free et des corruptions de pile.
  • Exécution déterministe : prévention de la fragmentation dynamique du tas et des exceptions non traitées.
  • Sécurité des types : blocage des troncatures silencieuses et des casts implicites dangereux.

Quelles industries exigent la conformité MISRA ?

La conformité MISRA C++ est imposée dans un large éventail de secteurs critiques et fortement réglementés :

  • Automobile (ISO 26262) : utilisée par les constructeurs et les équipementiers de rang 1 (p. ex. Stellantis, BMW, Bosch) pour les unités de contrôle moteur, la perception ADAS, le freinage électronique et les architectures de véhicule défini par logiciel (SDV).
  • Aérospatiale et avionique (DO-178C) : calculateurs de commandes de vol, systèmes de détermination d'attitude des satellites et modules de guidage de fusées.
  • Dispositifs médicaux (IEC 62304) : pompes à insuline automatisées, stimulateurs cardiaques, robotique chirurgicale et ventilateurs.
  • Systèmes ferroviaires (EN 50128) et défense : réseaux de signalisation, plateformes de défense autonomes et automatisation industrielle lourde.

Top 10 des règles MISRA C++ critiques pour la sécurité

Voici 10 principes MISRA C++ essentiels classés par criticité sécurité, avec des exemples non conformes et des corrections C++ modernes et sûres pour prévenir les vulnérabilités bas niveau dans les dispositifs embarqués.

1. Restreindre l'arithmétique des pointeurs et garantir la sécurité des bornes

Menace de sécurité : Débordements de tampon, exploits de manipulation de pointeurs et corruptions mémoire hors limites.

❌ Non conforme :

void processBuffer(uint8_t *ptr, size_t len) {
    for (size_t i = 0; i <= len; ++i) { // Bug: <= allows out-of-bounds write
        *(ptr + i) = 0;
    }
}

✅ Correction conforme :

#include <span>
void processBuffer(std::span<uint8_t> buffer) {
    for (auto &val : buffer) {
        val = 0; // Bounds-safe container iteration
    }
}

2. Toutes les variables doivent être initialisées avant utilisation

Menace de sécurité : Divulgation d'informations, comportement indéfini et exploits de mémoire non initialisée.

❌ Non conforme :

void authenticateUser() {
    bool isAuthenticated; // Uninitialized stack memory containing garbage data
    if (checkToken()) {
        isAuthenticated = true;
    }
    if (isAuthenticated) { // Undefined behavior if checkToken() returns false
        grantAccess();
    }
}

✅ Correction conforme :

void authenticateUser() {
    bool isAuthenticated = false; // Explicit default initialization
    if (checkToken()) {
        isAuthenticated = true;
    }
    if (isAuthenticated) {
        grantAccess();
    }
}

3. L'allocation dynamique sur le tas doit être restreinte ou évitée

Menace de sécurité : Déni de service (DoS) par épuisement du tas, fuites mémoire et délais d'allocation non déterministes.

❌ Non conforme :

void handleMessage(const char *data, size_t length) {
    char *buffer = new char[length]; // Dangerous heap allocation per message
    // process buffer...
    delete[] buffer;
}

✅ Correction conforme :

#include <array>
void handleMessage(const char *data, size_t length) {
    std::array<char, 256> staticBuffer; // Stack-allocated or statically pooled
    if (length < staticBuffer.size()) {
        // process safely without dynamic heap calls
    }
}

4. Aucune conversion implicite de type entraînant une perte de données

Menace de sécurité : Troncature d'entiers, erreurs de bouclage (wrap-around) et exploits de débordement de tampon.

❌ Non conforme :

void parseHeader(uint32_t declaredLength) {
    uint8_t bufferSize = declaredLength; // Implicit narrowing: 512 truncated to 0!
    uint8_t *dest = new uint8_t[bufferSize];
}

✅ Correction conforme :

void parseHeader(uint32_t declaredLength) {
    if (declaredLength > 255) {
        return; // Guard against truncation and invalid input
    }
    uint8_t bufferSize = static_cast<uint8_t>(declaredLength);
}

5. L'accès aux données volatile doit être géré correctement

Menace de sécurité : Conditions de concurrence, événements matériels manqués et contournements de vérifications de sécurité dus à la mise en cache des registres par les optimisations du compilateur.

❌ Non conforme :

uint32_t *const AuthStatusReg = reinterpret_cast<uint32_t*>(0x40001000);
void verifySecurityGate() {
    if (*AuthStatusReg == 0x1) { // Compiler may cache read value in a CPU register
        unlockDevice();
    }
}

✅ Correction conforme :

volatile uint32_t *const AuthStatusReg = reinterpret_cast<volatile uint32_t*>(0x40001000);
void verifySecurityGate() {
    if (*AuthStatusReg == 0x1) { // Forces hardware re-read on every execution
        unlockDevice();
    }
}

6. Éviter le comportement indéfini dans les opérations bit à bit

Menace de sécurité : Angles morts des optimisations du compilateur, débordement de registres à décalage et corruption logique.

❌ Non conforme :

uint32_t shiftRegister(uint32_t val, int bits) {
    return val << bits; // Undefined behavior if bits < 0 or bits >= 32
}

✅ Correction conforme :

uint32_t shiftRegister(uint32_t val, int bits) {
    if (bits < 0 || bits >= 32) {
        return 0; // Explicit bounds checking to prevent UB
    }
    return val << bits;
}

7. Appliquer rigoureusement la correction const

Menace de sécurité : Altération accidentelle de la mémoire ou élévation de privilèges par mutation non autorisée de paramètres de configuration statiques.

❌ Non conforme :

struct SystemConfig {
    uint32_t key;
};
void updateConfig(SystemConfig &cfg) {
    cfg.key = 0xDEADBEEF; // Mutable access can be exploited or mutated by mistake
}

✅ Correction conforme :

struct SystemConfig {
    uint32_t key;
};
void inspectConfig(const SystemConfig &cfg) {
    // cfg.key = ...; -> Compiler error: prevents unauthorized mutation
}

8. Éviter le masquage de variables (name hiding)

Menace de sécurité : Confusion logique et contournements d'autorisation causés par le référencement de variables de portée locale au lieu des états globaux voulus.

❌ Non conforme :

int globalAccessLevel = 0;
void processLogin(int accessLevel) {
    int globalAccessLevel = 1; // Shadows global variable!
    // Developer assumes global state is updated, but it remains unchanged.
}

✅ Correction conforme :

int g_AccessLevel = 0;
void processLogin(int inputAccessLevel) {
    g_AccessLevel = inputAccessLevel; // Clear, distinct variable scopes
}

9. Éviter les « nombres magiques »

Menace de sécurité : Failles logiques codées en dur, politiques de sécurité inmaintenables et échecs d'audit.

❌ Non conforme :

void validateUser(uint8_t role) {
    if (role == 3) { // What is 3? Admin? Guest? Superuser?
        grantSuperUserAccess();
    }
}

✅ Correction conforme :

enum class UserRole : uint8_t {
    Guest = 1,
    Operator = 2,
    Administrator = 3
};
void validateUser(UserRole role) {
    if (role == UserRole::Administrator) {
        grantSuperUserAccess();
    }
}

10. Les instructions switch doivent avoir une clause default

Menace de sécurité : Transitions d'automate non traitées ignorant les vérifications de sécurité lors du traitement de valeurs enum matérielles corrompues.

❌ Non conforme :

void handleCommand(ProtocolState state) {
    switch (state) {
        case ProtocolState::Idle:   resetTimer(); break;
        case ProtocolState::Active: processData(); break;
        // Missing default: corrupted enum skips checks silently!
    }
}

✅ Correction conforme :

void handleCommand(ProtocolState state) {
    switch (state) {
        case ProtocolState::Idle:   resetTimer(); break;
        case ProtocolState::Active: processData(); break;
        default:
            triggerSecurityAlarm(); // Catches corrupt or unexpected states safely
            break;
    }
}

Résumé

L'adoption des règles MISRA C++ dans votre pipeline d'analyse statique CI/CD automatisé (comme CppDepend) garantit que la sûreté et la sécurité sont vérifiées à chaque commit — bien avant que le code n'atteigne le matériel physique.

Share this article