AMD EPYC "CryptoNow!"

Les discussions sur la protection matérielle des informations utilisateur avec les processeurs AMD EPYC ont commencé il y a deux ans. Par conséquent, on ne peut pas dire que la protection de la mémoire et des environnements virtuels, disponible aujourd'hui dans les processeurs de serveur AMD avec une architecture Zen, était une surprise totale. Sur Geeks / Habré, vous pouvez lire à ce sujet dans l' annonce EPYC , sur le blog ESET NOD32 et dans les présentations AMD David Kaplan sur Internet. L'architecture de ces protections a été décrite en détail par CodeRush dans l'article « Sur la sécurité UEFI », dont je suis particulièrement reconnaissant. C'était vraiment un regard vers l'avenir.


La carte serveur ASUS KNPP-D3 avec deux processeurs AMD EPYC 7551 dans le boîtier RS700A-E9-RS4 prend en charge un ensemble de technologies de protection cryptographique propriétaires d'Advanced Micro Devices

Lorsqu'il nous est devenu possible d'explorer la carte mère ASUS KNPP-D32 avec deux EPYC 7551, la tâche s'est posée de déterminer les caractéristiques de la protection cryptographique implémentée là-bas. Notamment parce qu'il est difficile d'imaginer une autre utilisation d'une telle plateforme, sauf sous la forme d'une auberge pour machines virtuelles. Toute cette ferme, emballée dans un boîtier de montage en rack 1U avec un téraoctet de mémoire d'environ 64 cœurs de processeur, est une bonne illustration de la forte proportion de capacités informatiques. (Avec un régime doux de consommation d'électricité, soit dit en passant).



AMD considère la protection des données utilisateur comme une tâche en trois volets, comprenant le cryptage sécurisé de la mémoire , la virtualisation sécurisée cryptée et le cryptage du contexte du processus . Le deuxième volume du document AMD64 Architecture Programmer's Manual indique que vous pouvez savoir si la plate-forme est prête en exécutant l'instruction CPUID. Sa fonction 8000001Fh dans les registres EAX, EBX, ECX et EDX donne une image complète de l'état de la protection cryptographique. Nous utiliserons l'utilitaire JavaCrossPlatformCPUID .



Bien que nous ne puissions pas trouver la fonction souhaitée parmi les signets, le résultat de son travail peut être vu dans le vidage - le registre EAX contient 0000000Fh. P.534 du document ci-dessus nous permet de déclarer que tous les modes de sécurité sur la plate-forme ASUS RS700A-E9 sont normaux.


Cependant, vous ne pouvez pas entrer dans les détails. AIDA64 rapporte un résultat similaire. Certes, les informations sur la prise en charge du mode Secure Memory Encryption ne sont pas disponibles pour les utilisateurs de ce programme - un autre argument en faveur des diagnostics directs via les fonctions CPUID.


Désormais, les services cloud sont simplement obligés de garantir aux résidents d'un appartement commun que leurs machines virtuelles sont complètement isolées les unes des autres, ainsi que de l'œil curieux de la plateforme hôte. Soit dit en passant, les optimistes peuvent même ne pas chiffrer leurs tâches invitées: en plus des tâches chiffrées, les machines virtuelles non chiffrées s'entendent également pacifiquement (jusqu'à présent, vous n'aviez pas le choix - vous deviez être "comme tout le monde": soit-ou).

La petite chose est d'évaluer la surcharge de la cryptographie: quelles que soient les performances du processeur, les algorithmes de cryptage ont toujours créé et continuent de créer une surcharge sensible. Le site Web techpowerup , citant AMD, affirme une augmentation de la latence pendant les opérations de mémoire de 7 à 8 nsec, ce qui entraîne une diminution de 1,5% des performances SPECInt.

Un certain nombre de sources affirment qu'AMD offre la possibilité d'activer et de désactiver SEV-ES, et cela peut être fait dans une session de système d'exploitation sans redémarrage. Comment le sous-système de protection cryptographique est-il vu et quel effet de levier est disponible pour l'utilisateur?


Dans Windows Server 2016, le Gestionnaire de périphériques fournit des informations sur deux ensembles de périphériques: AMD K17 Platform Security Processor 3.0 (Device ID = 1456h) et AMD Cryptographic Coprocessor (Device ID = 1468h). Étant donné que chaque processeur possède quatre nœuds de processeur, un total de huit PSP et CCP sont détectés dans le système. Le système d'exploitation ne rapporte rien sur les ressources de ces processeurs. Il est cependant connu qu'ils sont connectés au bus PCI Express en mode pleine capacité (x16).


Bien que les PSP / CCP ne soient pas disponibles sur le logiciel, vous pouvez les désactiver en les désactivant dans le Gestionnaire de périphériques. Vous pouvez même désactiver la liaison AMD PCI qui y mène (pour PSP, ce sont des bus avec ID = 145Ah, pour CCP, des bus avec ID = 1455h), ou vous pouvez désactiver les ponts AMP K17 Internal PCIe General Purpose Ports (GPP). Il y en a 16 dans le système pour assurer le trafic entre les nœuds et les (co) processeurs cryptographiques autorisés. Ce qui, cependant, n'affecte pas les performances de la plateforme, à en juger par le Cinebench R15. La dispersion des résultats dans la gamme 4700 ... 5100 selon les phases de la lune annule le processus de collecte des métriques.



En fait, Platform Security Processor 3.0 peut être désactivé par le système d'exploitation, si vous avez besoin d'économiser de l'électricité. Voici une question stupide dans les yeux: pouvez-vous faire cela?

Conclusion

Les initiatives de protection des données matérielles des utilisateurs d'AMD ne seront pas nécessaires tant que Microsoft, Oracle, Red Hat et VMware ne prendront pas en charge leurs produits logiciels. Le chiffrement peut être utile le jour même où le logiciel correspondant devient disponible. Sinon, tout cela sera comme une histoire avec 3DNow!