Pour la troisième fois cette année, Intel vient d'annoncer une nouvelle série de failles  qui touche son système Management Engine. Pour rappel, l'Intel Management Engine est basé sur un coprocesseur indépendant et un firmware (basé sur le microkernel MINIX  comme s'en émouvait son créateur, Andrew S. Tanenbaum, qui interpellait il y a quelques jours  Brian Krzanich pour le manque de courtoisie de la société).

Ce système fait ainsi tourner un certain nombre de modules , certains optionnels et livrés avec certains modèles de chipset uniquement (comme les fonctionnalités iAMT qui visent la gestion des parcs informatiques d'entreprise), d'autres non (la validation du processeur, chipset et microcode par exemple, ou des vecteurs d'implémentation de DRM comme le PAVP  et SGX). Le propre du ME est d'être fonctionnel en permanence (du moment que la carte mère est alimentée), d'avoir un accès total au système et de ne pas être désactivable par l'utilisateur, ce qui en fait un vecteur d'attaque particulièrement dangereux en cas d'accès au kernel MINIX.

Un tweet  il y a deux semaines de cela avait montré une faille de la sorte avec un accès complet obtenu en mode local via un port USB. Cette faille est l'une de celle corrigée aujourd'hui par Intel dans sa mise à jour  (il y en a d'autres dont une avec accès distant mais qui nécessite une authentification locale, même si elles sont jugées moins importantes). Contrairement à certaines failles pointées plus tôt qui ne touchaient que les systèmes utilisant les modules AMT, cette faille touche tous les systèmes Intel à partir de la génération Skylake (ME version 11) qui sont donc tous potentiellement vulnérables (l'implémentation actuelle présentée requiert l'activation du mode USB DCI dans le BIOS).

Pour pouvoir s'en prémunir, il faudra passer par une mise à jour de BIOS (certaines mises à jour de BIOS peuvent inclure une mise à jour du ME, quelque chose de généralement optionnel sur la plupart des cartes mères modernes qui vous proposent d'effectuer une mise à jour simple, ou également du ME), et donc qu'un BIOS existe pour sa plateforme ce qui ne sera pas le cas des plus anciennes qui ne sont plus supportées (par Intel ou les constructeurs de cartes mères). Tout au plus, Intel fourni un outil pour détecter la version du ME.

A défaut, ces utilisateurs pourront regarder du côté de me_cleaner  qui tente de limiter au maximum la taille du firmware en désactivant la plupart des modules de l'IME, tout en gardant à l'esprit que cela ne résoudra pas la totalité des failles (comme la faille USB ci-dessus).

Ces failles de sécurité à répétition montrent les craintes légitimes que l'on peut avoir sur ce système implémenté par Intel sur toutes ses plateformes et le côté quelque peu trivial avec lequel le constructeur adresse les failles qui le touche. Contrairement au microcode des CPU, diffusable à grande échelle par Intel via des mises à jour de BIOS mais aussi des mises à jour des systèmes d'exploitation, la mise à jour du ME est beaucoup plus complexe. Elle requière au minimum la collaboration de deux acteurs, Intel et un OEM (dont les pratiques de suivi des mises à jour peuvent être variables, particulièrement dans le monde des PC portables), ainsi qu'une action non triviale de l'utilisateur. Ce n'est pas une pratique que l'on peut légitimement accepter pour un tel niveau de criticité.

Il faut enfin noter que si Intel est pointé (une nouvelle foi et à raison) du doigt, en grande partie par son obscurantisme durant des années sur les capacités réelles de l'IME, les dernières plateformes d'AMD disposent aussi d'un système équivalent, et pas plus documenté (on sait tout au plus qu'il s'agit d'une implémentation/variante du Trustzone d'ARM ) via son PSP  qui n'est pas non plus désactivable.

A l'occasion des 39 ans du lancement du premier processeur x86 Intel, le 8086, le constructeur revient via un billet de blog  sur les améliorations apportées au jeu d'instructions au fil des années. Mais alors que la première moitié du billet est assez classique et mélange historique et marketing, la seconde évoque la protection juridique de ces améliorations, avec pas moins de 1600 brevets déposés dans le monde.

Intel rappelle ensuite qu'il a dû poursuivre diverses entreprises par le passé pour faire valoir ses droits, surtout à ses débuts : United Microelectronics Corporation, Advanced Micro Devices, Cyrix Corporation, Chips and Technologies, Via Technologies et plus récemment Transmeta Corporation.

Vient ensuite cette partie :

However, there have been reports that some companies may try to emulate Intel's proprietary x86 ISA without Intel's authorization. Emulation is not a new technology, and Transmeta was notably the last company to claim to have produced a compatible x86 processor using emulation (“code morphing”) techniques. Intel enforced patents relating to SIMD instruction set enhancements against Transmeta's x86 implementation even though it used emulation. In any event, Transmeta was not commercially successful, and it exited the microprocessor business 10 years ago.

Only time will tell if new attempts to emulate Intel's x86 ISA will meet a different fate. Intel welcomes lawful competition, and we are confident that Intel's microprocessors, which have been specifically optimized to implement Intel's x86 ISA for almost four decades, will deliver amazing experiences, consistency across applications, and a full breadth of consumer offerings, full manageability and IT integration for the enterprise. However, we do not welcome unlawful infringement of our patents, and we fully expect other companies to continue to respect Intel's intellectual property rights. Strong intellectual property protections make it possible for Intel to continue to invest the enormous resources required to advance Intel's dynamic x86 ISA, and Intel will maintain its vigilance to protect its innovations and investments.

Sans les citer, ce qui semblait être au premier abord un gentillet billet de blog anniversaire se transforme clairement ici en un avertissement contre l'émulation x86 actuellement mise au point par Microsoft et Qualcomm pour Windows 10 ARM qui se limite pourtant au 32-bit, et promet donc une guerre juridique à venir entre ces 3 géants !

ARM vient d'annoncer de nouveaux blocs processeurs pour ses partenaires, sous le nom de Cortex-A75 et A55 (pour un rappel sur la stratégie d'ARM, nous vous renvoyons au début de cet article). Ces nouveaux Cortex sont des coeurs CPU clefs en main qui peuvent être utilisés par les partenaires d'ARM pour concevoir leurs SoC.

Les nomenclatures marketing d'ARM sont assez complexes à déchiffrer, la société dispose de plusieurs équipes qui font évoluer en parallèle des versions différentes de leurs architectures. Pour les "gros" coeurs, on retrouve deux familles distinctes avec d'un côté des "très gros" coeurs qui tendent à consommer significativement plus d'énergie. Ce sont les Cortex A15, A57 et A72 développés par l'équipe d'Austin. En parallèle, une autre équipe à Sophia-Antipolis développe des "gros" coeurs un peu plus efficaces comme les A12, A17 et plus récemment A73.

A l'origine, cette gamme était vue comme un intermédiaire par ARM même si la consommation élevée des "très gros" coeurs tend la société à pousser aujourd'hui les coeurs "Sophia" sur le haut de gamme mobile. Cette tendance se confirme aujourd'hui puisque l'A75 est en pratique le successeur de l'A73.

Techniquement ces puces se distinguent par un pipeline plus court, et sur ce point l'A75 ne change rien en gardant un pipeline court de 11 étapes pour les instructions entières. Le plus gros changement concerne le nombre d'instructions décodées par cycle puisque l'on passe de deux instructions décodées à trois, alignant sur cette caractéristique l'A75 avec ce qui se faisait sur les "très gros" ARM. On passe donc en pratique de 6 micro-ops par cycle à 8. Le nombre d'unités reste identique mais l'A75 ajoute des files supplémentaires pour stocker les micro-ops à traiter.

ARM applique un changement similaire pour les instructions flottantes et vectorielles (on parle de NEON dans le marketing ARM, le pendant de SSE/AVX sur x86) avec là aussi la possibilité de décoder trois instructions par cycle. Cela s'accompagne par une file supplémentaire et une troisième unité NEON spécifiquement utilisée pour les accès mémoire.

ARM annonce des gains de performance allant de 20 à 30% pour l'A75 rapport à l'A73 en fonction de la consommation autorisée, ce qui est plutôt intéressant. L'A75 est un bloc qui comme l'A73 est prévu pour le 10nm et il devrait faire son apparition en toute fin d'année ou plus probablement l'année prochaine dans des produits commerciaux.

Un nouveau coeur LITTLE

En plus des gros coeurs dont nous vous parlions au-dessus, ARM propose également des coeurs plus petits, à la consommation beaucoup plus faible et qui ont pour but d'être appairés à des gros coeurs dans ce qu'ARM appelait jusqu'ici des configurations big.LITTLE. Après avoir utilisé dans ce rôle l'A53 depuis plusieurs années (il avait été introduit en 2012 !), ARM propose enfin une nouvelle mouture de son petit coeur baptisée Cortex-A55.

Il s'agit toujours d'un coeur dit "In Order", les instructions ont exécutées dans l'ordre dans lequel elles arrivent (à l'opposé des processeurs plus gros/modernes qui utilisent des architectures "Out Of Order", les instructions sont réordonnancées pour optimiser l'exécution et améliorer le parallélisme).

Il y a assez peu de changements sur l'A55, le plus gros concerne la séparation des unités de lecture/écriture mémoire ainsi qu'un nouveau prédicteur de branchements. Le reste des changements se situant au niveau des caches mémoires qui ont été reconfigurés.

ARM annonce des gains de performances autour de 20% sur l'A55 à fréquence égale par rapport à un A53, des gains qui peuvent cependant monter beaucoup plus haut quand on prend en compte les caches. Sous SPECFP2006, la société annonce ainsi 38% de gains.

DynamIQ, big.LITTLE V2.0

Le concept du big.LITTLE évolue et prend désormais le nom de DynamIQ. ARM a repensé la manière dont il permettait de relier ses coeurs entre eux et propose un nouveau concept qui résout beaucoup de problèmes sur le papier.

L'idée principale est de remplacer big.LITTLE par des "clusters" qui peuvent regrouper jusque huit coeurs. On pourra mélanger au sein d'un cluster différents types de coeurs (par exemple quatre A75 et quatre A55) ce qui engendre un changement important au niveau de la structure des caches. Désormais, chaque coeur ARM (A55 ou A75) disposera de son propre cache L1 et de son propre cache L2. Ce changement est bienvenu et devrait éviter ces bugs embarrassants comme celui de Samsung et de son M1  qui mélangeait ses coeurs à des A53 avec des lignes de caches différentes.

Tous les coeurs d'un cluster partageront un cache L3 commun (jusque 4 Mo) et l'on pourra disposer de plusieurs clusters - jusque 32 - au sein d'une puce (quelque chose qui devrait surtout servir pour d'éventuelles versions serveurs de ces processeurs). Une organisation qui n'est pas sans rappeler celle utilisée par AMD avec ses CCX dans Ryzen, on notera qu'ARM indique que son cache L3 peut être partitionné dynamiquement pour certains coeurs ou pour d'autres applications.

En bref

On notera également côté GPU l'arrivée une version optimisée du Mali G71, baptisé G72 pour lequel il n'y a pas de changement majeur au niveau de l'architecture Bifrost d'ARM. L'augmentation de la taille des caches permet d'augmenter l'efficacité énergétique ce qui est appréciable.

Si les modifications effectuées sur les Cortex A75 et A55 sont intéressantes, on retiendra surtout de l'annonce d'ARM l'arrivée de DynamIQ qui devrait permettre de mieux exploiter les coeurs. Car si big.LITTLE était sur le papier une bonne idée, son implémentation pratique avait montré de multiples limites. Cette nouvelle approche sous la forme de clusters contribue aussi sur les gains de performances, tout comme la réorganisation des caches.

Le sous-système mémoire des Cortex a toujours été la faiblesse de l'architecture avec des contrôleurs extrêmement optimisées pour la basse consommation, mais pas forcément pour les performances ce qui donne aux architectures ARMv8 tierces (comme celles d'Apple et même de Samsung) un avantage en général très net sur ce point.

Il y a quelques jours de cela, le site Digitimes avait fait circuler une rumeur par laquelle TSMC et Samsung disposeraient de yields trop bas pour leur production 10nm. De quoi lancer multiples spéculations sur des retards de production.

Pour rappel, TSMC et Samsung ont annoncé avoir commencé la production en volume (des puces qui se retrouveront donc dans des produits commerciaux) de leurs nouveaux process 10nm au quatrième trimestre.

Pour tenter de couper l'herbe sous le pied des rumeurs, TSMC a confirmé une fois de plus au Taipei Times  que non seulement la production avait bien commencé au quatrième trimestre, mais que le 10nm générerait des revenus pour TSMC dès le mois prochain - ce qui signifie en pratique que TSMC aura livré des puces à ses clients.

Sur la question des clients, Digitimes avait spéculé qu'en plus d'Apple (client traditionnel en début de disponibilité de node pour TSMC), MediaTek et HiSilicon seraient parmi les premiers clients 10nm de TSMC. Des informations plutôt surprenantes pour les deux sociétés qui produisent (en grand volume) des SoC ARM à prix réduit, utilisant les blocs d'IP génériques (les "Cortex-A") dessinés par ARM.

Qualcomm, l'autre client habituel des débuts de nodes chez TSMC aurait cette fois ci misé sur Samsung pour le 10nm. Samsung n'a pas réagit aux rumeurs lancées par Digitimes. On notera cependant qu'il y a quelques semaines de cela, Samsung avait évoqué l'idée de mieux séparer ses activités. En effet, la marque coréenne entre assez régulièrement en conflit d'intérêts avec les éventuels clients de son activité "fabrication". Une situation que l'on a vue à de nombreuses reprises avec Apple par exemple.

Une restructuration qui séparerait les équipes de design de puces utilisées par Samsung (LSI et SoC) de l'activité "fab" serait donc envisagée selon nos confrères de Business Korea . Une séparation qui servirait surtout à rassurer d'éventuels clients car en pratique Samsung ne compte pas se séparer de son activité "fab".

Lancé en 2012, Windows RT qui était une version ARM 32-bit de Windows 8 s'est avéré être un echec. Il faut dire qu'au-delà du système et des applications Windows natives, les utilisateurs n'avaient accès qu'aux applications distribuées UWP (Universal Windows Platform) c'est-à-dire distribuées via le Windows Store utilisant l'API WinRT.

Pour Windows 10 sur ARM, Microsoft a appris de cette erreur. Si cette version sera ARM 64-bit et supportera les applications UWP, elle disposera également d'une émulation native permettant d'exécuter les applications Win32, soit x86 32-bits ce qui permettra d'avoir accès à l'énorme historique d'applications Windows !

Cette version ARM 64-bit a été développée en partenariat avec Qualcomm, et si la démonstration tourne sur un Snapdragon 820 il faudra a priori atteindre le second semestre 2017 et le Snapdragon 835 en 10nm pour voir débarquer des PC équipés de Windows 10 ARM. S'il n'est pas question d'attaquer Intel sur le plan performances pures, d'autant plus avec une surcouche d'émulation, voilà qui devrait faire bouger les lignes dans le secteur de l'ultra-mobilité et éventuellement sur l'entrée de gamme, des segments sur lesquels Microsoft prenait un risque de plus en plus grand en restant uniquement associé à Intel.