Les derniers contenus liés au tag linux
Microcode final pour Spectre chez Intel
GPUOpen, la réponse d'AMD à GameWorks
Passerelle CUDA pour le kernel linux
Microcode final pour Spectre chez Intel
(0) RéactionIntel 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.
GPUOpen, la réponse d'AMD à GameWorks
Pour répondre au GameWorks propriétaire de Nvidia, AMD renforce sa stratégie open source avec l'ouverture prochaine d'un portail dédié : GPUOpen. Au menu, des samples et des outils distribués sans restrictions dans l'optique de favoriser un partage de connaissances bénéfique pour l'évolution des techniques de rendu.
Lors de l'introduction de ses nouveaux pilotes, Radeon Software Crimson Edition, le Radeon Technology Group d'AMD avait annoncé que ceux-ci ne représentaient qu'un pan de sa stratégie au niveau software et que d'autres éléments suivraient. C'est le cas aujourd'hui avec GPUOpen, une remise en forme de sa stratégie à destination des développeurs. Comme le nom de cette initiative l'indique, AMD mise sur l'open source, tout d'abord dans le monde du jeu vidéo pour lequel les spécialistes du GPU fournissent samples, librairies et autres outils destinés à aider les développeurs à améliorer le rendu graphique et/ou les performances.
Et sans directement citer son concurrent, c'est bien entendu à l'aspect fermé de GameWorks qu'entend s'attaquer AMD. Nvidia préfère en effet conserver un contrôle total sur certaines librairies et dans certains cas les exploiter en priorité de manière à dégager un avantage compétitif direct plutôt qu'à simplement mettre dans les mains des développeurs de quoi les aider à améliorer leurs jeux. Si la philosophie d'AMD est en général tournée vers l'ouverture, il ne faut pas oublier que ces orientations sont également dictées par la force de chacun sur le marché. Nvidia peut profiter du poids de ses parts de marchés énormes pour imposer une stratégie agressive, ce que pourrait difficilement faire AMD dans sa situation actuelle.
A la base de GPUOpen se trouve une philosophie relativement simple : les meilleures innovations découlent du partage des connaissances. L'évolution du rendu graphique dans les jeux est progressive et se fait par petites améliorations successives apportées par différents développeurs. AMD entend donc faire en sorte que sa contribution ne puisse pas entraver cette évolution et pour cela le passage par l'open source est évidemment préférable aux boîtes noires que peuvent représenter certaines librairies concurrentes.
AMD entend ainsi lancer le portail GPUOpen avec un ensemble de contenu open source distribué sur GitHub (via une licence MIT qui offre une exploitation du code sans restrictions). Des effets graphiques directement exploitables, des outils, des bibliothèques et des SDK seront proposés sur ce portail qui sera ouvert dans le courant du mois de janvier. Le succès de cette initiative dépendra bien entendu de la capacité d'AMD à enrichir régulièrement son portail avec de nouvelles choses et avec le niveau de qualité requis pour convaincre un maximum de développeurs, notamment dans le cadre des nouvelles API de bas niveau.
Parallèlement, AMD rappelle que Linux profite depuis quelques temps d'efforts supplémentaires avec AMDGPU, un pilote qui unifie des pans ouverts et fermés/propriétaires avec une même structure, ce qui facilite leur exploitation et leur évolution. A la base d'AMDGPU se trouve un pilote open source (en kernel space) qui peut recevoir des modules ouverts ou fermés suivant les besoins. De quoi permettre à AMD de proposer, sur une même base, un pilote full open source et un autre optimisé pour les performances dans le cadre du jeu et des applications professionnelles. Typiquement, le module OpenGL fermé reste plus performant par exemple mais AMD a pour objectif de passer en open source dès que possible le module OpenCL/Vulkan du pilote "fermé".
L'open source ne concerne évidemment pas que le jeu vidéo et AMD insiste sur son infrastructure open source complète pour le GPU computing ce qui englobe ces nouveaux pilotes Linux et les compilateurs pour lesquels des nouveautés avaient été dévoilées il y a peu. Un ensemble qui permet aux développeurs de mieux comprendre comment leur code est interprété et éventuellement de faciliter l'optimisation et le débogage. Ce qui ne remplace bien entendu pas le besoin pour AMD, avant toute chose, de fournir des outils de qualité et de proposer un écosystème robuste pour convaincre le monde du HPC d'accorder sa confiance dans ses solutions.
Vous retrouverez la présentation complète ci-dessous :
Passerelle CUDA pour le kernel linux
L’université d’Utah, en partenariat avec Nvidia , vient de rendre disponible un projet original pour Linux baptisé kgpu . L’idée est de proposer une passerelle pour le noyau Linux sous la forme d’un mini pilote capable de communiquer avec des modules CUDA, qui continueront tout de même de s’exécuter en mode utilisateur. Sur le papier l’idée n’est pas inintéressante puisque cela permet de décharger certaines tâches systèmes des pilotes du noyau vers la carte graphique et son GPU. Pour mettre en avant l’intérêt du concept, les auteurs ont réecrit un module de cryptage pour eCryptfs en version GPU. Dans ce test que vous pouvez voir ici . Si les résultats sont convaincants en lecture, en écriture les gains dépendent massivement de la taille des données écrites.
Kgpu reste pour l’instant un exercice de style plus qu’autre chose, en grande partie à cause de l’algorithme de cryptage implémenté actuellement (ECB) qui n’est pas considéré comme sécurisé. Dans l’absolu, on peut également se poser la question de l’intérêt d’un cryptage qui nécessite de faire transiter les données dans un espace mémoire utilisateur à cause de la passerelle. En prime, si la méthode qui consiste à utiliser un mini driver côté kernel et un pilote en mode utilisateur est bonne pour la majorité des tâches, dans le cas de tâches critiques comme les accès disques, la gestion de la mémoire peut devenir problématique.
Dans tout les cas, l’initiative n’est pas inintéressante et devrait peut être inciter toute l’industrie qui pousse actuellement le GPGPU à proposer des pilotes OpenCL qui puissent exécuter également du code côté noyau.
