Les contenus liés au tag USB 3

L'USB-IF vient d'annoncer qu'il mettait la touche finale à l'USB 3.2, donc les spécifications définitives sont attendues pour septembre. L'apport principal de cette spécification est la combinaison des deux canaux montants et deux canaux descendants présents au sein des câbles USB Type-C afin de doubler le débit et d'atteindre donc 20 Gbps, une possibilité que nous avions évoqué en 2014.

Cela permettra d'atteindre en pratique des débits de l'ordre de 2 Go/s en USB 3.2 avec un câble USB Type-C certifié actuellement pour l'USB Type C 10 Gbps. Il s'agit probablement en partie d'une réponse à l'offensive récente d'Intel côté Thunderbolt 3 !

Après avoir proposé des contrôleurs SSD, VIA fait de nouveau parler d'elle en annonçant un nouveau contrôleur, le VL716 . Il s'agit d'un contrôleur USB/SATA, du type que l'on trouve dans les boîtiers pour disques durs externes. Ce contrôleur a cependant la particularité d'être le premier à avoir passé les certifications USB Type-C.

Asmedia propose déjà depuis un moment des solutions USB 3.1/SATA comme l'ASM1352R que nous utilisons durant nos tests de cartes mères, mais ce dernier n'était visiblement pas certifié Type-C (bien que notre boitier de test en soit muni). En pratique, nous avons rencontré avec lui un bon nombre de déconnexions à l'usage sous Windows.

 

 

Ce nouveau contrôleur de VIA gère donc d'un côté l'USB 3.1 10 Gbps, avec prise en charge des protocoles de transferts BOT et UASP (voir cet article pour plus de détails), et de l'autre le SATA 6 Gbps.

La puce est relativement petite, 6mm de côté ce qui permet de créer des designs compacts. VIA ne précise pas dans quelle mesure sa puce gère le standard USB Power Delivery. Techniquement, la présence de l'USB Type-C impose une gestion au moins à minima du standard.

L'alimentation d'un SSD (ou d'un disque dur 2.5 pouces) ne posera pas de problèmes, les 5W fournis par tous les connecteurs USB suffisant, mais des disques 3.5 pouces peuvent réclamer une puissance supérieure. En l'état, difficile de dire ce qui est réellement géré. L'illustration fournie laisse penser que l'on devrait retrouver cette puce dans des boîtiers 2.5 pouces.

Si le SATA est limité à 6 Gbps, en pratique passer de 5 à 10 Gbps côté USB devrait être assez bénéfique. Comme nous avions pu le voir dans cet article, les protocoles de transferts USB comme le mode BOT sont particulièrement inefficaces, et les pilotes UASP de Microsoft ne brillent pas non plus par leur rapidité.

Asus a rajouté sur son site web une nouvelle référence de carte mère, la J3455M-E . Sa particularité est d'embarquer, pour la première fois, l'un des tous derniers Atom d'Intel, les Apollo Lake. Pour rappel, Apollo Lake est un SoC 14nm utilisant l'architecture Goldmont que l'on aurait du retrouver également dans les SoC mobiles Broxton. Ces derniers avaient cependant été annulés au mois de mai.

 

 

Le processeur embarqué est un Celeron J3455 . Il s'agit d'un SoC quad core avec une fréquence de base de 1.5 GHz et une fréquence turbo maximale de 2.3 GHz. Il est accompagné de 2 Mo de cache L2, et d'un GPU Intel avec 12 EU cadencé entre 250 et 750 MHz.

Pour la partie SoC, on retrouve d'abord un contrôleur mémoire gérant DDR3L/LPDDR3 1866 et LPDDR4 jusque 2400 sur deux canaux. 6 lignes PCI Express sont présentes, mais limitées au mode 2.0. Notez enfin que l'on retrouve 2 ports SATA 6 Gb/s ainsi que 4 ports USB 3.0 et 4 ports USB 2.0. Le tout tient dans un TDP annoncé de 10 watts.

Côté carte mère, Asus propose deux slots mémoires DDR3 pleine taille, qui ont la particularité de ne pas être côte à côte. On notera qu'Asus indique supporter la DDR3 en plus de la DDR3L. Deux sorties vidéos sont disponibles, une VGA et un HDMI annoncé comme supportant au maximum une résolution de 3840 x 2160 à 30 Hz. Côté PCI Express, on retrouve trois slots, un "x16" connecté en x1, et deux x1. Notez enfin que le son et le réseau sont confiés à Realtek avec les 8111H (Gigabit Ethernet) et ALC887.

Le prix et la disponibilité sont pour l'instant inconnus.

Après avoir annoncé les versions mobiles en juin, AMD lance aujourd'hui la version desktop de ses APU de "7ème génération", les Bristol Ridge. Le lancement s'est fait par le biais d'un simple communiqué de presse  en ce jour férié aux Etats-Unis.

Le lancement est pourtant important puisque c'est en simultanée la première apparition de la nouvelle plateforme AM4 d'AMD, qui acceuillera non seulement les Bristol Ridge, mais également les Zen Summit Ridge. Une apparition toute relative puisque ce lancement est réservé aujourd'hui uniquement aux OEM.

Par rapport aux APU desktop précédentes (Kaveri/Godavari), on trouve un peu plus de changement que côté mobile, en grande partie parce que Carrizo (duquel Bristol Ridge est très très proche) n'avait pas été décliné sur le socket FM2+.

On reste bien entendu sur l'architecture Bulldozer, mais dans sa version Excavator contre SteamRoller précédemment, tandis que côté graphique on passe à la version 3 de GCN. De quoi proposer des gains d'efficacité par rapport a Kaveri... lancé début 2014.

Cela permet à AMD de faire baisser le TDP : bien que l'on reste en 28nm, ces nouvelles APU sont annoncées pour 65 watts. Le modèle le plus haut de gamme, l'A12-9800 est cadencé à 3.8/4.2 GHz pour ses deux modules (4 coeurs), et 1108 MHz pour les 8 CU côté graphique. Des versions 35 watts sont également lancées.

Les Bristol Ridge sont pour rappel des SoC et intègrent entre autre 8 lignes PCIe Gen3, la gestion de quatre ports USB 3.0 ainsi que 2 SATA et deux lignes PCIe Gen3 supplémentaires pouvant être utilisées pour des ports NVMe. AMD lance en simultanée deux chipsets, les A320 (!) et B350 qui rajoutent des ports USB, y compris des ports 3.1 ainsi qu'un plus grand nombre de ports SATA et de lignes PCIe. Un modèle spécifique "Enthusiast" sera annoncé plus tard, on l'imagine à l'occasion de la sortie de Zen.

AMD indique que ces puces seront disponibles dans un premier temps uniquement dans des configurations HP et Lenovo, et que d'autres OEM suivront.

Le communiqué de presse évite par contre la question d'une disponibilité de ces puces en dehors des OEM, ce qui élude la question du prix (la liste de prix d'AMD  n'a pas encore été mise à jour au moment ou nous écrivons ces lignes).

Vous pouvez retrouver l'intégralité de la présentation ci-dessous :

 

 

L'USB-IF vient d'ajouter un nouveau document à la spécification USB 3.1 . Baptisée USB Type-C Authentication Specification, il s'agit d'une spécification optionnelle qui rajoute la possibilité pour un hôte USB d'authentifier les câbles et les périphériques USB. Nous vous avions parlé de l'arrivée de ce protocole en août dernier.

Si l'on peut penser instantanément aux dérives que pourrait provoquer une norme de ce type - certains constructeurs de PC Portables n'autorisant pas l'utilisation de chargeurs tiers par exemple - en pratique les conséquences devraient être un peu plus nuancées, pour ne pas dire positives.

La question de la sécurité a toujours été un problème avec l'USB. Comme la majorité des protocoles mis au point durant les années 90, la question de la sécurité n'a tout simplement jamais été prise en compte dans la spécification. La multiplication incessante des protocoles gérés par l'USB (HID, vidéo, audio, réseau...) complexifiant un peu plus la donne.

Au fil des années, on a pu voir s'empiler un bon nombre de failles, certaines particulièrement importantes comme BadUSB . Le concept est relativement simple à comprendre, l'implémentation de base s'agissait d'une attaque du contrôleur de stockage Phison, très répandu dans les clefs USB (voir notre comparatif). La faille repose sur la possibilité (bien utile) de connecter plusieurs périphériques via un hub.

La modification du firmware transforme ainsi la clef en deux périphériques connectés en simultanée (ou ultérieurement, tout est imaginable), le second périphérique pouvant être un "faux" clavier par exemple ou une fausse carte réseau. De la même manière, des chargeurs "publics" peuvent être modifiés pour insérer un autre périphérique et compromettre l'hôte USB.

Avec l'arrivée de l'USB Type-C et de la dernière version de la norme de chargement (USB-PD 2.0), la situation s'est complexifiée puisque sont arrivés sur le marché un grand nombre de chargeurs et câbles non seulement défaillants, mais parfois excessivement dangereux. En effet si l'USB limitait dans sa version originale à 5 watts la puissance fournie aux périphériques (15W dans un second temps), l'USB-PD 3.0 fait passer le seuil à 100 watts, autorisant le chargement de PC portables (par exemple les Macbook et les Chromebook), mais multipliant surtout les erreurs de design dans les câbles et les adaptateurs Type-A vers Type-C.

Une situation tellement catastrophique qu'un ingénieur de chez Google, Benson Leung, s'est distingué en achetant et testant les différents modèles disponibles sur le marché pour vérifier s'ils étaient conformes aux spécifications. Il maintient ainsi une liste de câbles certifiés dans ce document en ligne .

Les mauvais designs ne sont cependant pas l'apanage de l'USB Type-C puisqu'à été découvert il y a quelques jours un chargeur USB laissant passer directement le 230V vers les prises USB . Electrisant !

Et si l'on ajoute des idées surréalistes comme WebUSB , une initiative de Google pour autoriser la création de drivers USB... en Javascript (!), il est difficile de penser qu'il n'est pas indispensable d'améliorer rapidement la sécurité de l'USB.

Regroupant toute l'industrie (d'Intel à Microsoft en passant par AMD, Apple, Google, STMicro... et même VIA !), la spécification décrit un système d'authentification optionnel basé sur un système de certificats présents dans les périphériques, l'hôte ayant charge de valider leur authenticité. Le protocole s'adapte à la fois aux périphériques (qui utilisent les voies de transferts de "données") et aux chargeurs.

Ce qui se passe en cas de périphérique non conforme reste la responsabilité du système d'exploitation de l'hôte USB. En cas de branchement d'un chargeur non certifié, le système d'exploitation pourra par exemple avertir l'utilisateur d'un problème potentiel, lui laissant le choix d'autoriser ou non la connexion. La spécification décrit également un scénario d'entreprise ou les systèmes d'exploitations pourront être configurés pour n'autoriser le branchement que de certaines clefs USB dont le certificat a été autorisé par le département informatique de l'entreprise.

De nombreux scénarios sont envisageables et si l'on peut craindre qu'un constructeur tente de fermer l'USB a ses seuls périphériques, la norme semble avoir été pensée pour maximiser l'interopérabilité. Il sera important de voir dans les mois à venir de quelle manière seront implémentés précisément les restrictions dans les systèmes d'exploitation, en notant qu'a plusieurs reprises, la spécification sous entend un cas particulier pour la "certification" USB.

L'USB-IF propose en effet depuis des années des certifications pour les différents produits (via des compliance workshop ), qui se traduisaient simplement par le droit d'utiliser ou non le logo USB (un "droit" facilement contournable pour les contrefaçons). Tout laisse penser que l'USB-IF signera lui même un certificat (un périphérique peut en contenir plusieurs) pour les périphériques ayant passé les tests de conformité même si la chose n'a pas été explicité clairement.

Le communiqué de presse , tout comme la spécification font ainsi référence à plusieurs reprises au cas des chargeurs USB-PD certifiés, laissant penser que l'interopérabilité des chargeurs a bel et bien été prise en compte. C'est en tout cas en ce sens que l'USB-IF semblait se diriger l'été dernier.

MAJ 18/04 : L'USB-IF nous a confirmé qu'il signerait lui même un certificat principal pour chaque revendeur, certificat qui servira de base à la signature de certificats signés par les revendeurs eux mêmes conformément à une procédure définie (un champ dans le certificat permet de s'assurer que le produit à passé les tests de conformité si nécéssaire, via Internet). Les systèmes d'exploitation pourront donc simplement valider tous les produits "conformes" et autoriser l'interopérabilité, ce qui est le but de ce protocole.