Les derniers contenus liés au tag Google
Microcode final pour Spectre chez Intel
Des failles de sécurité spécifiques aux Ryzen ?
GDC: Quelle API de bas niveau va s'imposer ?
IDF: Google, nouveau partenaire privilégié
IBM ouvre un peu plus l'architecture Power
Microcode final pour Spectre chez Intel
Intel vient de publier quelques informations concernant les failles de sécurité Spectre et Meltdown. Après deux bons mois de développement, le constructeur a publié mardi soir une nouvelle version de ses microcode qui contient la version définitive des correctifs pour Spectre. On se souviendra que Microsoft avait désactivé fin janvier son patch pour la variante 2 de Spectre suite aux problèmes de stabilité rencontrés dans certaines situations avec le microcode d'Intel.
L'attente aura été assez longue et la communication d'Intel au compte goutte, mais ce microcode final résout les problèmes de stabilités. Le correctif a été déployé d'après Intel sur toutes les architectures lancées ces cinq dernières années. En pratique, le patch Spectre est désormais disponible pour tous les CPU à partir de Sandy Bridge (les Core "2nde génération" comme les Core i7 2600K) en version classique et HEDT. A ce que nous avons pu voir, l'impact sur les performances ne changerait pas réellement entre la version finale et la version beta de ce microcode que nous avions testé il y a plus d'un mois de cela.
En parallèle, Intel annonce avoir effectué des modifications pour ses prochaines architectures. Le prochain processeur serveur Xeon, connu sous le nom de code Cascade Lake sera protégé nativement contre Meltdown (une faille qui ne touche qu'Intel côté x86) et la variante 2 de Spectre. Intel dit avoir "ajouté des "murs protecteurs" entre les applications et les niveaux de privilèges utilisateurs pour créer un obstacle contre les mauvais acteurs". En plus des Cascade Lake, Intel dit que des processeurs Core 8eme génération attendus pour la deuxième moitié de l'année proposeront aussi ces correctifs. Intel ne précise pas quels CPU sont concernées exactement, la logique voudrait que le constructeur parle de Cascade Lake-X, la déclinaison HEDT de Cascade Lake, même si le constructeur n'a pas pu nous le confirmer.
Corriger de manière matérielle Spectre V2 sera particulièrement important pour les nouvelles architectures d'Intel puisque Skylake, la dernière architecture en date, est assez difficile à sécuriser autrement qu'avec la méthode utilisée par Microsoft pour Windows (communément appelé patch IBRS). Une solution alternative développée par Google, retpoline , est plus difficile à appliquer sur les Skylake dont les mécanismes d'exécution spéculative diffèrent. L'impact de l'IBRS est particulièrement important sur les changements de contextes et les IO pour rappel. Intel n'a pas précisé le coût éventuel sur les performances de ses "murs protecteurs".
Les BIOS incluant ces mises à jour vont être rendus disponibles par les constructeurs dans les jours à venir.
Des failles de sécurité spécifiques aux Ryzen ?
Une firme de sécurité israélienne, CTS-Labs, a publié ces dernières heures un site web ainsi qu'un whitepaper décrivant selon eux treize vulnérabilités critiques (regroupées en 4 familles de failles) touchant les processeurs AMD Ryzen et dérivés. Le whitepaper publié est relativement avare en détails techniques (pour ne pas dire superficiel), mais il décrit globalement les méthodes et les impacts.
Trois "familles" de failles pour deux cibles distinctes
La première famille de faille, Masterkey, regroupe plusieurs attaques qui permettraient d'exécuter du code malicieux sur le Secure Processor (un CPU ARM Cortex A5 inclut dans les processeurs Ryzen, il s'agit peu ou prou du pendant de l'Intel Management Engine pour faire un parallèle). Le Secure Processor disposant (comme le ME) d'un niveau de privilège supérieur au reste du système, ce type de faille est en général considéré comme particulièrement critique (nous reviendrons plus bas sur l'impact réel). Dans ce cas cependant, l'exploitation des failles requiert que l'on flash au préalable un BIOS modifié/corrompu, ce qui limite sensiblement sa portée et sa facilité de déploiement.
La seconde famille de faille, Ryzenfall, s'attaque également au Secure Processor (l'ARM Cortex A5), ou plus précisément à son OS (Secure OS). AMD a choisi pour rappel d'utiliser les mécanismes de sécurité développés par ARM (TrustZone ). Deux implémentations de TEE (Trusted Execution Environment) coexistent, une développée par Qualcomm (QSEE) et l'autre par Trustonic (Kibini ). C'est cette dernière qui serait utilisée par AMD pour son "Secure OS" d'après le whitepaper. Les failles permettraient là aussi d'exécuter du code sur le Secure Processor et de bypasser les protections mémoires sous Windows. L'exploitation des failles est décrite comme requérant un accès système administrateur ainsi qu'un pilote signé spécifique (on ne sait pas lequel, s'il s'agit d'un pilote communément installé par les drivers AMD, ni s'il s'agit d'une version particulière du pilote). Bien que cela ne soit pas dit explicitement dans le whitepaper qui est assez avare en détails, le fait qu'un pilote Windows soit nécessaire laisse penser d'une part que la faille est spécifique à Windows, et de l'autre que la faille semble en grande partie logicielle. A noter que la troisième "famille" de faille, Fallout, est le pendant exact de Ryzenfall mais cette fois ci appliqué à Epyc plutôt qu'à Ryzen.
La dernière famille de faille, Chimera, s'attaque enfin au chipset utilisé par AMD pour les cartes mères Ryzen (les X370 et dérivés, connus sous le nom de code Promontory).
Ces chipsets sont pour rappels développés par Asmedia et s'occupent des I/O "lentes" (USB, SATA, réseau, ce que l'on appelait historiquement un southbridge). La faille pointée par la société permettrait d'exécuter du code directement sur le chipset et d'accéder à la mémoire via le DMA. Le whitepaper parle de deux failles distinctes, une liée au firmware, et l'autre lié au design de l'ASIC. L'exploitation de cette faille demanderait là aussi un accès système administrateur et un pilote signé (Windows n'est pas mentionné explicitement cette fois ci).
Des failles complexes à exploiter et peut être pas nouvelles
La première chose qu'il nous semble important de pointer est que ces failles requièrent systématiquement un accès administrateur (et donc un système déjà compromis) et soit un pilote signé, soit un BIOS modifié pour qu'elles soient exploitables. Elles sont incomparables de leur description avec des failles comme Meltdown qui permet sur les processeurs Intel une escalade de privilèges d'un espace mémoire userland vers root, ou comme les variantes de Spectre qui s'attaquent aux mécanismes d'exécution spéculatifs.
Ici, deux cibles distinctes sont pointées. Les trois premières familles de failles s'attaquent au Secure Processor et à son système d'exploitation avec une même finalité, exécuter du code dans l'environnement sécurisé. Si l'on doit faire un parallèle, ces failles font échos aux divers problèmes rencontrés par Intel autour de son Management Engine. Il ne s'agit pas non plus de la première fois que des failles sont pointées sur le Secure Processor d'AMD. En janvier 2018, une faille s'attaquant au trustlet (le nom des programmes tournant dans l'environnement TrustZone) fTPM (l'implémentation "firmware" du TPM, à distinguer d'un TPM hardware via le connecteur présent sur les cartes mères) avait été publiée par un ingénieur des équipes de sécurité de Google Cloud. Un patch avait été mis à disposition courant décembre par AMD. Rien ne laisse penser qu'AMD ne pourra pas corriger de la même manière ces failles qui semblent reposer sur le TEE et/ou sur les trustlets utilisés par AMD. La description de certaines des failles nous laisse penser qu'elles pourraient être exploitables sur d'autres SoC qui utiliseraient l'implémentation TEE de Trustonic (c'est le cas de certains SoC Samsung par exemple).
On notera aussi que le Project Zero de Google avait pointé l'été dernier un bon nombre de limites/failles dans les implémentations TrustZone/TEE de Qualcomm et de Trustonic, particulièrement au niveau de la question de la révocation de trustlets. Dans le cas de l'OS de Trustonic, la version 400 (utilisée par Samsung à partir des SoC intégrés dans les Galaxy S8) renforce les possibilités de révocation qui lorsqu'elles sont bypassées peuvent être utilisées pour exploiter des bugs présents dans d'anciennes versions du firmware (Project Zero décrit sur son blog une attaque sur le TEE de Trustonic pour les versions précédentes). Les détails dévoilés par la firme de recherche sont ténus, mais le fait qu'un flashage de BIOS soit nécessaire nous fait penser que la faille exploitée est peut être celle décrite par Google en juillet dernier.
On note d'ailleurs que les failles s'attaquent spécifiquement au fTPM ou à des fonctionnalités spécifiques du BIOS qui deviendraient désactivables. C'est là que les parallèles s'arrêtent d'ailleurs avec les failles du ME d'Intel puisque les descriptions de Masterkey ne parlent pas de la possibilité d'accéder à de la mémoire privilégiée, mais plutôt d'exécuter du code sur le SP sans préciser ce que cela veut dire réellement. Le blog Project Zero explique l'impact relatif :
"And what of Trustonic's TEE? Unlike QSEE's model, trustlets are unable to map-in and modify physical memory. In fact, the security model used by Trustonic ensures that trustlets aren't capable of doing much at all. Instead, in order to perform any meaningful operation, trustlets must send a request to the appropriate “driver”. This design is conducive to security, as it essentially forces attackers to either compromise the drivers themselves, or find a way to leverage their provided APIs for nefarious means. Moreover, as there aren't as many drivers as there are trustlets, it would appear that auditing all the drivers in the TEE is indeed feasible. "
Il n'y a donc pas d'accès mémoire direct autorisé aux trustlets, contrairement au modèle de sécurité utilisé par l'Intel Management Engine. Qui plus est, le whitepaper pointe le problème spécifique des pilotes (qui semble être ce qu'exploite Ryzenfall/Fallout qui requiert comme nous l'expliquions un pilote signé et qui est capable d'accès mémoire privilégié, on l'imagine via le pilote comme le décrit Google) comme point d'entrée, et la manière de mitiger les attaques, ce qui fait là aussi écho au papier de Project Zero :
" Although trustlets aren't granted different sets of “capabilities”, drivers can distinguish between the trusted applications requesting their services by using the caller's UUID. Essentially, well-written drivers can verify that whichever application consumes their services is contained within a “whitelist”, thus minimising the exposed attack surface. Sensitive operations, such as mapping-in and modifying physical memory are indeed unavailable to trusted applications. They are, however, available to any driver. As a result, driver authors must be extremely cautious, lest they unintentionally provide a service which can be abused by a trustlet."
Les parallèles dans la description du whitepaper nous laisse penser qu'il s'agit soit des failles décrites par le Project Zero l'été dernier, soit de variantes spécifiques aux trustlets utilisées par AMD. Si l'on ne connaît pas la version de Kibini utilisée par AMD dans les Ryzen, rien ne semble empêcher théoriquement le constructeur et Trustonic de sécuriser leurs pilotes (même s'ils ne semblent pas l'avoir fait, ou suffisamment depuis la publication de juillet dernier pour peu que les failles soient présentes dans les dernières versions des pilotes) et bloquer les failles publiées.
Le cas ASMedia
La quatrième famille de failles s'attaque spécifiquement au "chipset" fourni par ASMedia. Le whitepaper pointe le fait que le chipset est l'amalgamation sur un même die d'un contrôleur USB 3.1 ASM1142, d'un contrôleur SATA ASM1061 et d'un pont PCI Express. S'ils ne le disent pas explicitement pour leur faille, sur la page suivante la firme indique que les contrôleurs USB ASM1142 ont "une sécurité en dessous des standards" et qu'ils contiennent "des vulnérabilités côté logiciel et hardware".
Il nous est difficile d'évaluer les dires de la firme sur ce point, mais plus globalement, la sécurité des puces additionnelles intégrées sur les cartes mères est un problème important qui est en général limité par le fait que l'accès au périphérique est restreint par un pilote signé. Sans plus de détails il est impossible de savoir si la faille est liée à une version spécifique de pilote, si elle a été corrigée, ou si elle est corrigeable. Mais dans l'absolu, le fait que la faille semble liée a l'ASM1142 spécifiquement (et possiblement à sa version précédente, l'ASM1042) fait que son impact va bien au delà de Ryzen, ces puces contrôleurs USB 3.1 étant utilisées sur la quasi totalité des cartes mères vendues ces dernières années.
Un marketing très appuyé et orienté
Si la description technique des failles nous fait nous poser des questions sur leur impact réel et leur nouveauté, le marketing qui les entoure nous semble également assez orienté.
D'abord, là où en général les failles de sécurités sont communiquées en amont aux constructeurs, pour qu'ils puissent avoir une chance de les corriger, on notera que CTS Labs ne s'est fait connaître auprès d'AMD que 24 heures avant la publication de leur whitepaper. Un délai excessivement court et qui va a l'encontre des pratiques utilisées de nos jours par la majorité des firmes de recherches. Historiquement la question du délai entre le moment ou l'on prévient un constructeur d'une faille et le moment ou elle est rendue publique a toujours été un point de contention entre les chercheurs et failles et les sociétés informatiques. Les constructeurs ont longtemps abusé de la bonne volonté des chercheurs pour étendre au maximum cette durée qui se comptaient longtemps en mois. Google, via son Project Zero, a tenté d'imposer un standard de 90 jours, contesté par nombre de sociétés comme trop court mais qui nous semble être dans l'intérêt général. Le délai de 24 heures dénote donc assez fortement et ne nous semble pas particulièrement "responsable".
La lecture du whitepaper montre qu'il n'est pas non plus neutre dans sa rédaction (on est loin des standards utilisés par Google), quelque chose que l'on ressent également sur le site, le choix du nom de domaine (amdflaws.com), la présence d'une vidéo, ou le fait que ces failles de sécurités renvoient en bas de page vers une agence de relations presse. Dès l'introduction on trouve ce passage par exemple :
"We urge the security community to study the security of these devices in depth before allowing them on mission-critical systems that could potentially put lives at risk."
Dans le cas d'ASMedia, les failles sont présentées comme des backdoors et la conclusion est quelque peu lapidaire :
"This can allow attackers to bury themselves deep within the computer system and to potentially engage in persistent, virtually undetectable espionage, executed from AMD's Secure Processor and AMD's chipset."
La section "Legal disclaimer" à la fin de l'article contient également cette phrase qui n'est pas habituelle dans ce type de communication :
"Although we have a good faith belief in our analysis and believe it to be objective and unbiased, you are advised that we may have, either directly or indirectly, an economic interest in the performance of the securities of the companies whose products are the subject of our reports."
Ce type de mention d'intérêt financier direct ou indirect est surprenant (il n'est pas interdit de publier des "recherches négatives" tout en pariant à la baisse sur le cours d'une action dans la loi américaine), mais la raison pour laquelle on le mentionne est que la publication du whitepaper a été accompagnée, seulement une heure après, par un autre whitepaper de 25 pages (!) d'une société de recherche baptisée Viceroy Research . Sous le nom "AMD - The Obituary" ("l'éloge funèbre"), ils concluent ainsi (on vous passe le reste) :
"In light of CTS's discoveries, the meteoric rise of AMD's stock price now appears to be totally unjustified and entirely unsustainable. We believe AMD is worth $0.00 and will have no choice but to file for Chapter 11 (Bankruptcy) in order to effectively deal with the repercussions of recent discoveries."
Un élément relayé par la presse financière (non sans circonspection) par exemple dans cet article de Bloomberg qui pointe une augmentation significative des options à la baisse sur le titre d'AMD. Bloomberg rappelle que Viceroy Research est considéré comme un short-seller (voir cet article relayé par un lecteur d'Hacker News sur cette particulière société).
Le cours de l'action d'AMD n'a pas particulièrement réagi a la publication de ces informations hier, même si l'action du constructeur est en légère baisse (-1.1%) a l'ouverture aujourd'hui au moment ou nous écrivons ces lignes.
AMD de son côté n'a pas encore réellement communiqué sur le sujet, se contentant simplement d'un billet de blog sur son site réservé aux investisseurs :
"We have just received a report from a company called CTS Labs claiming there are potential security vulnerabilities related to certain of our processors. We are actively investigating and analyzing its findings. This company was previously unknown to AMD and we find it unusual for a security firm to publish its research to the press without providing a reasonable amount of time for the company to investigate and address its findings. At AMD, security is a top priority and we are continually working to ensure the safety of our users as potential new risks arise. We will update this blog as news develops."
GDC: Quelle API de bas niveau va s'imposer ?
Au cours de la semaine de la GDC, nous avons demandé à la plupart de nos interlocuteurs quel était leur pronostic officiel dans la bataille qui s'annonce entre les différentes API de bas niveau. Vulkan va-t-il avoir une chance sous Windows ? La réponse a été quasi unanime : non. Explications.
Avec Mantle, AMD et Frostbite ont démontré qu'exploiter des API graphiques de plus bas niveau dans les moteurs de jeu PC était tout à fait réaliste et n'avait pas de raison d'être une exclusivité des consoles. Depuis, la liste de ces API s'est allongée :
- Mantle supporté par les Radeon sous Windows 7/8/10
- Direct3D 12 supporté par tous les GPU sous Windows 10 et par la Xbox One
- Metal supporté par les SoC Apple sous iOS
- Vulkan supporté par tout type de GPU sous tout type de plateforme
- et nous pouvons y ajouter GNM, l'API de la PS4
Sur le papier, Vulkan a un avantage important puisqu'il va permettre à un moteur graphique de supporter de nombreuses plateformes et notamment Android et Linux/SteamOS. Pourquoi ne pas supporter Windows au passage ? Si les spécialistes du moteur de jeu prévoiront probablement cette possibilité, personne ne s'attend à ce qu'elle soit exploitée.
Microsoft ne compte pas proposer de support de Vulkan pour la Xbox One, ce qui va forcer les développeurs à exploiter Direct3D 12. Vu la proximité avec la plateforme Windows, il n'y aura pas d'intérêt à y proposer Vulkan sur PC.
Mais ce n'est pas tout. Vulkan pourrait avoir des difficultés sur d'autres fronts. Alors que nous l'imaginions en bonne position sous Android, la plupart de nos interlocuteurs ont émis un avis plus mitigé. A la question de savoir pourquoi, nous avons en général reçu un sourire gêné en guise de réponse car une autre API est embusquée. C'est un secret de polichinelle dans le milieu des spécialistes de la 3D : Google prépare sa propre API graphique de bas niveau. Une annonce qui pourrait avoir lieu fin mai lors de la conférence Google I/O ou un peu plus tard cette année.
Cette API devrait être ouverte dans le sens où ses spécifications seront fixées par Google, mais son implémentation pourra se faire sur d'autres plateformes. De quoi venir concurrencer directement Vulkan, par exemple si elle était portée sous Linux et SteamOS.
Cela ne veut pas dire pour autant que Vulkan est mort-née. Il y aura vraisemblablement toujours des développeurs qui voudront profiter de son support multiplateformes, surtout dans le monde mobile. Mais à terme, il semble évident que chaque plateforme voudra contrôler sa propre API graphique de bas niveau, ce qui est naturel pour les acteurs concernés. Les spécialistes des moteurs graphiques, tels que l'Unreal Engine, l'Unity, le Cry Engine ou encore le Frostbite, y trouveront probablement leur compte, mais le développement de moteurs "indépendants" risque de devenir difficile à supporter pour de plus en plus de studios.
IDF: Google, nouveau partenaire privilégié
Au delà des annonces côté matériel, la seconde keynote d'Intel a été l'occasion de parler des partenaires côté système d'exploitation. Si quelques minutes auront été passées sur le cas Microsoft, qui s'est notamment félicité d'avoir écouté sa communauté de développeur en publiant - hier - la version RTM de Windows 8.1 sur Technet et MSDN (Microsoft ne souhaitait pas livrer cette RTM en avance aux développeurs, avant de changer d'avis sous une certaine pression), la majeure partie de l'attention était autour d'un autre éditeur de systèmes d'exploitation : Google. Les deux systèmes de la marque ont été amplement mis en avant, avec les différentes initiatives d'Intel côté support.
Commençons par Android ou plusieurs axes de contributions importants ont été mis en avant. Intel a indiqué avoir plus de 1000 développeurs qui collaborent au développement de diverses parties du système. Outre le noyau et les pilotes, deux points particuliers ont été évoqués, à commencer par le développement d'une version 64 bits d'Android, quelque chose qui concerne uniquement Intel à court terme car pour rappel, les processeurs ARM sous Android restent encore des processeurs 32 bits (ARMv8, la version 64 bits n'est pas attendue avant 2014, même si Apple à annoncé hier pour rappel un SoC ARM 64 bits pour l'iPhone 5S).
L'autre axe de développement concerne la question des applications natives. Si Java reste le langage privilégié sous Android, il est également possible de compiler des applications natives. Et si le NDK permet de compiler à la fois pour ARM et x86, la majorité des applications existantes ne ciblent que les processeurs ARM. Intel propose une couche d'émulation pour ces applications mais essaye de multiplier les partenariats pour inciter au développement x86 natif. Intel avait invité Gameloft pour montrer la dernière version de son jeu de course, Asphalt 8, lancé dès aujourd'hui sur Google Play en version native x86.
ChromeOS était également à l'honneur et de la même manière, Intel a mis en avant ses contributions au système d'exploitation de Google, certaines étant indirectes. Intel contribue en effet principalement au noyau Linux pour ses pilotes, mais participe aussi aux projets WebKit/Blink par exemple côté navigateurs.
Au delà de ces initiatives, quatre machines sous ChromeOS ont été annoncée. Chez HP, Acer et Toshiba, il s'agissait de Chromebook sous Haswell. La quatrième machine proposée par Asus est la plus originale : elle prend le nom de Chromebox et il s'agit, un peu à la manière d'un NUC, d'une machine desktop très compacte. On ne sait rien du prix et de la disponibilité des divers modèles, qui ne devraient pas être annoncés avant le mois prochain.
Notez enfin que Sundar Pichai, Senior Vice President de Google en charge de ChromeOS et d'Android est passé sur scène pour parler rapidement des relations entre sa société et Intel. Un signe de plus de la volonté de la firme de Santa Clara de miser sérieusement sur d'autres écosystèmes que ceux de Microsoft.
IBM ouvre un peu plus l'architecture Power
Développée par IBM à la fin des années 80, l'architecture Power est une architecture RISC développée à l'origine pour des utilisations type station de travail et serveur, et qui a connu son heure de gloire avec l'alliance Apple/IBM/Motorola dans les années 90 pour produire ce qui deviendra l'architecture PowerPC, dérivé grand public de l'architecture Power.
Cette architecture Power est progressivement ouverte (par le biais de power.org ) depuis 2004 dans le cadre d'usages "grand public", et a été utilisée dans des co-développements comme le Cell avec Sony et Toshiba, ou des utilisations embarqués comme le PA6T de P.A. Semi. IBM a continué cependant en parallèle de développer la déclinaison serveur haut de gamme avec des processeurs comme les POWER4/5/6/7 destinés à des serveurs fabriqués exclusivement par IBM.
L'un peu encombrant Power5 en version MCM (Multi Chip Module) proposait 8 cœurs en 2003
La concurrence extrêmement forte du x86 sur le marché serveur aura probablement poussé IBM à vouloir changer de stratégie puisque le géant américain vient d'annoncer l'ouverture à licence des technologies propriétaires autour de la déclinaison serveur des POWERn, y compris les technologies relatives aux futurs POWER8.
Le constructeur essaye donc de créer un écosystème autour de ses serveurs en ouvrant le firmware (BIOS) en open source, ce qui permettra l'arrivée de partenaires côté cartes mères. Le communiqué de presse annonce l'arrivée de Tyan pour remplir ce rôle dans le nouveau consortium open-power.org , mais aussi de Nvidia dans le but d'intégrer ses GPU et Mellanox pour les interconnexions. Google fait également partie des membres du futur consortium, sans que son rôle soit précisé. Si l'ouverture d'une architecture de plus, qui plus est très focalisée sur les hautes performances est toujours une bonne chose, il faudra voir si en pratique cela permettra de relancer l'activité plutôt en berne d'IBM sur le marché des serveurs suite à la forte concurrence des x86 très abordables en comparaison.