Windows Embedded CE 6.0 et la sécurité
Cet article a été écrit par Olivier Bloch,
Responsable Relations Techniques avec les Développeurs.
Windows Embedded CE 6.0 est un système d'exploitation modulaire 32 bits temps
réel supportant de multiples architectures CPUs (ARM, MIPS, SH, x86).
Il est conçu pour être adapté et embarqué dans des systèmes parfois critiques, souvent
interactifs, mais nécessitant le plus souvent un niveau de sécurité et de fiabilité
très élevé.
Cet article décrit les principaux éléments qui font de la version 6.0 de Windows
CE la version la plus sécurisée. Présentant les nouveautés apportées à la gestion
de la mémoire virtuelle et à l'architecture du noyau, il détaille les modes User
et Kernel pour les applications et les drivers avant d'introduire le nouveau modèle
de sécurité 1-Tiers de Windows Embedded CE 6.0. Il présente enfin les outils mis
à disposition du développeur afin de lui permettre le développement d'applications
et de drivers toujours plus sécurisés.
Sommaire
Nouvelle architecture du noyau : séparation des modes User et Kernel
Les drivers : Le User Mode Driver Framework
Protection du système au chargement et à l'exécution de code
Outils, compilateurs et runtimes
Conclusion
Nouvelle architecture du noyau : séparation des modes User et Kernel
L'architecture de la gestion de la mémoire virtuelle et celle du système ont été
repensées et modifiées. Supprimant les limites des versions précédentes, la gestion
de la mémoire virtuelle de Windows Embedded CE 6.0 permet la cohabitation de 32768
processus, disposant chacun de 2Go de mémoire virtuelle (les limites étaient précédemment
de 32 processus avec 32 Mo de mémoire virtuelle par processus).
De plus l'architecture du noyau a elle aussi été modifiée afin d'unifier le noyau
et d'améliorer les performances générales du système.
Ces modifications n'ont pas été faites au détriment de la sécurité du système, bien
au contraire.
Architecture mémoire de CE 6
Les 4Go de mémoire virtuelle sont partagés comme ceci :
.gif)
Toutes les applications sont chargées et accèdent aux 2 Go inférieurs de la mémoire
virtuelle. Tout accès à la partie supérieure, celle dans laquelle est chargé le
Kernel et qu'il utilise, se fait via un appel à une API (Application Programming
Interface) du système (accéder à un driver via le Device Manager, accéder au File
System, etc. ?). Ainsi, aucun accès à des ressources critiques (système ou hardware)
ne peut se faire sans la vérification et le contrôle du système.
Architecture du Système
L'architecture du noyau de Windows Embedded CE 6.0 a été repensée et modifiée. Elle
se présente désormais comme ceci :
.gif)
Alors que dans les versions précédentes de Windows CE les services du noyau tels
que le Device Manager, ou le File System ou bien encore GWES (Graphical Windowing
and Event Subsystem) étaient des processus séparés du Kernel, ils se présentent
désormais sous la forme de DLLs qui sont chargées par le processus Kernel.
Ceci a pour premier impact de réduire l'overhead sur les appels systèmes. En effet,
alors que dans les versions antérieures à Windows Embedded CE 6.0 un appel à un
service du système depuis une application (driver par exemple) devait transiter
par plusieurs processus (filesys.exe, nk.exe, device.exe pour l'exemple de l'appel
à un driver), le même appel ne transitera plus que par le processus du Kernel. Cela
permet aussi de cloisonner le Kernel en ne permettant pas aux applications et certains
drivers d'accéder aux ressources système et hardware sans passer par un appel système.
En ce qui concerne les drivers, il est possible de choisir s'ils seront chargés
dans l'espace Kernel ou dans l'espace User. En effet, on voudra pour certains drivers
dont on connait la robustesse, pouvoir les charger en mode Kernel et ainsi leur
permettre un fonctionnement plus performant. Dans ce cas, ils pourront librement
accéder aux ressources hardware. Mais pour d'autres drivers (tierce partie, installables
ou moins robustes), on voudra s'assurer qu'ils ne peuvent nuire au fonctionnement
général du système, et on les chargera dans un (ou plusieurs) processus en mode
User. Ces drivers pourront accéder aux ressources critiques, mais toujours sous
le contrôle du système, et ceci à l'aide du "User Mode Driver Framework" (cfr. Chapitre
suivant).
Le mode Kernel
- Dans Windows CE 5.0 et les versions précédentes, le mode "Kernel" est un
niveau d'accès rattaché à un thread. Lorsqu'un thread est en mode Kernel, il peut
accéder à l'espace mémoire Kernel. On peut appeler l'API SetKMode pour changer le
mode d'un thread. La plupart des APIs du système ne sont pas implémentées par le
Kernel (nk.exe), ainsi, appeler une de ces API ne met pas le thread dans le mode
Kernel pour autant, tandis que l'appel à une API implémentée dans le Kernel, met
temporairement le thread en mode Kernel pendant la durée de l'appel.
- Dans Windows Embedded CE 6.0, l'implémentation est la même, si ce n'est que
l'API SetKMode n'est plus supportée. On ne peut plus mettre un thread en mode Kernel
lorsqu'on le désire. Toutefois, la plupart des APIs système étant désormais implémentées
dans des modules désormais chargés dans le contexte du process Kernel, l'appel à
l'une de ces API met le thread en mode Kernel pendant la durée de l'appel de fait.
Alors que l'implémentation est la même, le résultat diffère. Dans CE 5.0, le mode
Kernel est une propriété qu'un thread peut acquérir ou perdre à la demande. Dans
CE 6.0, la règle est très simple : le thread est en mode Kernel lorsqu'il exécute
du code dans le contexte du process Kernel, et en mode User lorsqu'il s'éxécute
dans le contexte d'un process User.
Note : Le terme "Kernel" est couramment utilisé pour décrire du code et des adresses
uniquement accessibles au processus Kernel (adresses supérieures à 0x80000000) :
drivers en mode Kernel, code en mode Kernel, addresses en mode Kernel.
Callbacks
Des précautions particulières sont à prendre dans Windows Embedded CE 6.0 au sujet
des callbacks. Lorsqu'une application passe un pointeur de fonction en paramètre
à du code en mode Kernel (driver en mode Kernel par exemple) afin d'être notifié
en retour, le code de la fonction de notification s'exécute dans le contexte d'un
thread qui est en mode Kernel. Ceci présente une faille de sécurité importante dans
la mesure où le code User de la fonction de callback pourrait alors accéder à des
adresses en mode Kernel ou appeler des APIs "Kernel-only".
Lorsqu'on écrit un driver qui implémente ce mécanisme de callback, il faut s'assurer
de la bonne utilisation de la fonction du CEDDK (CE Driver Development Kit) CeDriverPerformCallback
qui garantira le passage du thread en mode User avant l'appel de la fonction de
callback empêchant ainsi à ce code originellement en mode User d'accéder à des ressources
critiques.
Attention, la terminologie "Kernel Mode" utilisée ici n'a aucune relation avec son
utilisation pour décrire le mode d'un CPU exécutant des instructions particulières
non utilisables en temps normal (gestion des interruptions par exemple). Lorsqu'un
thread Windows CE est en mode Kernel, cela ne signifie pas qu'il sera en mesure
d'utiliser ce mode CPU particulier. Il n'y a que quelques parties du Kernel et de
l'OAL qui exploitent ce mode privilégié du CPU.
Les drivers : Le User Mode Driver Framework
Comme évoqué dans les chapitres précédents, la nouvelle architecture du noyau de
Windows Embedded CE 6.0 propose deux modes d'éxécution : le mode User et le mode
Kernel. Ceci concerne aussi les drivers qui pourront s'exécuter dans un mode ou
un l'autre. Chargé en mode Kernel par le module Device Manager du Kernel, un driver
pourra accéder de manière optimale (en terme de performance) aux ressources système
et hardware, tandis que chargé en mode User, un driver ne pourra nuire à la robustesse
du système. Afin de permettre cela, Windows Embedded CE 6.0 propose Le User Mode
Driver Framework.
Le User Mode Driver Framework se présente sous la forme de deux composants physiques
:
- Le User Mode Driver Reflector, qui réside dans le contexte du module Device
Manager du Kernel.
- Le User Mode Driver Host, qui est une application en mode User lancée et
gérée par le User Mode Driver Reflector.
Lorsqu'un driver est désigné comme étant un driver en mode User dans le registre,
le Device Manager passera par le User Mode Driver Reflector. Celui-ci lance le processus
User Mode Host adéquate vers lequel il redirige les appels. Le processus User Mode
Driver Host redirige à son tour les appels vers le driver en mode User :
.gif)
Le mécanisme d'utilisation d'un driver en mode User est initié par une application
en mode User ou un driver de "Parent Bus" qui peuvent charger les drivers en mode
User en appelant ActivateDevice ou ActivateDeviceEx et les décharger en appelant
DeactivateDevice. Une fois un driver en mode User chargé, une application en mode
User ou un driver peuvent y accéder en utilisant son Device Handle.
Lorsqu'un driver est en mode User, l'appel à ActivateDevice ou ActivateDeviceEx
est aussi redirigé vers le User Mode Driver Reflector. Un driver est configuré comme
étant en mode User lorsque dans la clé de base de registre du driver la valeur FLAGS
est positionnée à DEVFLAGS_LOAD_AS_USERPROC (0x10).
Le User Mode Driver Reflector, qui connait les processus d'origine et de destination,
utilise CeFsIoControl pour rediriger les appels du Device Manager vers le User Mode
Driver Host. Le User Mode Driver Host va ensuite charger, décharger, appeler les
fonctions du driver en mode User, ou bien encore appeler l'entrée du Parent Bus.
Le driver en mode User a des droits d'accès au hardware qui sont donc restreints,
ce qui l'empêche d'utiliser des fonctionnalités telles que le mapping de mémoire
physique ou l'appel aux fonctions de gestion d'interruption. Pour accomplir ce type
d'opérations, le driver en mode User appelle le User Mode Driver Reflector à qui
il confie la gestion de ces opérations. Le User Mode Driver Reflector vérifie alors
en fonction des paramètres de base de registre s'il peut ou non répondre à cette
requête. En revanche, l'accès au driver du Parent Bus n'est pas restreint pour le
driver en mode User, et ceci quelque soit le mode dudit driver et sans l'intervention
du User Mode Driver Reflector.
Protection du système au chargement et à l'exécution de code
Avant Windows Embedded CE 6.0
Dans les versions antérieures à 6.0 de Windows CE, il est possible d'activer un
modèle de sécurité reposant essentiellement sur l'utilisation des certificats. Chaque
module (dll ou exe) est signé avec un certificat et appartient alors à l'une de
ces catégories:
- "Full Trust" : c'est typiquement le cas de dll/exe signés avec un certificat
enregistré sur le système. Dans ce cas, le module est autorisé au chargement et
le code peut appeler toutes les API du système.
- "Run" : c'est le cas des modules signés avec un certificat enregistré sur
le système avec un niveau de confiance moindre. Dans ce cas, le module est chargé
mais certaines APIs du système lui sont interdites (SetKMode par exemple).
- "Untrusted" : c'est le cas des modules non signés ou signés avec un certificat
non enregistré/reconnu sur le système et qui ne peuvent donc être chargé sur le
système.
On peut aussi envisager de ne pas implémenter ce mécanisme et de limiter les appels
aux APIs système à toutes les applications qui ne sont pas en ROM (qui n'ont pas
été intégrées dès le départ au noyau).
Avec Windows Embedded CE 6.0
Désormais sous Windows Embedded CE 6.0, le modèle proposé est de type 1-Tiers. Le
mécanisme se présente en deux parties "API Privilege" et "Load Privilege" :
- "API Privilege" : permet d'autoriser (ou non) le code d'un module à accéder
à certaines APIs marquées comme n'étant accessibles qu'aux modules en mode Kernel.
Cette vérification repose sur l'adresse à laquelle est chargé le code du module
: s'il est chargé à une adresse supérieure à 0x80000000, il est considéré comme
étant en mode Kernel et pourra accéder à ces APIs protégées, s'il est chargé à une
adresse inférieure, il sera considéré comme étant en mode User et ne pourra accéder
à ces APIs. Ainsi ce mécanisme est indépendant du certificat associé au module concerné.
- "Load Privilege" : le système autorise ou non le chargement d'un module (par
exemple, lorsqu'une application appelle CreateProcess ou LoadLibrary). Ce mécanisme
est mis en ?uvre lorsque le composant de gestion de la certification est inclus
dans le noyau (cf. plus loin). Il répond aux règles suivantes :
- - Tout module dont le fichier a l'attribut ROM est "Fully Trusted".
- - Tout module signé avec un certificat enregistré sur le système est "Fully Trusted".
- - Tous les autres modules sont "Untrusted".
En prenant en considération tout ceci, voici les différentes possibilités pour la
création d'un système Windows Embedded CE 6.0 :
Cas 1 : terminal fermé
L'OEM veut développer un terminal fermé, il doit :
- Activer la variable d'environnement SYSGEN_CERTMOD pour la génération du noyau
- Ne pas charger de certificats sur le terminal
- S'assurer que tous les modules qui doivent tourner sur le terminal sont bien en
ROM
Une fois un noyau généré avec de tels paramètres, aucune application ou module tierce
partie ne pourra être chargé sur ce système.
Cas 2 : terminal semi-fermé
L'OEM veut développer un terminal semi-fermé sur lequel seulement les modules signés
pourront être chargés par le système, il doit alors :
- Activer la variable d'environnement SYSGEN_CERTMOD pour la génération du noyau
- Ajouter un ou plusieurs certificats sur le terminal
- S'assurer que tous les modules qui doivent tourner sur le terminal sont soit en
ROM, soit signés avec un certificat chargé sur le terminal.
Cette solution est la bonne si l'OEM veut publier un SDK pour ses terminaux, permettant
ainsi à ces éditeurs de logiciel d'écrire des applications pour leur plateforme.
En imposant la signature des applications avec leur certificat, les OEM peuvent
contrôler quelles applications sont ou non autorisées à s'exécuter sur le terminal.
Cas 3 : terminal ouvert
L'OEM veut développer un terminal totalement ouvert, il doit :
- désactiver la variable d'environnement SYSGEN_CERTMOD pour la génération du noyau
Dans ce cas, tous les modules du système sont considérés comme étant "Fully Trusted"
et toute tentative de chargement aboutira. Notez que SYSGEN_CERTMOD ne fait que
gérer les privilèges de chargement. Une fois le module chargé, les APIs auxquelles
il a accès dépendent du mode d'exécution (User ou Kernel) des threads du module,
et cela dépend de l'espace mémoire dans lequel le module est chargé (cf. chapitres
précédents).
Outils, compilateurs et runtimes
Nous venons de décrire dans les chapitres précédents les éléments qui font de Windows
Embedded CE 6.0 la version du système la plus sécurisée. Toutefois, il est indispensable
que les développeurs système et d'applications mettent en ?uvre tous ces mécanismes
et utilisent les outils, compilateurs et runtimes au mieux afin de construire un
système embarqué réellement sécurisé et robuste.
En effet lorsqu'une application ou un driver sont considérés comme étant fiables
et robustes, et qu'ils sont soit signés numériquement, soit inclus dans la ROM,
ils peuvent, s'ils présentent des failles de sécurité, nuire à la robustesse de
l'ensemble du système.
Lors de la génération de l'OS, le développeur pourra décider du type de modèle de
sécurité général en implémentant ou non les fonctionnalités que nous avons cité
précédemment : plateforme ouverte, semi ouverte ou fermée, drivers en mode Kernel
ou User, signatures numériques, inclusion des applications dans la ROM? Il devra
aussi suivre les recommandations sur l'usage de composants tels que "NDIS User-Mode
I/O Protocol Driver" ou "Internet Connexion Sharing" qui par essence peuvent mettre
le système en danger s'ils ne sont pas utilisés correctement. L'outil Platform Builder
va indiquer au développeur les risques et les bonnes pratiques pour les éviter.
Lors du développement d'applications et de drivers, le développeur pourra s'appuyer
sur divers outils mis à disposition dans Visual Studio pour rendre son code fiable
et robuste, tels que les options de compilations et d'édition de lien, SafeSEH,
l'analyse de code C/C++ ou bien encore la possibilité d'utiliser un Runtime C sécurisé.
Options de compilation et d'édition de lien
/GS :
Lorsque l'on compile avec l'option /GS active, le compilateur détecte les
"Buffer Overruns" potentiels dans le code. Les situations de Buffer Overrun (comme
celle de l'exemple ci-dessous) peuvent être exploitées, particulièrement sur des
microprocesseurs tels que les x86 qui dans les conventions d'appel passent l'adresse
de retour des appels de fonction à la fin de la pile : le code pouvant, à cause
du Buffer Overrun, écraser et modifier cette adresse de retour et ainsi forcer l'exécution
de code malicieux.
The following sample overruns a buffer. When built with /GS, this sample
displays a message box, and then terminates the process.
#include <cstring>
// Vulnerable function
void vulnerable(const char *str)
{
char buffer[10];
strcpy(buffer, str); // overrun buffer !!!
}
int main()
{
// declare buffer that is bigger than expected
char large_buffer[] = "This string is longer than 10 characters!!!";
vulnerable(large_buffer);
}
Afin d'éviter l'exploitation des situations de Buffer Overrun, lorsque du code est
compilé avec l'option /GS, le compilateur identifie les fonctions qui sont
sujettes à cette situation, il insert un identifiant de sécurité dans la pile avant
l'adresse de retour. Si, à la sortie de la fonction l'identifiant de sécurité a
changé, le compilateur signale une erreur et stoppe le processus.
Afin de permettre à /GS de protéger efficacement le code contre d'éventuelles
attaques, la librairie C Runtime (CRT) doit être initialisée au lancement de l'application.
Pour faire cela, il s'agit de configurer le point d'entrée comme étant une des routines
de démarrage de la CRT. Si l'on ne fait pas cela, il faut appeler la fonction __security_init_cookie
dès que possible dans l'exécution du code, avant qu'une quelconque fonction contenant
la gestion d'un buffer ou d'exceptions soit ajoutée à la pile d'appels.
L'option /GS ne protège pas de toutes les attaques de type buffer overrun.
Par exemple, les attaques sont toujours possibles en écrasant la zone des paramètres.
Il faut donc, même si on utilise /GS, s'assurer que le code ne permette aucun
buffer overrun.
SafeSEH :
Lorsque /SAFESEH est spécifié, l'éditeur de liens produit uniquement une
image s'il peut également produire une table des gestionnaires d'exceptions sécurisés
de l'image. Cette table indique au système d'exploitation les gestionnaires d'exceptions
valides pour l'image.
/SAFESEH n'est valide que pour les cibles x86. Cette option n'est pas supportée
sur les autres plateformes telles que ARM, MIPS ou SH, dans la mesure où ces plateformes
positionnent les gestionnaires d'exceptions dans les structures PDATA.
Lorsque /SAFESEH:NO est spécifié, l'éditeur de liens ne produit pas d'image
avec une table de gestionnaires d'exceptions sécurisés même si tous les modules
sont compatibles avec la gestion sécurisée des exceptions.
Le système de génération d'OS s'appuie sur la variable d'environnement SAFESEH dans
les fichiers SOURCES : "SAFESEH=1" pour activer SAFESEH et "SAFESEH=" pour désactiver
l'option.
Security-enhanced CRT
Pour Windows Embedded CE 6.0 et les versions qui suivent, la librairie C Runtime
(CRT) s'est vue ajouter les versions sécurisées des fonctions présentant des failles
de sécurité. Les anciennes versions de ces fonctions sont désormais dépréciées et
leur utilisation dans le code génère des warnings lors de la compilation.
Il est vivement recommandé d'utiliser les versions sécurisées de ces fonctions plutôt
que de supprimer les warnings de compilation.
La librairie C Runtime (CRT) est un ensemble d'APIs définis dans le "C Programming
Language with Extensions" de Microsoft il y a entre 10 et 30 ans. Depuis, beaucoup
de lacunes et de failles d'architecture ont été identifiées et de nombreuses fonctions
sont désormais disponibles en version sécurisées. Lorsqu'une nouvelle version sécurisée
existe, l'ancienne version est indiquée comme dépréciée et la nouvelle se présente
avec un suffixe _s.
NB : lorsqu'on l'on dit qu'une fonction est "dépréciée", cela signifie que son utilisation
n'est pas recommandée.
Les versions sécurisées de ces fonctions permettent d'intercepter les erreurs, et
effectuent des vérifications supplémentaires levant une exception lors de la détection
d'une erreur.
Par exemple, la fonction strcpy ne peut pas savoir si la chaine de caractère
qu'elle copie est ou non trop grande pour le buffer de destination. Sa version sécurisée
strcpy_s, prend la taille du buffer en paramètre et peut donc déterminer
si on est dans une situation de Buffer Overrun.
Lorsque des warnings signalent l'utilisation de fonctions dépréciées, il y a plusieurs
solutions :
- Désactiver ces warnings en définissant _CRT_SECURE_NO_DEPRECATE ou en utilisant
le pragma warning. Attention, en faisant cela, le risque n'est pas évité.
- Utiliser les versions sécurisées des fonctions signalées.
- Définir _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES à 1. Ceci supprimera les
warnings et changera tous les appels en leur version sécurisée. Pour plus d'information,
voir la documentation de Visual Studio 2005.
Les améliorations en termes de sécurité couvrent entre autre :
- Validation des paramètres : les paramètres passés aux fonctions CRT sont validées
(vérification des valeurs NULL passées aux fonctions, validation des valeurs énumérées,
vérification des bornes pour les entiers?)
- Gestion de paramètre invalide : le développeur a à sa disposition un gestionnaire
de paramètre invalide lui permettant de ne plus simplement voir son application
se terminer, mais de prendre la main sur le problème en utilisant la fonction _set_invalid_parameter_handler
et en connectant une fonction de callback.
- Buffers de taille explicite : les fonctions sécurisées imposent l'ajout en paramètre
de la taille du buffer en plus de son pointeur.
- - Elles vérifient que le buffer est suffisamment grand pour pouvoir écrire dedans,
permettant ainsi d'éviter les situations de Buffer Overrun évoquées plus haut.
- - Elles retourneront code d'erreur de type errno et appelleront le gestionnaire
de paramètre invalide si le buffer n'est pas de taille suffisante.
- - Les fonctions qui lisent des données depuis un buffer, tel que des gets,
ont des versions sécurisées qui imposent la spécification d'une taille maximum.
- Terminaison des chaines de caractère : certaines fonctions qui potentiellement laissaient
des chaines de caractère sans caractère de fin sont désormais disponibles dans une
version sécurisée assurant la terminaison par un caractère nul.
- Amélioration du rapport d'erreur : les fonctions sécurisées retournent des codes
contenant plus d'information que leurs versions non sécurisées. Elles positionnent
désormais errno et renvoient aussi souvent un code d'erreur de type errno.
- Sécurité du système de fichier : par défaut, les APIs d'entrée sortie de fichier
supportent l'accès sécurisé aux fichiers.
- Vérification de la syntaxe des "format strings" : les strings invalides sont désormais
détectés, comme par exemple, l'utilisation d'un mauvais descripteur de type de caractère
dans un "format string" passé à la fonction printf.
- D'autres améliorations sont décrites pour chaque fonction dans la documentation.
Fonctions "Safe String"
En plus des fonctions sécurisées de la CRT, Windows Embedded CE dispose de fonctions
de gestion des chaînes de caractère améliorées en remplacement ou en complément
des fonctions de la CRT servant à manipuler des chaînes de caractère. Les fonctions
standard de manipulation de chaînes de caractère mal utilisées peuvent induire des
problèmes de sécurité importants tels que Buffer Overrun ou bien encore l'injection
de code malicieux. Les fonctions en questions sont disponibles via strsafe.h. Pour
plus d'information, voir
ici.
Analyse du code C/C++
L'outils d'analyse de code C/C++, PREFast, intercepte le compilateur natif
et effectue une analyse statique inter-procédurale des fichiers source.
L'outil peur identifier les situations de Buffer Overrun, les problèmes de sémantique
dans l'utilisation de HRESULT, problèmes potentiels de gestion de la mémoire,
et l'usage d'opérateur invalide. De plus, il identifie d'autres problèmes qui peuvent
être de simples erreur de frappe mais apparaissent dans le code comme des erreurs
de format, de casting, etc?
Pour plus d'information, voir ici.
Application Verifier
Disponible dans l'outil Windows Embedded CE 6.0 Test Kit (CETK), l'Application
Verifier est un outil qui garanti la stabilité d'une application. Il peut non seulement
détecter les problèmes de sécurité, mais peut aussi identifier les erreurs
communes de programmation.
L'application Verifier a pour principe de surveiller l'utilisation par une application
du système d'exploitation (système de fichier, registre, mémoire et les API) pendant
que ladite application s'exécute. L'outil fourni ensuite des indications pour la
correction et l'ajustement du code source pour les problèmes détectés.
L'outil vous permet :
- D'identifier les fuites mémoire et les corruptions de tas, dont les débordements
de buffer, ou les problèmes avec les blocs mémoire déplaçables.
- De trouver et gérer les oublis de typage des Handles tels que les Handles
de registre, fichier, évènement, ou section critique.
- De déterminer certains types de problème avec les objets GDI et les objets définis
par l'utilisateur.
Pour plus d'information et les instructions de mise en oeuvre, voir ici.
Conclusion
On a pu voir au travers de cet article que Windows Embedded CE 6.0 est un système
d'exploitation qui s'avère être plus sécurisé que jamais. L'architecture même de
l'OS et les diverses fonctionnalités évoquées permettent de constituer un OS sécurisé.
Il n'en reste pas moins que le rôle du développeur est primordial lorsque la question
de la sécurité est posée.
Celui-ci dispose, grâce aux outils Visual Studio 2005 et Platform Builder 6.0 d'une
panoplie très complète d'outils, de librairies, de compilateurs, et de technologies
complémentaires l'aidant à créer un système, des drivers et des applications qui
pourront non seulement être adaptés et optimisés pour un usage particulier, mais
qui garantiront aussi un fonctionnement stable, performant, sûr.
Il aura la possibilité de ne plus devoir complètement fermer son système pour se
prémunir de tout risque, mais d'ouvrir sa plateforme embarquée tout en garantissant
un fonctionnement robuste et stable.