Les derniers contenus liés aux tags AMD et Windows

Afficher sous forme de : Titre | Flux

Pilotes Radeon et GeForce pour Far Cry 5

Publié le 27/03/2018 à 16:49 par Guillaume Louel

A l'occasion du lancement de Far Cry 5, AMD et Nvidia proposent coup sur coup de nouveaux pilotes optimisés pour ce titre. Chez AMD tout d'abord, outre le support optimisé de ce titre (AMD note malgré tout que ces pilotes peuvent causer des clignotements dans ce jeu en multi GPU après avoir utilisé Alt+TAB), on retrouve également quelques correctifs.

Pour Final Fantasy XV, certains effets de lumières sur les arbres à certains endroits de la carte ont été corrigés, tout comme un bug qui pouvait causer un crash à l'arrivée du second chapitre. Dans la liste des "problèmes corrigés", le constructeur parle aussi d'une baisse de performances sur certaines charges "blockchain" comparé aux pilotes précédents, ce qui nous rend assez circonspects, on ne sait pas si la chose est corrigée ou si c'est ce pilote qui est plus lent. On notera également dans les problèmes connus que ces pilotes peuvent causer un crash système après une utilisation prolongée et simultanée de 12 GPU (!) pour des tâches compute. Ces pilotes 18.3.4 sont téléchargeables sur le site du constructeur .

Chez Nvidia, il s'agit des pilotes 391.35 qui apportent un support pour ce titre. Quelques bugs ont été corrigés, un problème d'Alt-TAB sous Diablo III en SLI avec V-Sync actif qui pouvait planter le jeu, et une fuite mémoire de GeForce Experience lorsque l'on utilise la fonction "freestyle". Plus important, le pilote apporte des correctifs de sécurité pour ses pilotes. 7 CVE sont pointés par Nvidia, plusieurs s'attaquant au pilote "noyau" (nvlddmkm.sys) avec des risques importants d'escalade de privilèges.

Contrairement aux autres périphériques sous Windows dont les pilotes fonctionnent dans l'espace mémoire utilisateur (une restriction imposée par Microsoft pour réduire les plantages), les GPU disposent encore d'un petit pilote niveau "noyau", ce qui permet théoriquement aux pilotes GPU de planter complètement votre système (ou d'être un vecteur de failles) contrairement à un pilote USB par exemple, quelque chose dont Microsoft se plaint souvent même s'ils sont responsables de cette situation !

Certaines failles concernent également le pilote en espace mémoire "utilisateur". Nous ne pouvons que vous conseiller de mettre à jour vos pilotes qui sont téléchargeables ici pour Windows 7 , et là pour Windows 10 .

Radeon Software 18.3.3 beta avec Vulkan 1.1

Publié le 20/03/2018 à 13:27 par Guillaume Louel

AMD a mis en ligne ces dernières heures une nouvelle version beta de ses pilotes graphiques. On retrouve comme souvent un support "optimisé" pour de nouveaux titres, cette fois ci il s'agit de Sea of Thieves et A Way Out.

Côté bugs, un problème de stuttering intermittent sous Forza Motorsport 7 à été corrigé. Pour Final Fantasy XV, ce sont des clignotements et objets disparaissant qui ont été résolus pour les configurations Multi GPU. Enfin pour Battlefront 2, c'est un plantage au lancement du titre, là encore sur des configurations Multi GPU, qui a été corrigé.

L'autre nouveauté de ces pilotes est qu'ils apportent un support de la version 1.1 de Vulkan, l'API "bas niveau" de Khronos Group. Cette nouvelle version avait été annoncée il y a quinze jours de cela  apporte plusieurs nouveautés dont les "Subgroup Operations" pour partager des données entre plusieurs tâches sur un GPU et une nouvelle version du langage intermédiaire de shaders, SPIR-V 1.3 (et de ses outils). Nvidia avait de son côté proposé un pilote beta spécifique pour Vulkan 1.1 au moment de l'annonce .

L'autre objectif pour Khronos Group est un support multi plateforme universel. Quelques jours avant l'annonce de cette version 1.1, la "Khronos Vulkan Portability Initiative"  avait été annoncée avec pour but de créer des couches de compatibilités fines s'appuyant sur les API bas niveau natives des plateformes, comme DirectX 12 pour Windows ou Metal chez Apple.

Pour rappel, Apple gère le déploiement (et le co développement) des pilotes graphiques pour sa plateforme contrairement à ce que l'on voit sous Windows, et il n'y a pas de support natif dans l'OS pour Vulkan. Microsoft n'en propose pas non plus pour Windows, le support y étant assuré par les pilotes directement (cf cette actualité), comme cela était le cas pour OpenGL dans les dernières versions de Windows.


Avec LunarG et MoltenVK, Valve annonce 50% de performances en plus sous Dota 2 par rapport à l'implémentation OpenGL sur Mac

Proposer des couches intermédiaires est donc une solution assez pragmatique, car si en général ces couches sont assez coûteuses, toutes ces API bas niveau sont excessivement proches dans leurs caractéristiques (elles sont après tout de bas niveau et "très proches du métal" avec des similarités larges) ce qui limite grandement l'impact sur les performances. Valve et Brenwill Workshop ont rendu open source LunarG  (un SDK MacOS Vulkan spécifique développé par Valve) et MoltenVK  (une couche de traduction Vulkan vers Metal pour MacOS et iOS) en partenariat avec Khronos. Vous pouvez retrouver une présentation de cette initiative sur cette page  qui évalue également la portabilité pour DirectX 12. Une autre initiative est celle de Mozilla  dans le cadre du développement de son API cross plateforme bas niveau gfx-rs .

Le téléchargement de ces pilotes AMD s'effectue sur cette page du site du constructeur .

Des failles de sécurité spécifiques aux Ryzen ?

Publié le 14/03/2018 à 16:11 par Guillaume Louel

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."

Focus : Windows 10, Meltdown et Spectre : quel impact sur les performances ?

Publié le 07/02/2018 à 14:41 par Guillaume Louel

Quel est l'impact des premiers patchs des failles Meltdown et Spectre sur notre protocole de test CPU ? Les jeux sont ils également impactés ? Essayons de faire le point !

En début de mois, l'université de Graz  et Google Project Zero  ont annoncé avoir découvert deux failles de sécurité importantes s'appuyant sur les mécanismes de fonctionnement interne des processeurs.

Trois vulnérabilités permettant d'accéder à de la...

[+] Lire la suite

Patch pour le Core Parking pour Ryzen !

Tags : AMD; Ryzen; Windows;
Publié le 06/04/2017 à 23:00 par Guillaume Louel

Enfin ! Il aura fallu un peu de temps, mais AMD vient enfin de confirmer la question de l'impact du Core Parking pour Ryzen sous Windows 10, que nous avions soulevés quelques jours après le lancement de Ryzen. Pour rappel, le Core Parking est une fonctionnalité du scheduler de Windows qui consiste à "parquer" les coeurs d'un processeur en les mettant en veille et en ne les rallumant que progressivement lorsque la charge le nécessite. Cette fonctionnalité a un impact particulièrement important sur les processeurs qui disposent de l'HyperThreading ou du SMT.

AMD confirme aujourd'hui ce que nous avions noté, à savoir que par défaut sous Windows 10, le Core Parking n'est pas réglé de la même manière sur Ryzen que sur les processeurs Intel. Afin de garantir l'équité dans nos tests, nous avions manuellement modifié le profil de gestion d'alimentation "Balanced" de Windows 10 afin de désactiver cette fonctionnalité.

Dans un billet de blog , AMD propose à son tour un nouveau profil de gestion d'alimentation spécifique à Ryzen. Il sera distribué de cette manière dans un premier temps (il est téléchargeable ici ), avant d'être intégré d'ici quelques semaines aux prochains pilotes chipsets d'AMD : l'installation de ce profil deviendra donc automatique.

Pour ceux qui auraient déjà modifié manuellement le Core Parking via les méthodes que nous vous avions conseillé dans nos articles, notez que vous aviez en pratique modifié le profil "Balanced" de Windows. Vous pouvez donc installer directement ce patch qui ajoute un profil supplémentaire que vous pouvez voir ci dessus. En pratique on pourra repasser si on le souhaite à tout moment en mode "Balanced".

Nous avons pu essayer en avance ce nouveau profil qui au delà de la désactivation du Core Parking change d'autres choses :

  • Réduction du seuil de charge nécessaire pour passer à un P-State supérieur (de 60 à 25%)
  • Réduction du seuil de charge nécessaire pour passer à un P-State inférieur (de 20 à 10%)
  • Diminution de l'intervalle entre deux ajustements par le scheduler Windows du P-State (de 30 à 15 millisecondes)
  • Augmentation du seuil de P-State minimal que peut utilise le processeur (augmentation de 5% à 90%)

Ces changements concernent donc en grande majorité les P-State, à savoir les couples de fréquence/tensions auxquels peuvent fonctionner les processeurs. Vous pouvez retrouver un exemple pour le Ryzen 7 1800X ci-dessous :

Techniquement le premier impact de ces changements est qu'AMD n'autorise pas le fonctionnement actif du processeur en dessous du mode P1. Cela revient à ce que l'on voit habituellement avec le profil de gestion d'alimentation "Performance" (dans ce cas, le seuil est à 100%). Cela ne veut cependant pas dire qu'AMD désactive les fonctionnalités d'économie d'énergie de Ryzen. En pratique AMD bypasse la gestion du mode P2 par le scheduler Windows et laisse Ryzen prendre la main pour passer plus rapidement dans les modes d'énergies supérieurs comme le CC6. Ces modes avancés sont gérés directement par le processeur qui peut passer de l'un à l'autre rapidement, en environ 1 milliseconde, là ou le scheduler de Windows ne change les P-States habituellement que toutes les 30 millisecondes.

Les autres changements visent a accélérer le rythme auquel le scheduler Windows peut modifier les P-State justement, en premier lieu en baissant de moitié le temps entre deux changements potentiels, et en modifiant les seuils. En pratique ces changements auront surtout un très léger impact sur la consommation lors de faibles charges ou de charges intermittentes ou la consommation pourra très légèrement évoluer de manière marginale. En pratique cela ne change pas nos mesures de consommation réalisées dans des cas où la charge n'est pas impactée par ces modifications (au repos, charge sur un coeur, charge sur tous les coeurs).

En pratique ce patch permet d'obtenir un niveau de performance similaire au mode "Balanced + Core Parking OFF" que nous avons utilisé dans nos tests, ce qui permet de remonter significativement les performances notamment dans les jeux, comme le rappelle ce graphique :


On pourra se demander pourquoi cette mise à jour n'est pas proposée directement par Microsoft sous la forme d'un patch pour Windows 10. Nous avons posé la question à AMD qui nous a dit qu'ils proposaient pour l'instant cette solution et qu'ils ne pouvaient pas s'exprimer au nom de Microsoft. Sous entendant que la situation pourrait évoluer à l'avenir.

Dans tous les cas on se félicitera qu'AMD ait enfin reconnu ce problème et propose aujourd'hui un correctif officiel !

Top articles