Mardi 12 novembre, Arte diffuse le concert du Bal des enragés au Helfest 2019.
L’attention du public ainsi détournée, Intel en profite pour lancer une vague de correctifs, 77 correctifs, un grand nombre de CVE (des failles) y est dévoilé. Les failles concernent les processeurs eux‑mêmes (et microcontrôleurs) et les micrologiciels trop nombreux qui tournent dans vos cartes‐mères.
Sommaire
Matériel
Fin mai 2019, Intel dévoilait une faille autour de sa technologie MDS.
MDS est une optimisation qui permet de remplir des petites structures temporaires (micro‐architecturaux) lors des opérations load, fill et store. Lorsque le code d’une branche est rencontré, le mécanisme de prédiction va exécuter le code en avance sans attendre le résultat de la branche et ainsi remplir ces structures. Consultez ce diagramme pour mieux vous le représenter. En cas d’invalidation de la branche, ces structures ne sont pas vidées.
Exploitée par le biais désormais célèbre de l’attaque par canal auxiliaire d’exécution spéculative — speculative execution side channel —, la faille permet trois attaques : RIDL, Fallout et zombieload.
Pour les contrer, les développeurs du noyau Linux ont d’abord introduit le paramètre de démarrage mds. Enfin, parce que, bon, ça commence à bien faire, la version 5.2 amène le paramètre mitigation qui permettra à terme d’activer ou non une bien belle collection de contre‑mesures processeur.
Cette fois, Intel remet le couvert avec la technologie TSX Asynchronous Abort (TAA), liée aux extensions TSX déjà abordées lors de faille Lazy‑FPU. Souvenez‐vous, il est noté à propos de ces extensions que « ce serait presque étudié pour ». L’exploitation de la faille repose aussi sur des registres dits « micro‑architecturaux ». De fait, les correctifs du mois de mai n’ont corrigé qu’une partie du problème…
La contre‑mesure repose sur le détournement d’une instruction obsolète, ou annexe, pour nettoyer les registres concernés par la faille. Ceci implique une mise à jour du microcode et du système, ce dernier devant appeler à point nommé cette instruction. En cas d’annulation de transaction TSX, les écritures effectuées au cours de la transaction sont annulées et les registres restaurés. Mais, lorsqu’une annulation en cours est asynchrone, une opération load peut encore se terminer et lire ces registres micro‐architecturaux pour les faire passer à la branche exécutée de manière spéculative.
Sous Linux, le paramètre d’amorçage tsx_async_abort=off|full a été ajouté pour gérer les contre‑mesures. La directive tsx=off|on|auto autorisera au non les extensions TSX. Vous pouvez combiner ces deux variables.
Ce n’est pas tout, une autre faille Jump Conditional Code Erratum, toujours liée à cette complexité micro‐architecturale, est annoncée. Une série d’instructions appelées micro‑ops, est mise en cache (structure DSB) et décodée en dehors de sa chaîne de traitement. Seulement l’une de ces instructions (JCC) peut provoquer un comportement indéfini lorsqu’elle est mal alignée.
La contre‑mesure consiste à éviter que toute instruction de saut conditionnel soit mise en cache DSB, d’où de nombreux retours sur le traitement standard et une perte de performance significative. Évidemment, Intel recommande donc de mettre à jour les microcodes de ses processeurs via les outils de vos distributions et systèmes d’exploitation :
- devcpu-data, pour FreeBSD ;
- intel-microcode, pour Debian ;
- microcode_ctl, pour la famille Red Hat (RHEL, Fedora et CentOS) ;
- intel-ucode, pour Arch Linux.
Sans lien avec MDS, la faille Machine check error erratum permet à un attaquant de redémarrer ou d’arrêter un système. Une instruction fetch dans certaines conditions va lever par erreur l’exception machine check et provoquer un redémarrage ou un arrêt.
Les cartes graphiques ne sont pas épargnées, via notamment le mode d’exécution en ring‑2, System Management Mode (SMM), qui permet d’interrompre l’exécution normale du système d’exploitation pour passer la main à un micrologiciel. On peut se demander si cette faille n’est pas liée au correctif du SDK SGX, qui a un mode d’exécution réservé dans lequel aucun autre mode (ou ring) n’est censé pouvoir accéder.
Sous Linux, vous trouverez dans /sys/devices/system/cpu/vulnerabilities/ une liste des failles. Il suffit de lancer un cat sur chaque fichier de ce répertoire pour obtenir le statut de votre processeur.
Sous FreeBSD, la clef hw.mds_disable active les contre‑mesures.
Micrologiciels (firmwares)
Ces failles matérielles ont pour effet de bord de se propager aux micrologiciels fournis par Intel pour vos machines, qui vont permettre d’exploiter au mieux ces failles. Et ce, d’autant plus que le code, fermé, de ces derniers, ne semble pas d’une qualité très élevée, malgré des noms pompeux, avec trust dedans.
On trouve beaucoup d’erreurs de codage, telles que :
- insufficient session validation ;
- insufficient access control ;
- insufficient input validation ;
- unhandled exception ;
- stack overflow ;
- out of bound read ;
- memory corruption ;
- heap corruption.
Intel® Trusted Execution Engine (TXE), Technologie Intel® Platform Trust
Elles sont supposées être les garantes du sytème d’exploitation et des environnements que vous allez faire tourner, basées sur un module TPM, troué lui aussi. Au menu, élévation de privilèges et fuite de données.
Malheureusement, on commence à trouver aussi ce genre de micrologiciels (trusted) sur des architectures non‑Intel, comme des systèmes monopuces (SoC) ARM.
Intel® Active Management Technology (AMT)
Un outil d’assistance et de maintenance à distance, qui permet une élévation de privilèges. À distance.
Il repose principalement sur l’Intel Management Engine (IME). Autrefois planqué dans le hostbridge, aujourd’hui dans le PCH. Pensez à le désactiver, si vous le pouvez.
Un outil qui repose sur plein de petits modules :
- Intel® Converged Security and Manageability Engine ;
- Intel® Securing and Management Engine ;
- Intel® Server Platform Services.
Baseboard Management Controller
C’est un autre outil de maintenance à distance que l’on retrouve sur les serveurs et modules de calcul, dont une version libre existe. Pour celui‑ci, il y a un risque critique d’élévation de privilèges, déni de service et de fuite de données, via le réseau.
UEFI
Une vulnérabilité a été annoncée sur la famille Xeon.
Périphériques
Les microcodes des cartes réseau Intel Ethernet 700 Series permettent une évaluation de privilèges, déni de service et fuite de données.
Logiciel
Le SDK Intel® SGX (Software Guard Extensions) permet une élévation de privilèges.
Télécharger la dernière version.
[N. D. M. : le site 01.org appartient bien à Intel.]
Bilan
Intel affirme que la majorité de ces failles a été trouvée « en interne ». Pourtant, on trouve nombre de chercheurs indépendants remerciés dans les CVE. En fait, une bonne partie des failles découvertes dans les microcodes me semble sortie d’un logiciel d’analyse de code.
Malheureusement, une partie de ces contre‑mesures et mises à jour, surtout celles concernant les micrologiciels, devront être apportées par les constructeurs, les fournisseurs de cartes. Les machines dédiées au marché des particuliers risquent d’attendre longtemps…
Greg Kroah‑Hartman a conclu lors de l’Open Source Summit Europe : vous allez devoir choisir entre la sécurité et la performance. Car, désactiver l’hyperthreading, les extensions TSX, retirer des µops du cache induit une importante perte de performance.
Notez que si la désactivation de l’hyperthreading rend plus difficile la plupart de ces attaques, cela ne suffit généralement pas. De même, la distribution aléatoire de l’espace d’adressage noyau (KASLR) n’empêche pas l’exploitation de ces failles.
Aller plus loin
- Blog Intel (52 clics)
- Annonce FreeBSD TSX (52 clics)
- Annonce FreeBSD MCEPSC (48 clics)
- Linux, vulnérabilités matérielles (74 clics)
# Accès
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
En pratique il me semble que pour exploiter ces failles (au moins une bonne partie d'entre elles) il faille tout de même avoir gagné le droit d'exécuter du code sur la machine ? Me tromperais-je ? Ça limite tout de même les nécessités de mise à jour, non ? Y a-t-il des exploitations connues passant par les navigateurs ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Accès
Posté par jtremesay (site web personnel) . Évalué à 10.
Les failles Spectres et meltdown étaient exploitable par du JS dans le navigateur (src), donc je suppose que pour celles là aussi ça doit être possible.
Ou alors par un chaînage de vulnérabilité, tel que par exemple dans la libpng où une image spécialement formée peut permettre à l'attaquant d'exécuter du code (cf)
[^] # Re: Accès
Posté par David Marec . Évalué à 7.
J'ai au moins en tête l'attaque RIDL écrite en javascript, sur leur site, parmi d'autres.
Tout à fait et les failles ici sont des variantes de Spectre. C'est juste «l'angle d'attaque» qui change.
[^] # Re: Accès
Posté par nlgranger . Évalué à 5.
Je présume qu'il y a un risque pour les hébergements de serveurs mutualisés à base de conteneurs type docker/kubernetes/lxc vu qu'il y a des changements des contexte entre différents clients sur un même coeur CPU. Et ça inclurait aussi les fournisseurs de services PaaS. Quelqu'un peut confirmer?
[^] # Re: Accès
Posté par claudex . Évalué à 7.
Et ceux qui hébergent des VM.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Accès
Posté par Anonyme . Évalué à 3.
Non. Tout dépend de ton modèle de menace.
# Question de modèle
Posté par Arthur Accroc . Évalué à 9.
Il suffit d’avoir un processeur honnête :
Non, je n’ai pas triché et si, c’est un Intel…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Question de modèle
Posté par Micromy (site web personnel) . Évalué à 5.
C'est quoi ? Un Pentium III @800Mhz ??? :p
[^] # Re: Question de modèle
Posté par David Marec . Évalué à 2. Dernière modification le 27 novembre 2019 à 21:41.
Un truc reposant sur l' architecture EPIC ?
[^] # Re: Question de modèle
Posté par claudex . Évalué à 1.
Ce n'est pas trop Intel.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Question de modèle
Posté par David Marec . Évalué à 4.
EPIC != Epyc
La gamme Epyc s'appuie sur une architecture appelée ZEN.
[^] # Re: Question de modèle
Posté par claudex . Évalué à 3.
Désolé, j'ai vu tellement de fois Epy mal écrit que je n'ai pas réfléchi plus loin.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Question de modèle
Posté par David Marec . Évalué à 3.
Bah, c'était l'occasion de rappeler que la gamme des Itanium n'est touchée par aucune faille de type Spectre ou Meltdown.
Ce n'est pas le même prix qu'un Atom, par contre.
[^] # Re: Question de modèle
Posté par claudex . Évalué à 3.
Ni le même tdp.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Question de modèle
Posté par Kerro . Évalué à 4.
Et surtout le plus puissant des Itanium (4500 €) est 30 fois plus cher d'un Intel Core i3-8100 (140 €), et pourtant ne lui arrive pas à la cheville côté puissance de calcul.
[^] # Re: Question de modèle
Posté par totof2000 . Évalué à 2. Dernière modification le 25 décembre 2019 à 13:18.
Avant tout, je tiens à préciser que je ne suis pas un spécialiste des micro-architectures, et que je peux me tromper, et que ce que je dis ici est plus un ressenti qu'une réelle analyse factuelle, et que toute personne ayant les capacités à affirmer ou infirmer ma théorie est bienvenue pour me répondre et éclairer ma lanterne (autrement dit, ne pas prendre ce que je dis comme une vérité absolue, mais uniquement comme le point de vue d'une personne qui l'expose à d'autres qui potentiellement en connaissent mieux qu'elle et pouirraient l'aider à mieux comprendre).
Moi, ce que j'en comprends c'est que l'architecture X86 est vieillissante et à bout de souffle, et qu'il serait peut-être temps de la remplacer par autre chose. En effet, x86 (et x86-64) est une techno née il y a des dizaines d'années, et, avec le temps, on lui a greffé un tas de trucs par dessus, avec parfois pour objectif d'être sur le marché avant les concurrents, donc probablement avec des trucs pas forcément bien nets ou pas bien finis à l'intérieur, qui ne posaient peut-être pas de problèmes à l'époque ou ils sont sortis, mais qui posent problème aujourd'hui, vu l'évolution des utilisations (virtualisation et containarisation par exemple), avec toujours cette contrainte de compatibilité ascendante qui fait qu'elle traîne probablement d'autres boulets.
Je ne suis pas spécialiste des micro-architectures, mais, si on met la perf de côté pour le moment, je me demande si l'Itanium, avec une architecture plus récente, ne serait pas mieux protégé contre ce type de failles (celà dit, il y a probablement des failles de même type dans les processeurs Itanium, ou autre type de processeur, mais vu que ces processeurs sont moins couramment utilisés, il n'y a peut-être pas autant de recherches sur ce type de CPU). Maintenant, l'Itanium n'est pas non plus tout jeune du point de vue architecture, et peut-être faudrait-il repartir d'une feuille blanche ? ( je sais que vu l'échec du processeur Itanium, il n'y a pas grand monde qui pourrait investir sur un nouveau processeur) .
Vous en pensez quoi vous ?
[^] # Re: Question de modèle
Posté par totof2000 . Évalué à 3.
Bon, j'aurais peut-être du lire tous les comentaires avant de poster … j'ai une partie de mes réponses ici : https://linuxfr.org/nodes/118724/comments/1791960 . Mais si vous avez d'autres idées qui n'ont pas encore été abordées, n'hésitez pas.
[^] # Spéculer, c’est mal !
Posté par Arthur Accroc . Évalué à 9. Dernière modification le 28 novembre 2019 à 00:39.
À ma connaissance le dernier processeur Intel de gamme x86_64 qui ne fasse pas de spéculation : l’Atom D2550.
Pas le plus puissant de la gamme, c’était le D2700, que le D2550 a bizarrement remplacé (peut-être pour éviter de marcher sur les plates-bandes de la gamme du dessus, celle du Celeron).
La puissance de calcul est plutôt faible (un peu moins pour le D2700), mais d’après des calculs à la louche que j’avais fait, le rapport puissance de calcul / puissance électrique consommée était similaire à celle des autres Intel de l’époque, celui-ci étant basé sur un cœur nettement plus simple et plus petit.
Le chip graphique intégré n’est pas supporté sous Linux, mais heureusement pour moi, j’ai avec un chip graphique AMD (prévu pour être associé à cette gamme de processeur).
On pourrait imaginer une mise à jour de cette gamme de processeurs avec la technologie actuelle (notamment finesse de gravure) et un nombre important de cœurs pour atteindre une puissance similaire aux processeurs actuels, mais sans failles de conception !
Par contre, la puissance par fil d’exécution serait nettement moindre et il faudrait paralléliser les traitements, à défaut de contourner les failles.
D’un sens, de tels processeurs seraient sûrement en dessous des Arm en puissance par fil de calcul (alors qu’actuellement Intel a l’avantage sur ce point), mais seulement en dessous des Arm qui font de la spéculation et sont donc vulnérables à des failles de type Spectre.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Spéculer, c’est mal !
Posté par djibb (site web personnel) . Évalué à 7.
aie…
[jjkhkb@fixe ~]$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling
[^] # Re: Spéculer, c’est mal !
Posté par Arthur Accroc . Évalué à 2.
« Félicitations », tu as un Intel.
Le plus ennuyeux, ce n’est peut-être pas tant les vulnérabilités listées (et « mitigées »), que celles que ton noyau (pas tout à fait à jour, non ?) ne prend manifestement pas en charge, itlb_multihit et tsx_async_abort…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# preums
Posté par David Marec . Évalué à 4.
Oui, ceux sont des modestes chez Intel.
ou alors il faut qu'ils installent leurs centres dans l'Ain.
[^] # Re: preums
Posté par claudex . Évalué à 9.
C'est le nom de leur division dédiée à l'opensource.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Et les autres ...
Posté par kif . Évalué à 5.
Je me demande si les autres (AMD, ARM, IBM, …) ont mes même problèmes où si c'est Intel qui est particulièrement mauvais (acheté, verolé ?)
[^] # Re: Et les autres ...
Posté par claudex . Évalué à 8.
Une partie des failles de la famille Spectre ont aussi touchés les autres. Cependant Intel a été beaucoup plus touché. Je ne sais pas si c'est parce qu'ils ont fait plus de connerie ou parce qu'ils sont beaucoup plus scrutés que les autres (vu la part de marché).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et les autres ...
Posté par Colin Pitrat (site web personnel) . Évalué à 4.
Ou parce qu'ils ont beaucoup plus d'optims de ce genre que les autres, ce qui explique que leur processeurs soient plus rapides.
[^] # Re: Et les autres ...
Posté par claudex . Évalué à 8.
Je classe ça dans les conneries (faire des optimisations non désactivables qui ont des implications de sécurité).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et les autres ...
Posté par lolop (site web personnel) . Évalué à 2.
Ça dépend du contexte.
Si tu as besoin de perfs en calcul pour un cluster où tu contrôles ce qui s'exécute, ça peut être intéressant.
Si tu es hébergeur pour des clients qui font tourner ce qu'ils veulent, en direct ou en virtualisé, c'est pas bon.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Et les autres ...
Posté par claudex . Évalué à 10.
C'est pour ça que j'ai écrit "non désactivable". Il y a plein de cas où il préférable de privilégier les performances sur la sécurité. Par contre, par défaut, la sécurité devrait primer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et les autres ...
Posté par Anonyme . Évalué à 8.
ce n'est pas une excuse :), je pense plutot que la partie securité est passé à la trappe pour toujours être les premier dans la course à la performance. et celle de leur action en bourse.
codé avec le cul comme on dit en france, mais ca va plus vite forcement. Toute ressemblance avec une ssi de base est fortuite.
la fameuse dette technique, ils doivent se regaler en reunion maintenant qu'ils doivent tenir compte de la securité.
[^] # Re: Et les autres ...
Posté par tao popus . Évalué à 2. Dernière modification le 29 novembre 2019 à 10:23.
``C'est clair que ça doit arrondir les benchmarks pour montrer de meilleurs perfs ou perfs équivalentes que les concurrents.
Ça me fait penser aux code du fameux constructeur automobile allemand qui change l'algo de ses voitures pour réduire sa pollution uniquement sur les banc d'essais ou aux machines à voter électronique tout ça. Dans tous ces cas les résultats trompent et ont des conséquence sur la vente du produit.
Au passage l'architecture RISC-V n'a été touché par aucune de ces failles.
[^] # Re: Et les autres ...
Posté par claudex . Évalué à 7.
Ou aux smartphone qui laisse chauffe plus le cpu quand une appli de benchmark tourne.
Ce n'est pas lié à l'architecture, la preuve, il y a des atom qui ne sont pas affectés. Il y a aussi des ARM qui ne sont pas affecté. Aucun cpu RISC-V n'a été affecté parce que personne n'a fait un cpu assez puissant, sinon, ils auraient utilisé les même techniques que les autres (Power, ARM, z/processor, x86).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et les autres ...
Posté par Anonyme . Évalué à 10.
Les autres sont affectés par Spectre (à part certains petits cœeurs ARM n'ayant pas de prédiction de branches) mais pas sur autant d'angles d'attaque et ils n'ont pas toutes les autres familles de vulnérabilités comme Meltdown ou LazyFPU.
Côté GPU, Nvidia a récemment été affecté par une faille majeure dans son pilote mais rien d'aussi inquiétant que chez Intel.
Côté module de management/sécurité, le Trustzone de ARM a aussi essuyé beaucoup de vulnérabilités, en particulier via l'implémentation faite par Qualcomm. Le PSP de AMD n'est pas non plus à l'abri.
Intel a pris beaucoup de raccourcis en terme de sécurité pour apporter des fonctionnalités et augmenter les performances mais ils n'ont pas comblé les lacunes par la suite, même pas l'implémentation de killswitch. Ils ont eu une dizaine d'année sans concurrents sérieux et ont pêché par négligence, maintenant ils payent leurs erreurs de gestion à un moment où ils sont eux-même pénalisés par leur retard en matière de lithographie et d'architecture processeur et où ARM et AMD sont devenu assez costauds pour grignoter davantage que des miettes au niveau du marché CPU.
[^] # Re: Et les autres ...
Posté par ʭ ☯ . Évalué à 4.
Pour ma part, je mesure le niveau du problème à la chute de performances obtenue avec les correctifs. Et là, il n'y a pas photo, Intel est loin devant ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Et les autres ...
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Il y a des fois, où on se demande si c'est de l'incompétence. Ou s'ils ont plus que moins discrètement fourni à la NSA des portes d'entrée béantes pour de nombreuses années en toute connaissance de cause…
[^] # Re: Et les autres ...
Posté par tao popus . Évalué à -2.
RISC-V n'est pas affecté à ma connaissance.
[^] # Re: Et les autres ...
Posté par Anonyme . Évalué à 3. Dernière modification le 29 novembre 2019 à 15:04.
Il y a tout de même eu un POC de Spectre sur BOOM.
Mais par chance pour les fabricants et les clients, les puces déjà créés ne reposaient pas sur cette architecture mais sur des designs plus simples comme Rocket ou Pulp.
Bref, si RISC-V avait été développé et commercialisé plus tôt, il y aurait eu des problèmes similaires aux gros processeurs MIPS ou ARM existants.
Edit : Ça rejoint ce que Xavier Claude disait plus haut, j'avais pas lu.
[^] # Re: Et les autres ...
Posté par djip007 . Évalué à 3.
avec un AMD ryzen (1)…. un peu mieux que intel… (et les Ryzen 2 on moins de failles… et sont bien plus rapide…)
[^] # Question hors sujet
Posté par Arthur Accroc . Évalué à 3.
Sais-tu s’il y a chez AMD des processeurs prévus pour être montés sans ventilateur, même dans un portable, équivalents des Intel Pentium N… (exemple) ou Core …Y (successeurs des Core M…, exemple), et des portables construits avec ?
Après un Toshiba, j’ai décidé de ne plus acheter que des PC fanless, mais si le processeur pouvait ne pas être une collection de failles, ça ne serait pas plus mal…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Question hors sujet
Posté par ʭ ☯ . Évalué à 4.
Je pense que n'importe quel Ryzen peut être monté sans ventilateur : tu le brides avec cpufreq et problème réglé. Et au moins, c'est toi qui choisis, pas le micrologiciel comme chez intel.
Pas de risque thermique, ils ralentissent tout seuls en cas de surchauffe.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Question hors sujet
Posté par Kerro . Évalué à 5.
Ce n'est pas le cas des Intel ?
Je suis quasi persuadé que c'est le cas. Mais peut-être que dans une certaine mesure.
[^] # Re: Question hors sujet
Posté par ʭ ☯ . Évalué à 3.
J'ai pas dit le contraire : j'indiquais seulement que les AMD avaient une protection thermique, depuis 2003 et les AMD64 en fait. Avant, on pouvait griller les Athlon ;-)
Côté Intel, la protection thermique est arrivée avec les Pentium 4 : il surchauffaient bien trop pour ne pas avoir une catastrophe industrielle sans ça. J'ai vu des portables qui n'arrivaient pas à tenir la fréquence maximale plus de 3 secondes!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Question hors sujet
Posté par Anonyme . Évalué à 4.
Le ralentissement automatique, le thermal throttling, ne fait pas tout.
Si le CPU n'a pas la possibilité de dissiper la chaleur malgré le niveau de puissance minimale (automatiquement ou forcé via le gouverneur powersave), il se coupe par sécurité. C'est ce dernier mécanisme, le thermal shutdown, qui manquait cruellement aux Athlon K7 et plus anciens.
Sans un design étudié pour un usage passif, un ordi portable a très peu de marge de dissipation avec une ventilation désactivée et il y a de fortes chances que même à son minimum de puissance, l'appareil se coupe au bout de quelques dizaines de minutes une fois que l'inertie thermique du radiateur arrive à la température critique. C'est un peu pour cette raison que le POST vérifie le bon fonctionnement du ventilateur et que souvent sur les portables cela peut carrément bloquer la suite du démarrage.
[^] # Re: Question hors sujet
Posté par Anonyme . Évalué à 5.
Si tu veux un portable AMD, il vaut mieux attendre quelques mois que leur gamme Zen2 sorte. On aura plus d'infos durant le CES en Janvier.
La gravure 7nm fait déjà des merveilles en terme de conso et d'échauffement sur leur gamme de bureau.
Et même si tu te fiches d'avoir la dernière génération, ça voudra aussi dire que les modèles actuels vont baisser de prix (bien plus qu'au Black Friday ou Cyber Monday).
# Merci
Posté par lascapi . Évalué à 4. Dernière modification le 28 novembre 2019 à 10:03.
Super dépêche, fort intéressante ! Le schéma du processeur est génial ! On voit la complexité de l'affaire.
Merci :)
# HP
Posté par ElectronLibre63 . Évalué à 5.
Chez HP aussi, on trouve des trucs sympa. :
https://www.cert.ssi.gouv.fr/avis/CERTFR-2019-AVI-594/
# Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, de confiance
Posté par benoar . Évalué à 2.
Petit rappel : ces failles sont exploitables par un code d'un adversaire qui tournerait sur votre machine. Bref, c'est valable uniquement si vous aimez faire tourner du code provenant d'inconnus malveillants. Si vous n'utilisez que du logiciel libre, issu du personnes de confiance (comme par exemple de personnes cooptées ayant approuvé une constitution garantissant la liberté des utilisateurs), aucun problème pour vous !
Bien sûr, vu qu'une bonne partie du web moderne marche uniquement sous les prémices d'accepter de faire tourner n'importe quoi n'importe quand, ça vous limite un peu dans les sites accessibles : mais c'était déjà le cas pour les logiciels si vous respectez vos convictions. Noscript est votre ami, et les réseaux sociaux sont mauvais pour la santé de toutes façons.
Je trouvais ça important de rappeler ce fait sur notre bon vieux linuxfr.
[^] # Re: Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, ...
Posté par djip007 . Évalué à 0.
Des logiciel comme matrix opensource libre… etc nécessite javascript pour marcher et en particulier pour gerer le chiffrement de bout en bout!!!
Donc a moins de ne pas utiliser internet (et en pas y etre connecté…) Ces failles sont assez critique…
Bon elles le sont encore plus pour des codes que l'on fait tourner sur des VM qq soit le provider vue que ca permet des compromission entre VM (et on ne sais pas quel autre VM avec quel autre code tourne en meme temps… c'est bien sur la que ces failles sont les plus critiques!
[^] # Re: Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, ...
Posté par benoar . Évalué à 4.
Très bien, tu peux l'utiliser sans problème. Où est-ce que j'ai dit qu'il fallait bannir tout le Javascript ?
C'est ce genre d'exagération qui fait mal comprendre le problème et qui handicape le libre : j'utilise Internet de plein de manières différentes, merci, mais pas par du Javascript privateur, ou alors une whitelist très limitée (oui, je ne suis pas parfait, je fais quelques petites exceptions).
Alors déjà, tu fais tourner ton code sur la machine de quelqu'un d'autre : qu'est-ce qui te dit qu'il ne fait pas déjà quelque-chose de malicieux avec tes données ?!
Le modèle de menance sous-entendu quand on parle de « faille de sécurité » par ces mécanismes est très très difficile à contrer : dire qu'on peut faire tourner du code inconnu sur sa machine (ou un code connu sur une machine dans un état inconnu) et espérer que c'est « sécurisé », c'est se faire des illusions à l'heure actuelle, et sera toujours très difficilement sécurisable. Je comprends que certains ont choisi ce compromis en échange d'avantages autres (pouvoir facilement déployer du code partout pour le JS, avoir des machines modulables pas cher pour le cloud), mais croire que ce compromis est « sécurisé » aussi bien que certain l'affirme c'est se mettre des œillères.
C'est triste de se faire moinsser quand on ose dire ça sur un site de libriste.
[^] # Re: Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, ...
Posté par tao popus . Évalué à 0.
Effectivement, lorsque les tiers ne sont pas de confiance, on a des choses du genre minage de cryptomonnaie ou cliquage dicret de pub distantes ;)
Cela dit, il y a bien les modules JavaScript pour npm qui servent presque à rien, mais était soit disant optimal et utilisé par des tas de frameworks (notamment en raison cascade de dépendances) avait cette fâcheuse tendance à aller faire des actions sur twitter, histoire de bien plomber les perfs du programme. Il y en avait qui cliquait sur une publicité distante pour un sandwich mais je ne retrouve pas le lien
https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558
[^] # Re: Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, ...
Posté par tao popus . Évalué à 1.
Voir aussi la partie 5 de ce billet à propos de ça… Des modules NPM qui vont loguer les clés SSH, d'autres qui recodent des fonctions de base déjà présentent dans le langage lui-même, le fameux NPM worm, etc…
https://blog.nodeswat.com/what-i-learned-from-analysing-1-65m-versions-of-node-js-modules-in-npm-a0299a614318?gi=f6c500cc5291
[^] # Re: Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, ...
Posté par vv222 . Évalué à 3.
Gaffe, une lecture attentive et un poil de recherche sur les problèmes remontés laissent penser que cet article est une parodie.
[^] # Re: Et toujours aucune vulnérabilité pour ceux qui utilisent uniquement du logiciel libre, ...
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 2.
Un lien qui comporte "silicon-satire" doit-il être pris au sérieux de toute façon ? :-)
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Possibilité de contourner l'absence de correctif du revendeur ?
Posté par PS12r . Évalué à 3. Dernière modification le 28 novembre 2019 à 19:06.
Une question à ce sujet car je n'y connais rien :
Si le fabriquant/vendeur de mon ordinateur/carte mère ne propose pas de mise à jour pour le BIOS/UEFI, est-il possible de contourner le problème et de mettre à jour les micrologiciels avec des paquets comme microcode_ctl ou fwupd ?
[^] # Re: Possibilité de contourner l'absence de correctif du revendeur ?
Posté par Anonyme . Évalué à 3. Dernière modification le 29 novembre 2019 à 00:41.
Si le correctif n'a pas été fourni publiquement il y a peu de chances.
Puis hélas, tout ne se résout pas à coup de microcodes : les correctifs réguliers d'AGESA et d'IME nécessitent que le fabricant du matériel fournisse un outil de MÀJ ou un nouveau "BIOS".
Après contrairement à l'AGESA, pour l'IME tout n'est pas perdu mais en terme de complexité ce n'est pas très loin d'un radical me_cleaner.
Enfin, il me semble que fwupd est justement un accord des constructeurs pour fournir du support donc pas possible de l'utiliser pour flasher un nouveau BIOS/firmware qu'ils ne fournissent pas.
[^] # Re: Possibilité de contourner l'absence de correctif du revendeur ?
Posté par ʭ ☯ . Évalué à 2.
Oui, c'est bien le but de microcode : il remplace le micrologiciel CPU au boot.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Ah, Intel...
Posté par FantastIX . Évalué à 0.
… à voir le travail de pro, z'ont pas besoin de fuites quantiques pour rendre leurs processeurs plus poreux que des passoires!
(C'est pas nous, les électrons ont sauté une couche et du coup ils se sont retrouvés dans le mauvais canal en dévoilant les clés privées des applications depuis le cache L12. C'est la faute à Schrödinger!)
# Nouvelle faille: Plundervolt
Posté par FantastIX . Évalué à 4. Dernière modification le 24 décembre 2019 à 11:10.
Il semble qu'une nouvelle faille de sécurité, touchant le système de contrôle de la tension d'alimentation au sein du CPU, ait été découverte et exploitée, selon la chaîne ThreatWire (en). Elle est baptisée Plundervolt. Un exploit de cette faille provoque au pire un crash de tout le système avec, comme finalité, un déni de service.
Contre-mesure: installer les derniers correctifs du micro-code Intel.
[^] # Re: Nouvelle faille: Plundervolt
Posté par David Marec . Évalué à 5.
Je suppose qu'il s'agit de cette SA.
- C'est en lien avec les trous dans SGX. -
Par contre, ça me semble très compliqué à exploiter, voire quasiment impossible depuis l'extérieur, sans s'appuyer sur une autre faille.
Même pas, il faut une mise à jour BIOS/UEFI pour ça.
[^] # Re: Nouvelle faille: Plundervolt
Posté par Arthur Accroc . Évalué à 5.
Et ça, ce n’est que si ton constructeur en propose, y compris pour les machines de l’âge de la tienne. Ce n’est pas gagné pour toutes les machines…
Il y a quelques temps, on aurait pensé être plus à l’abri de l’absence de mise à jour avec les ordinateurs qu’avec les smartphones…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.