Réduction de la surface d’attaque du microprogramme (FASR)

En octobre 2019, Microsoft a travaillé en étroite collaboration avec ses partenaires OEM et Silicon pour lancer des PC à cœur sécurisé. Ces appareils disposent d’un matériel, d’un microprogramme et de logiciels profondément intégrés pour garantir une sécurité renforcée pour les appareils, l’identité et les données. L’un des principaux piliers de sécurité des PC à cœur sécurisé est d’aider à offrir une protection des microprogrammes pour les appareils. Une fonctionnalité matérielle fondamentale requise pour satisfaire ce pilier est La racine dynamique de confiance pour la mesure (D-RTM). Cependant, il n’y a pas beaucoup d’appareils qui offrent aujourd’hui D-RTM en raison de la dépendance au chipset sous-jacent pour prendre en charge cette fonctionnalité, ce qui entrave notre engagement à contribuer à élever et à maintenir une barre de sécurité élevée pour tous les appareils Windows.

Plus peut être fait pour améliorer la posture de sécurité de tous les appareils Windows, y compris ceux sans D-RTM. Pour aider à combler cet écart, Microsoft a commencé à travailler avec des partenaires pour résoudre les problèmes de compatibilité qui ont empêché l’application des protections de la mémoire dans le microprogramme UEFI en développant un ensemble d’améliorations de sécurité SMM open source pour offrir une flexibilité supplémentaire aux oem.

Pour refléter cet engagement envers la sécurité des microprogrammes, nous avons identifié une nouvelle approche pour garantir que les appareils peuvent répondre aux exigences de protection des microprogrammes des PC à cœur sécurisé.

Vue d’ensemble du FASR

Pour les PC à cœur sécurisé qui ne disposent pas de fonctionnalités D-RTM matérielles, nous devons définir un petit ensemble de composants de microprogramme qui présentent une surface d’attaque réduite et qui peuvent être attestés dans le système d’exploitation. Cette approche est appelée réduction de la surface d’attaque du microprogramme (FASR). Pour que le microprogramme basé sur FASR soit mis à l’échelle sur des PC de différents fournisseurs, une nouvelle approche du processus de démarrage du microprogramme devait être définie.

FASR prend en charge deux chemins de démarrage :

1. Chemin de démarrage certifié :

   • Seul le code approuvé, signé et intégré par Microsoft est autorisé à s’exécuter.

   • La falsification du chemin de démarrage est détectable par le système d’exploitation.

   La figure ci-dessous montre le flux de démarrage FASR S-RTM sur le chemin de démarrage certifié. Ce chemin de démarrage permet d’empêcher l’exécution inattendue du code de microprogramme de plateforme. Toutefois, il utilise certaines données spécifiques à la plateforme fournies par le chemin de démarrage personnalisé. Le diagramme suivant montre le flux de démarrage FASR sur le chemin de démarrage certifié.

   

2. Chemin de démarrage personnalisé : Tout le code du microprogramme de plateforme peut s’exécuter. Les informations critiques au démarrage spécifiques à un OEM/plateforme particulier sont converties en données sur le chemin de démarrage personnalisé et utilisées par le chemin de démarrage certifié pour configurer correctement le système sur ce chemin de démarrage. Le diagramme suivant montre le flux de démarrage FASR sur le chemin de démarrage personnalisé.

   

   Un appareil FASR activé pour la conformité du PC à cœur sécurisé est défini par défaut sur le chemin de démarrage certifié, sauf si un événement s’est produit qui provoque le basculement du démarrage vers le chemin de démarrage personnalisé au début du processus de démarrage du microprogramme. Les exemples de tels événements incluent une mise à jour du microprogramme, l’utilisateur a demandé une interface utilisateur de microprogramme ou l’utilisateur a choisi de désactiver le PC à cœur sécurisé, ce qui signifie qu’il démarrera toujours sur le chemin de démarrage personnalisé jusqu’à ce qu’il soit réactivé.

   Notez que le démarrage personnalisé peut être utilisé pour démarrer n’importe quel système d’exploitation ou logiciel tiers tel que pris en charge par le microprogramme de la plateforme sur un appareil compatible FASR, mais Windows ne reconnaît pas le démarrage sur le chemin de démarrage personnalisé comme étant conforme à un PC sécurisé.

Pour mieux comprendre les technologies de sécurité derrière FASR, nous aimerions partager une vue d’ensemble rapide du processus de démarrage Windows.

Processus de démarrage Windows

Racine de confiance

L’exécution initiale du microprogramme dans un PC moderne suit un processus de démarrage où un ensemble initial de code charge un autre code, et le niveau de fonctionnalité augmente au fur et à mesure que le démarrage progresse. Chaque jeu de code vérifie l’ensemble de code suivant qui forme une chaîne d’approbation. Lorsque le microprogramme UEFI prend le contrôle, il suit la norme de démarrage sécurisé de vérification des signatures logicielles pour continuer la chaîne d’approbation jusqu’au système d’exploitation. Ensuite, le chargeur de démarrage Windows continue la chaîne d’approbation avec démarrage approuvé, qui vérifie tous les autres composants du système d’exploitation dans le processus de démarrage avant son chargement.

En général, les attaquants cherchent à prendre le contrôle le plus tôt possible dans le processus de démarrage avant que les fonctionnalités de sécurité et les verrous qui aident à protéger le système soient activés. Lorsque le système est sorti de la réinitialisation, l’ensemble initial de code exécuté doit être ancré dans l’approbation. La technologie de vérification matérielle qui remplit le rôle d’effectuer cette vérification de code précoce est appelée racine de l’approbation. Bien que les détails exacts varient selon le fournisseur de matériel, toutes les racines de confiance sont généralement enracinées dans le matériel immuable ou les rom dans le SOC.

Démarrage mesuré

Le démarrage sécurisé ancré dans une racine de confiance permet de s’assurer que la signature numérique de tous les microprogrammes est vérifiée ; toutefois, il est également souhaitable d’avoir un enregistrement de ce que le microprogramme a exécuté. Le programme de compatibilité matérielle Windows exige que tous les pc Windows 10 et Windows 11 incluent une puce appelée module de plateforme sécurisée (TPM). Le module TPM contient des emplacements de mémoire appelés registres de configuration de plateforme (PCR). Chaque PCR contient le hachage d’un type de code et/ou de données chargés pendant le démarrage, comme le code du microprogramme sur le périphérique de stockage non volatile (par exemple, flash SPI), les rom d’option des appareils PCI ou le chargeur de démarrage du système d’exploitation. La taille d’une valeur qui peut être stockée dans une PCR est déterminée par la taille de synthèse de l’algorithme de hachage pris en charge. Par exemple, une PCR SHA-1 peut stocker 20 octets, tandis qu’une PCR SHA-2 peut stocker 32 octets. Plusieurs RCP associés au même algorithme de hachage sont appelés banque. La spécification du profil TPM du client PC TCG définit l’inclusion d’au moins une banque PCR avec 24 registres.

Avec un module TPM présent, chaque composant de microprogramme peut également mettre à jour ou étendre la PCR appropriée à mesure que le nouveau code et les données sont chargés dans le processus de démarrage. Le processus d’extension met à jour la valeur PCR pour qu’elle soit la sortie de l’algorithme de hachage à l’aide de la valeur PCR actuelle concaténée avec le nouveau code ou l’argument de données comme entrée. Le résultat est que les pcr peuvent être inspectés après le processus de démarrage pour déterminer ce qui a été exécuté. Cela permet aux logiciels du système d’exploitation de comprendre si le processus de démarrage était différent des démarrages précédents. Dans un environnement sensible à la sécurité, le système d’exploitation peut être informé de l’ensemble exact des mesures de code attendues dans certains PCR pour détecter l’exécution de code de microprogramme inattendu. Étant donné que les 16 premiers pcr d’une banque ne peuvent être réinitialisés qu’en réinitialisant l’ensemble du module de plateforme sécurisée, ils sont approuvés et l’emplacement préféré pour stocker les mesures importantes dans le module de plateforme sécurisée.

Racine de l’approbation pour la mesure

Maintenant que nous avons examiné le rôle d’une racine de confiance et la façon dont le démarrage mesuré est utilisé, nous allons examiner deux approches courantes pour établir une racine de confiance pour signaler une chaîne de mesure au TPM : statique et dynamique.

Une racine statique d’approbation pour la mesure (S-RTM) établit l’approbation lors de la réinitialisation du système et exige que l’approbation soit maintenue tout au long du processus de démarrage. Si l’approbation est compromise à un moment quelconque du processus de démarrage, elle est irrécupérable tant que le système n’est pas réinitialisé. Le diagramme suivant illustre la façon dont S-RTM est utilisé sur le chemin de démarrage certifié.

En revanche, la racine dynamique d’approbation pour la mesure (D-RTM) n’approuve qu’une petite partie du code du microprogramme d’initialisation du chipset, ainsi qu’un agent matériel utilisé pour rétablir l’approbation dynamiquement pendant le démarrage. Le système peut initialement démarrer dans un code de microprogramme non approuvé, mais, peu de temps après le lancement, il revient à un état approuvé en prenant le contrôle de tous les processeurs et en les forçant à descendre d’un chemin d’accès bien connu et mesuré. Le diagramme suivant fournit une vue d’ensemble d’un flux D-RTM traditionnel.

Il existe un compromis entre S-RTM et D-RTM. S-RTM ne nécessite pas de fonctionnalités matérielles spéciales, mais nécessite un logiciel pour mieux tenir compte du code qui s’est exécuté pendant l’intégralité du démarrage. D-RTM nécessite des fonctionnalités matérielles spéciales, mais permet au logiciel de se lancer dans un état approuvé dynamiquement pendant la durée de vie du système.

Les PC Windows Secure-core ont utilisé un D-RTM dans Le lancement sécurisé pour permettre au large éventail de fabricants de systèmes d’implémenter des fonctionnalités et des expériences uniques dans le microprogramme, tout en garantissant que le système peut atteindre un état approuvé et mesuré acceptable pour héberger un environnement de système d’exploitation sécurisé. Un événement de lancement D-RTM est utilisé pour rétablir la confiance à partir d’un environnement inconnu avant de charger un noyau sécurisé. Le diagramme suivant montre l’événement de lancement D-RTM pour rétablir un environnement système connu.

Dans le passé, S-RTM pouvait être implémenté sur d’autres appareils en raison de son absence de dépendance à l’égard de fonctionnalités matérielles spéciales pour vérifier l’état de sécurité du système, mais le système d’exploitation n’avait pas de méthode fiable pour confirmer qu’il pouvait approuver les mesures signalées sur un appareil Windows donné à l’aide de S-RTM.

Améliorations de la sécurité des microprogrammes

Réduire les composants du microprogramme dans le chemin de démarrage du système d’exploitation

Une façon d’approuver les mesures S-RTM consiste à réduire les composants de microprogramme autorisés à s’exécuter à un ensemble minimal. Si tous les appareils utilisant S-RTM utilisaient le même ensemble de composants de microprogramme, le système d’exploitation n’aurait besoin d’approuver qu’un seul ensemble de valeurs PCR attendues pour ces composants connus et approuvés. Avec cette approche basée sur SRTM, un appareil peut être considéré comme ayant satisfait aux exigences de protection du microprogramme des PC à cœur sécurisé lorsque l’ensemble de microprogrammes de démarrage est vérifié pour contenir uniquement des logiciels signés Par Microsoft qui peuvent être attestés par Windows. Pour mieux comprendre comment ces composants de microprogramme diffèrent de ceux d’un démarrage normal de PC, examinons le processus de démarrage avant et après.

En raison de la flexibilité et de l’ensemble complet de fonctionnalités offertes par le microprogramme pc moderne, le code qui s’exécute avant le système d’exploitation entraîne une surface d’attaque accrue. Le diagramme suivant montre un exemple de flux de démarrage S-RTM traditionnel.

Les principales responsabilités du microprogramme pendant le démarrage peuvent être considérablement simplifiées pour :

• Spécifique à la plateforme : fonctionnalité qui s’applique uniquement à la conception matérielle de la plateforme spécifique.

• Non spécifique à la plateforme : fonctionnalité standard du secteur et commune à d’autres matériels.

Un sous-ensemble relativement petit de microprogrammes modernes est généralement spécifique à la plateforme. Une grande partie du code d’infrastructure du microprogramme qui effectue des tâches courantes telles que l’allocation de la mémoire, la distribution des pilotes de microprogrammes, la gestion des événements, etc. est identique entre tous (ou la plupart) les systèmes UEFI. Les pilotes binaires de microprogramme pour ces tâches peuvent être réutilisés sur plusieurs PC. En outre, les spécifications matérielles et les interfaces standard permettent aux pilotes de microprogramme courants d’initialiser des disques durs, des contrôleurs USB et d’autres périphériques. Les pilotes binaires de microprogramme pour ce matériel peuvent également être réutilisés sur plusieurs PC. En résumé, les PC peuvent être démarrés avec un ensemble très minimal de pilotes de microprogramme courants.

La réduction du nombre total de pilotes de microprogrammes chargés pendant le démarrage peut entraîner d’autres avantages :

• Temps de démarrage amélioré

• Coordination des fournisseurs diminuée pour les mises à jour

• Exposition réduite aux bogues

• Surface d’attaque réduite

Vérification du chemin de démarrage FASR et conformité des cœurs sécurisés

Pour qu’un système FASR réponde aux exigences de protection du microprogramme des PC à cœur sécurisé, il doit avoir démarré sur le chemin de démarrage certifié. Le microprogramme FASR facilite cela en fournissant au système d’exploitation un manifeste signé par Microsoft appelé manifeste FASR (mesuré dans le TPM) qui contient les valeurs PCR attendues pour la séquence de démarrage du module sur le chemin certifié. Cela peut être comparé à la séquence de démarrage réelle qui s’est produite sur le chemin certifié. Si ces mesures correspondent, le système est considéré comme ayant satisfait aux exigences de protection du microprogramme du programme PC à cœur sécurisé. Tout écart par rapport à la séquence de chemin de démarrage certifié attendue entraîne des mesures inattendues effectuées dans les registres de configuration de la plateforme (PCR) du TPM que le système d’exploitation va détecter.

En outre, Windows ne libère des secrets protégés par l’hyperviseur qu’après la validation réussie du manifeste FASR signé par rapport aux mesures enregistrées lors du démarrage actuel. Si sur un chemin de démarrage certifié ou une mise à jour de capsule, le manifeste FASR n’est pas présent, la vérification de la signature échoue ou une incompatibilité PCR se produit, et les secrets VSM ne seront pas descellés ou migrés.

Comment le microprogramme FASR traite les protections mémoire et SMM

Maintenant qu’un fichier binaire signé par Microsoft avec un ensemble minimal de fonctionnalités a été défini, il peut inclure les protections de sécurité de microprogramme fondamentales, mais manquantes, que Microsoft travaille avec ses partenaires pour mettre sur le marché. Le chemin de démarrage certifié doit au minimum répondre aux exigences suivantes :

1. Le code ne lit pas/n’écrit pas dans NULL/Page 0

2. Le code d’image et les sections de données sont séparés

3. Les sections d’image sont alignées sur une limite de page (4 Ko)

4. Les données sont allouées uniquement en types de mémoire de données et le code en types de mémoire de code

5. Les images de code ne sont pas chargées à partir du code distribué en tant que fichiers binaires UEFI (uniquement les répartiteurs désignés)

6. Le code reste dans les limites des mémoires tampons allouées avec des pages de protection autour des allocations de pages

7. Le dépassement de pile peut être détecté

8. Le code ne s’exécute pas à partir de la pile

9. La caractéristique DE DLL /NXCOMPAT est définie pour activer les protections NX

Les rom d’option tierces, les applications UEFI et les pilotes UEFI n’ont souvent pas été créés ou validés par rapport à cet ensemble de conditions. Par conséquent, ils ne s’exécuteraient pas sur le chemin de démarrage certifié. Le chemin de démarrage personnalisé peut éventuellement choisir de réduire le niveau de protection requis, mais ce chemin de démarrage n’est pas considéré comme un PC sécurisé conforme par le système d’exploitation.

Mode de gestion du système (SMM)

SMM est un mode de fonctionnement de processeur spécial dans l’architecture x86. Il présente un défi unique pour la sécurité du système, car le code exécuté dans l’environnement SMM est opaque pour le système d’exploitation et s’exécute généralement au niveau de privilège le plus élevé (parfois appelé « Anneau -2 ») de tout logiciel sur le processeur hôte. Lors de l’entrée, SMM configure son propre environnement en configurant la table de pages, la table de répartition des interruptions (IDT) et d’autres structures système. Par conséquent, SMM représente une surface d’attaque importante qui pourrait être exploitée par du code malveillant pour compromettre ou contourner les protections du système d’exploitation activées par le biais de la sécurité basée sur la virtualisation (VBS). Pour aider à atténuer le danger posé par SMM, les fonctionnalités de SMM peuvent être réparties de manière conceptuelle entre l’infrastructure principale SMM et les pilotes SMM comme suit :

• Cœur SMM : code commun à toutes les implémentations SMM exécutant des responsabilités architecturales et d’infrastructure

• Pilotes SMM : code écrit pour accomplir une tâche spécifique à la plateforme dans SMM

Voici quelques moments clés du cycle de vie de SMM :

1. Lorsque la base (ou le cœur) SMM est établie , la charge initiale du programme (IPL) SMM

2. Lorsque les pilotes SMM sont chargés, appelé répartition des pilotes SMM

3. Quand l’entrée dans SMM se produit via une interruption de gestion du système (SMI)

Chargement initial du programme (IPL) SMM

Le processeur dispose de fonctionnalités spéciales qui accordent au code SMM un privilège élevé et aident à le protéger. Par exemple, un mécanisme est défini pour entrer SMM via des événements logiciels ou matériels, une instruction d’UC est utilisée pour retourner à partir de SMM, et plusieurs registres sont définis pour contrôler l’accès et verrouiller la configuration de SMM. La plupart de ces registres de contrôle sont configurés par le code IPL SMM pour restreindre l’accès à la zone de mémoire où le code et les données SMM sont stockés (appelée RAM de gestion du système ou SMRAM).

Étant donné que la zone SMRAM se trouve dans la mémoire principale (DRAM), elle ne peut pas être établie tant que la DRAM n’est pas activée pendant le démarrage. Les procédures d’activation de la DRAM varient selon le fournisseur de silicium, mais quelques mégaoctets de code peuvent s’exécuter directement à partir du cache CPU LLC (y compris le code qui initialise la DRAM) avant que la mémoire principale ne soit disponible.

Le microprogramme FASR apporte le point IPL SMM plus tôt au démarrage que la plupart des autres systèmes. Cela réduit la possibilité pour un attaquant d’affaiblir ce processus et de prendre le contrôle du système avant la configuration de SMM. Pour mieux comprendre cela et les autres améliorations apportées à SMM dans le microprogramme FASR, nous devons en savoir plus sur le processus de démarrage du microprogramme.

Démarrage de l’initialisation de la plateforme (PI) dans le microprogramme UEFI

Le microprogramme pc moderne est construit autour de nombreuses spécifications. La spécification UEFI définit l’interface entre un système d’exploitation conforme à UEFI comme Windows et le microprogramme de l’appareil. Une autre spécification appelée spécification d’initialisation de plateforme (PI) définit la façon dont les pilotes de microprogramme sont générés et détaille le processus de démarrage lui-même. À un haut niveau, la spécification UEFI peut être considérée comme l’une des normalisations qui permet à une image Windows unique de fonctionner avec autant d’appareils différents, et la spécification PI peut être considérée comme l’une des normalisations qui permet à tant d’images de microprogramme de différents fournisseurs de matériel de fonctionner ensemble. Les deux spécifications sont gérées par le forum UEFI.

La spécification PI définit les phases de démarrage et les pilotes qui sont écrits dans les phases de démarrage. Pendant le démarrage du microprogramme, chaque phase passe à la suivante et, dans la plupart des cas, les pilotes de la phase de remise ne sont plus utilisés et seules les données importantes sont passées à la phase suivante afin qu’elle puisse continuer le processus de démarrage. Les phases de démarrage peuvent être résumées comme suit :

1. SEC : contrôlez le vecteur de réinitialisation du processeur et passez de l’assembly au code C pour charger PEI

2. PEI : initialiser l’état système pour charger DXE et initialiser la DRAM

3. DXE : effectuer l’initialisation du système restante, ce qui inclut la prise en charge des besoins BDS pour charger un système d’exploitation

4. BDS : découvrez l’option de démarrage pour le démarrage actuel (par exemple, chargeur de démarrage du système d’exploitation) et tentez de démarrer cette option

5. Système d’exploitation : noyau du système d’exploitation

Protection de la charge initiale du programme (IPL) SMM

Le microprogramme classique conforme à la spécification UEFI PI charge l’IPL SMM dans la phase de démarrage DXE. Le microprogramme FASR charge l’IPL SMM dans la phase de démarrage pei. La base de calcul fiable (TCB) d’un système est l’ensemble total des mécanismes de protection qui le protègent, y compris le matériel, le microprogramme et les logiciels. En déplaçant l’IPL SMM de DXE vers l’Île-du-Prince-Édouard, l’ensemble de la phase DXE (qui est un environnement beaucoup plus grand et plus riche que l’Île-du-Prince-Édouard) est supprimé du TCB. Le diagramme suivant montre l’IPL SMM déplacé précédemment dans le processus de démarrage UEFI.

Le code PEI et DXE s’exécutent à l’anneau 0 et ne persistent pas (à quelques exceptions près) dans le système d’exploitation. Le code SMM s’exécute avec un privilège beaucoup plus élevé que l’anneau 0 (et l’hyperviseur) et persiste dans le système d’exploitation. Par conséquent, le fait de ne pas autoriser une vulnérabilité DXE à impacter l’établissement de SMM réduit la surface d’attaque système globale. En outre, étant donné que SMM est lancé plus tôt dans le processus de démarrage, les bits de verrouillage définis pour aider à protéger SMM peuvent être activés plus tôt au démarrage, ce qui réduit davantage la fenêtre d’un attaquant pour compromettre SMM.

Protection du processus de répartition des pilotes SMM

Dans la spécification PI, deux modes SMM sont définis : MM traditionnel et MM autonome. Mm traditionnel est équivalent au modèle logiciel SMM utilisé historiquement dans les microprogrammes conformes PI, qui constitue la majorité des microprogrammes UEFI dans le secteur. Le mode mm autonome est un mode relativement nouveau qui révise le modèle historique pour améliorer la sécurité de l’environnement SMM et éviter les erreurs courantes commises dans les implémentations mm traditionnelles qui ont entraîné de nombreux défis de portabilité et de sécurité au fil des ans.

Le microprogramme FASR fonctionne exclusivement en mode MM autonome. Cela permet au microprogramme FASR de suivre une approche disciplinée de l’exécution de logiciels dans SMM. Aujourd’hui, de nombreuses vulnérabilités basées sur SMM sont dues à des pratiques incorrectes autorisées dans le code SMM dans le mm traditionnel qui peuvent simplement être supprimées dans le mm autonome. À un niveau élevé, cela se produit parce que, dans le modèle MM traditionnel, un pilote SMM est distribué deux fois, une fois par le répartiteur DXE dans l’anneau 0, et à nouveau par le répartiteur SMM dans SMM. Le code de pilote exécuté dans l’environnement DXE permet ainsi de mettre en cache des pointeurs vers des ressources en dehors de SMRAM auxquelles ils ne doivent pas accéder après le retour du point d’entrée. Les attaques qui dépendent du code SMM pour appeler du code en dehors de SMM sont souvent appelées « attaques de légende SMM ».

Protection de l’entrée dans SMM

Les données sont transmises à un gestionnaire SMI via une structure appelée « mémoire tampon de communication ». Le gestionnaire SMI est chargé de vérifier si les données répondent à certaines exigences dans leur point d’entrée. La table d’atténuation de la sécurité SMM (WSMT) windows est un mécanisme utilisé pour aider à atténuer les menaces non vérifiées que les gestionnaires SMI posent à la sécurité basée sur la virtualisation dans le système d’exploitation. Microsoft a contribué au projet TianoCore pour améliorer la validation de la mémoire tampon de communication. En plus de tirer parti de ces deux techniques, le code FASR implémente également des protections strictes d’accès à la mémoire, ce qui permet au code SMM d’accéder uniquement aux plages de mémoire explicitement autorisées.

Superviseur du mode de gestion (superviseur MM)

Le code principal SMM est commun et partagé avec un minimum ou aucun changement entre les systèmes. La surface d’attaque imposée par SMM peut être considérablement réduite en introduisant la séparation des privilèges dans l’environnement SMM. Pour cette raison, le microprogramme FASR inclut un superviseur SMM qui s’exécute en MM autonome. Il en résulte un environnement SMM bien défini avec un TCB minimal avec des niveaux de privilèges appliqués à partir de la création. Le superviseur MM place des restrictions sur les accès aux ports d’E/S, les accès MSR (Model Specific Register), l’accès MMIO, l’accès à l’état d’enregistrement du processeur et les instructions autorisées dans l’environnement SMM. Une stratégie de superviseur SMM est utilisée pour configurer les détails exacts des ressources matérielles à restreindre, et ces détails exacts sont susceptibles d’être modifiés par génération de silicium.

La stratégie a récemment été transférée vers une approche de refus par défaut qui réduit considérablement les ressources matérielles disponibles pour le code en dehors du superviseur SMM. Ce superviseur fonctionne sans dépendance matérielle sur les fonctionnalités matérielles que l’on ne trouve pas couramment dans les PC modernes.

Le superviseur MM est utilisé dans FASR est open source et disponible dans le référentiel project mu MM Supervisor.

Conformité du système FASR aux exigences relatives aux PC à cœur sécurisé

Le tableau suivant indique les grands piliers ou objectifs de sécurité des PC à cœur sécurisé, et la façon dont les systèmes FASR qui démarrent dans le chemin certifié peuvent répondre aux exigences des PC à cœur sécurisé :

Avantages en matière de sécurité	Fonctionnalités de sécurité dans les PC à cœur sécurisé
Créer une racine d’approbation matérielle	Démarrage sécurisé
	Module de plateforme sécurisée 2.0
	Protection d’accès direct à la mémoire (DMA)
Se défendre contre les attaques au niveau du microprogramme (voir la remarque ci-dessous)	System Guard Secure Launch (D-RTM) ou S-RTM (FASR FW)
	Isolation en mode de gestion du système (SMM) ou MM autonome avec superviseur MM (FASR FW)
Protéger le système d’exploitation contre l’exécution de code non vérifié	Intégrité de la mémoire (également appelée HVCI)
Fournir une vérification et une protection d’identité avancées	Windows Hello
Protéger les données critiques en cas de perte ou de vol d’appareils	Chiffrement BitLocker

Si le système ne dispose pas de fonctionnalités de sécurité avancées pour prendre en charge D-RTM, les exigences de protection du microprogramme peuvent être satisfaites à l’aide d’une combinaison de S-RTM et de MM autonome avec superviseur MM, qui sont tous deux proposés par le microprogramme FASR.

Résumé

Il s’agit de quelques-uns des investissements que Microsoft a faits pour répondre au nombre croissant d’attaques de microprogrammes qui sont répandues dans l’industrie aujourd’hui. En utilisant du code open source pour ces modifications, nous permet à nos partenaires de tirer parti de certains de ces avantages en matière de sécurité, qui profiteront à leur tour à l’écosystème et à l’industrie dans son ensemble.

L’objectif principal de l’initiative PC à cœur sécurisé est de s’assurer que les clients ont accès à certaines des fonctionnalités de sécurité les plus avancées disponibles pour les PC Windows. Avec certaines de ces modifications de microprogramme, nous sommes un pas de plus vers la réalisation de cet objectif, et nous avons mis à jour les exigences de protection des microprogrammes des PC à cœur sécurisé pour refléter cette inclusion. En savoir plus sur les PC à cœur sécurisé ici.