Coucou tout le monde
Alors, je n’aime pas trop ça, je t’écris en me basant sur des pures spéculations à travers le Web. Mais le faisceau d’indices est trop grave pour passer à côté.
Commençons par les faits, rien que les faits. Ces derniers mois, on a vu apparaître pour le noyau Linux une nouvelle solution de sécurité proactive (qui ne corrige pas une faille mais diminue considérablement l’impact d’éventuelles failles présentes ou à venir), nommée KAISER, renommée depuis KPTI, Kernel Page Table Isolation. Comprendre l’intérêt de cette sécurité nécessite un peu de compréhension de l’agencement de la mémoire virtuelle de nos machines x86 64 bits.
Les 64 bits sont grosso modo découpés en deux parties. En « bas » se trouve l’espace utilisateur, propre à chaque processus. Le processus 1 voit ainsi à l’adresse 0x4273B0B0 ses données alors que le processus 2 y verra les siennes, sans possibilité d’accéder aux données du processus 1. En « haut » en revanche se trouve, d’accès bloqué par l’unité matérielle de gestion de la mémoire (MMU), l’espace noyau. Pourquoi avoir fait ça, me direz‐vous ? Si la MMU (zéro tracus) a un bogue, paf, les applis accèdent à la mémoire du noyau et l’apocalypse se déclenche… La MMU fait heureusement bien son travail, et cela permet d’augmenter considérablement les performances pour les appels système. En effet, basculer sur un espace mémoire séparé nécessite de vider le TLB, un bon gros cache qui tache… Et ça coûte terriblement cher ! (des appels système comme gettimeofday() sont encore plus optimisés et utilisent le vDSO pour ne même plus faire de bascule entre espace utilisateur et noyau, mais c’est une autre histoire). Donc, lors d’un appel système, le noyau « dit » à la MMU « C’est bon, j’ai accès à ma RAM » et tout le monde est content.
KPTI change tout ça. Les processus n’ont plus en haut de leur espace mémoire virtuel le noyau. À la place, le noyau bascule sur un espace mémoire différent lors des appels système. C’est très coûteux. Avec les derniers processeurs, on est sur un pourcentage pouvant monter à trois chiffres sur le temps d’exécution d’un appel système. Bien sûr, c’est un micro benchmark, un vrai cas d’usage imposerait ~5 % de perte seulement…
Jusque‐là, tout va bien, tout le monde est heureux.
Mais le patch KPTI a eu une fin de décembre tumultueuse qui soulève un potentiel gravissime problème de sécurité sur les processeurs Intel.
En effet, KAISER a été révélé en octobre. Il semblait alors être un patch pour protéger le noyau d’attaques visant à casser le KASLR. Avec KASLR, le noyau a un emplacement aléatoire dans son espace mémoire, et un attaquant voudra trouver l’emplacement exact pour accomplir ses méfaits. Donc, ça ne semblait pas critique, même si le patch semblait être poussé relativement rapidement. Puis, il fut développé, a suivi le cycle de revues, été renommé en KPTI…
Et tout récemment, le 30 décembre, Linus Torvalds a intégré KPTI directement dans la version 4.15-rc6 avec un message invitant à son intégration dans tous les noyaux encore maintenus. Et, là, c’est très très louche. Jamais Linus n’aurait intégré dans une rc6 un patch ne servant qu’à pallier des fuites de KASLR. Jamais il n’aurait appelé à un rétroportage.
Le patch est très volumineux, a un impact non négligeable sur les performances, et est activé par défaut. Un développeur AMD a juste altéré le patch en précisant que les processeurs AMD ne sont pas impactés car leur fonctionnement rend le patch inutile. Même Microsoft aurait fait des correctifs similaires à KPTI pour le noyau de Windows.
Spéculons : a-t-on dans tous les processeurs Intel modernes (≥Core 2 ?) une faille permettant aux processus en espace utilisateur de contourner la MMU, et donc lire voire écrire la mémoire noyau ?
Dans tous les cas, ça commence à chauffer, le patch devrait arriver dans les distributions rapidement, peut‐être jeudi (un bogue Xen est sous embargo jusqu’à jeudi, c’est peut‐être le même).
Quelques sources :
# Benchmark plus complet
Posté par Pinaraf . Évalué à 10.
Phoronix a fait un premier benchmark (je suis pas fan, ils auraient pu faire plus propre mais ça donne une idée) : https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1
Les résultats font vraiment peur surtout pour le DBA que je suis…
# Desactivable?
Posté par Sylvain Colinet (site web personnel) . Évalué à 0.
C'est la vraie question, les tests font peur sur les IOs. pour une vunérabilité qui est pas encore exploité, le coût est trop gros.
[^] # Re: Desactivable?
Posté par Pinaraf . Évalué à 7.
C'est désactivable, mais est-ce «désactivable» ? :)
On peut par un paramètre au boot le désactiver. Mais si la faille permet la lecture de tout l'espace noyau, ou pire la moindre écriture, c'est inenvisageable de la désactiver à part sur un système parfaitement clos…
[^] # Re: Desactivable?
Posté par Jean-Max Reymond (site web personnel) . Évalué à 6. Dernière modification le 03 janvier 2018 à 10:03.
Quand on voit le patch du gars d'AMD, j'ai comme des doutes qu'on puisse le désactiver
[^] # Re: Desactivable?
Posté par claudex . Évalué à 8.
Je me suis permis de modifier la mise en forme du commentaire.
« 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: Desactivable?
Posté par Pinaraf . Évalué à 9.
Si si, on peut le désactiver par un paramètre au boot, pti=off / pti=on.
Là c'est pour «marquer» le CPU comme ayant un bug et donc imposant d'activer par défaut le PTI. La valeur initiale quoi…
[^] # Re: Desactivable?
Posté par Le Gab . Évalué à 1.
Du coup tu désactives toutes les autres contre-mesures, pas certains que soit judicieux.
Bref, je n'arrive pas à croire qu'en 2018 j'allais à nouveau compiler un noyau linux. :)
[^] # Re: Desactivable?
Posté par Pinaraf . Évalué à 4.
Toutes les autres contre-mesures ? De quelles contre-mesures parles-tu ? Ça ne désactive que le KPTI…
[^] # Re: Desactivable?
Posté par Le Gab . Évalué à 2.
Ben t'as dit
je croyais que c'était un flag général.
[^] # Re: Desactivable?
Posté par Boa Treize (site web personnel) . Évalué à 4.
Quand on regarde le monde par le mauvais bout de la lorgnette, on ne voit pas grand chose.
Quand on fait une recherche sur Internet, on apprend vite qu'il y a un paramètre de démarrage du noyau pour désactiver ce nouveau comportement, c'est
nopti.[^] # Re: Desactivable?
Posté par Chris K. . Évalué à 7.
Cf le commentaire de Pinaraf qui résume bien la situation…
Vu le X86_BUG_CPU_INSECURE et l'intégration inhabituelle j'ai peur que les inquiétudes soulevées soient fondées.
# Stock options Intel
Posté par jjl (site web personnel) . Évalué à 10.
C'est marrant, le CEO d'Intel vient de vendre plein de stock options …
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
[^] # Re: Stock options Intel
Posté par Jean-Max Reymond (site web personnel) . Évalué à 5.
Et pourtant, ils va s'en vendre des palettes de futurs chips Intel avec le bug hardware corrigé. J'ai une bécane qui a 7 ans et si d'un coup, je perds 30% de perf, je vais peut-être la changer
[^] # Re: Stock options Intel
Posté par NiKaro (site web personnel) . Évalué à 10.
Ouai mais cette fois-ci tu prendras peut-être du AMD ou ARM.
[^] # Re: Stock options Intel
Posté par Pinaraf . Évalué à 10.
Ou du POWER9 ? https://www.raptorcs.com/TALOSII/prerelease.php
[^] # Re: Stock options Intel
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Tu as déjà vu des machines POWER a des prix LOWER ?
[^] # Re: Stock options Intel
Posté par Pinaraf . Évalué à 5.
J'aime bien ta formulation. Et c'est pour ça que j'ai juré le jour où Apple a abandonné ses PowerPC pour passer à du x86, la demande étant très faible les prix sont élevés…
[^] # Re: Stock options Intel
Posté par steph1978 . Évalué à 7.
L'initiative OpenPOWER devrait permettre de fondre des POWER8 à coût moindre.
[^] # Re: Stock options Intel
Posté par David Marec (site web personnel) . Évalué à 10.
D'où cette réflexion, sortie du forum FreeBSD
[^] # Re: Stock options Intel
Posté par Colin Pitrat (site web personnel) . Évalué à 2.
Si elle a 7 ans, tu as des chances de ne pas être impacté !
[^] # Re: Stock options Intel
Posté par fcartegnie . Évalué à 6.
Et nous on doit faire quoi à part subir si c'est bien le cas d'un fiasco majeur annoncé ?
- Vendre à découvert Intel à la sortie de l'embargo,
- prendre maintenant des Turbo/Warrant Put Intel et Call AMD,
- lancer une class action qui existe pas vraiment en France,
- et/ou invoquer le Vice caché pour un retour de tous les matos ?
[^] # Re: Stock options Intel
Posté par Yohann (site web personnel) . Évalué à -4.
Jérôme ? C'est toi ?
[^] # Re: Stock options Intel
Posté par ribwund . Évalué à 3.
Sauf que la décision de les vendre c'était quand? En général y'a un délai entre la mise en place d'un plan 10b5-1 et la vente des actions.
[^] # Re: Stock options Intel
Posté par Anonyme . Évalué à 4.
D'après NextInpact, la communication sur ce bug a commencé le 29 novembre:
"les partenaires sont prévenus, de manière plus ou moins rapide selon leur importance [..] Selon nos informations, le programme a débuté le 29 novembre dernier".
Et pour les stocks options, ce serait un peu pareil : "mi-décembre, The Motley Fool a évoqué le fait que le PDG Brian Krzanich avait vendu toutes les stocks options qu'il pouvait selon une déclaration d'Intel le… 29 novembre dernier, son rôle lui imposant d'en garder 250 000 au minimum."
[^] # Re: Stock options Intel
Posté par ribwund . Évalué à 8.
D'abord la communication à Intel c'était en juin d'après le post de google. Sinon j'ai l'impression que y'a une certaine incompréhension sur comment marche les stocks options.
Pour éviter les délits d'initié, un dirigeant trade généralement sur un plan prévu à l'avance. Genre: "tous les trimestres vend toutes les actions au prix de marché" (mais l'algo peut être bien plus compliqué).
(C'est ça un plan 10b5-1)
Du coup en permanence les dirigeants vendent leurs actions, et si une boîte annonce quelque chose tu pourra toujours trouver qqn qui a vendu avant. Ça veut pas dire que y'a un délit d'initié vu que c'est basé sur un algo défini des mois ou années avant.
[^] # Re: Stock options Intel
Posté par xeuzuex . Évalué à 2.
J'espère qu'il y aura enquête et prison si nécessaire. (je vois mal comment il va se défendre).
[^] # Re: Stock options Intel
Posté par David Marec (site web personnel) . Évalué à 8.
Personnellement, j'ai vite investi dans le pop-corn.
[^] # Re: Stock options Intel
Posté par Pinaraf . Évalué à 10.
Tu voulais dire popcoin ?
# Bug chez Intel
Posté par Damien Thébault . Évalué à 10.
Tout le monde a l'air d'accord sur le fait qu'un but existe chez Intel, le seul mystère reste quoi précisément.
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
# NSA
Posté par David Demelier (site web personnel) . Évalué à -6.
J'espère que Intel va couler, au plus vite. Vive RISC-V.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: NSA
Posté par Anonyme . Évalué à 10.
RISC 5 en est au début de la fabrication. Les seuls proco sortis sont des microcontroleurs in-order basées sur rocket. Il va falloir un moment avant qu'arrivent des CPU grand public basées sur BOOM donc il reste la grosse part du marché PC qui n'est pas satisfaite par OpenPower. Puis risc-v n'est qu'une ISA, plein de monde bosse dessus pour faire ses propre designs et il y a beaucoup de chances que les fabricants pondront un truc plein de blob. Après tout, c'est sous licence permissive.
Si Intel coule (chose impossible en l'état) ou perd de son quasi-monopole, c'est AMD, Apple et Qualcomm qui vont prendre la place Pareil, si x86 perd du terrain ce sera au profit de ARM et ça ne sera pas vraiment une victoire vu les pratiques actuelles tout aussi douteuses des gros concurrents.
[^] # Re: NSA
Posté par patrick_g (site web personnel) . Évalué à 6.
Pour Risc-V il y a eu un mail de Christoph Hellwig sur la liste de diffusion afin que les devs de cette architecture tiennent compte de ce besoin d'isolation : https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa-dev/JU0M_vug4R0/YELX92fIBwAJ
# Concrètement ?
Posté par Stinouff . Évalué à 3.
Bonjour,
Je suis sous Debian 9 avec un Intel G3220 : https://www.ldlc.com/fiche/PB00152673.html
Concrètement, que vais-je devoir faire et qu'est-ce que je perds ? Je suis loin de comprendre tous les tenants et aboutissants de cette nouvelle.
Si je comprends bien, à mon très modeste niveau, un patch de sécurité pour une faille inutilisée va être appliquée sous Windows et Linux, réduisant les performances des ordinateurs ?
[^] # Re: Concrètement ?
Posté par Pinaraf . Évalué à 4.
Il est urgent d'attendre :)
Tu auras bientôt une mise à jour de sécurité concernant le noyau. Tu devras l'appliquer, comme toute mise à jour de sécurité. Et tu perdras de 3 à 5% de performances sur certains usages précis.
[^] # Re: Concrètement ?
Posté par Stinouff . Évalué à 2.
Quels usages ? Je ne trouve pas d'informations.
Le traitement vidéo ? La décompression ? Les jeux ? Le rendu 3D ? Tout ? xD
[^] # Re: Concrètement ?
Posté par Pinaraf . Évalué à 7.
Les usages avec beaucoup d'appels système… C'est vague :)
En gros, beaucoup d'IOs, (très) beaucoup de réseau sur la loopback (et pas en ethernet/wifi où la latence va masquer la perte)…
Le pire c'est les bases de données.
Tout ce que tu cites par contre consomme du processeur mais sans faire trop d'appels système (si c'est bien codé), donc c'est peu impacté.
[^] # Re: Concrètement ?
Posté par Anonyme . Évalué à 2.
Du coup ça n'impactera pas les performances dans ce cas-ci mais le CPU va mouliner davantage donc il y aura tout de même une augmentation de la consommation ce qui peut être gênant autant en terme d'autonomie que de chauffe, donc de performance, de nuisance sonore ou d'usure principalement sur des appareils nomades type laptop, tablettes ou de l'embarqué.
J'imagine aussi que les Quark, Core-M et descendant d'Atom sont touchés, non ?
[^] # Re: Concrètement ?
Posté par Pinaraf . Évalué à 5.
Sont-ils plus récents que des Pentium 1 ? Si oui, il y a une chance pour qu'ils soient impactés :)
[^] # Re: Concrètement ?
Posté par Anonyme . Évalué à 2.
OK merci :)
Déjà que les x86 ne brillaient pas en basse conso face à ARM, si on ajoute ce patch ça creuse encore l'écart.
[^] # Re: Concrètement ?
Posté par GnunuX (site web personnel) . Évalué à 3.
Tout va dépendre de ton utilisation. Il est probable que pour un usage non serveur, la perte ne soit pas réellement perceptible.
[^] # Re: Concrètement ?
Posté par Stinouff . Évalué à 2.
Le problème a effectivement l'air bien plus grave pour tous les professionnels.
[^] # Re: Concrètement ?
Posté par richardd . Évalué à 1. Dernière modification le 03 janvier 2018 à 10:57.
Il est aussi probable que le patch soit écrit rapidement, avec de l'alcool dans le sang / fatigue et qu'il puisse être amélioré (Le fait qu'il ciblait tous les processeurs x86_64, dont les AMD, et pas seulement les fautifs, m'y laisse y penser).
On ne sait pas non plus si la situation peut-être corrigé par le microcode du CPU. (On a eu des mise à jours en urgence du microcode au même moment…).
Bref, wait and see..
[^] # Re: Concrètement ?
Posté par Pinaraf . Évalué à 6.
Le bug semble être localisé dans la partie «hard» du processeur, pas celle sous contrôle du microcode. Sinon il n'y aurait pas tout ce tintouin et on nous demanderait juste de mettre à jour nos microcodes.
Par contre l'amélioration des performances du patch… Ça va être dur, le TLB se fait défoncer obligatoirement, et c'est ce qui coûte cher.
[^] # Re: Concrètement ?
Posté par ckyl . Évalué à 8. Dernière modification le 03 janvier 2018 à 12:24.
Surtout que le problème s'est déjà posé il y a 15 ans lorsque l'on voulait pouvoir donner 32 bits d'adressage à un processus sur un CPU 32. Ça nous remonte en 2003, ça s'appelait le 4G/4G split et ça faisait grosso modo la même chose: virer le noyau de l'espace d'adressage du processus et vider le TLB à chaque syscall. Si ma mémoire est bonne, on n'a jamais trouvé d'astuce pour optimiser le truc et le surcoût de l'époque est similaire aux premiers benchmarks qui sortent (30% pour les charges qui font pleins de syscall, 5% lorsqu'il y a peu de syscall).
[^] # Re: Concrètement ?
Posté par Guillaume Knispel . Évalué à 7.
Y a des nouvelles features (ASID / PCID) dans les proc les plus récents qui permettent de flusher sélectivement ou un truc du style, et donc mitiger les pertes de perfs, mais même avec ces features elles restent notables, et en plus surtout dans les régimes où elles sont déjà grandes à la bases.
Personnellement je viens de mesurer un passage de certains syscalls que j'ai patché ya pas longtemps (semget & co) de 200ns (Linux 4.14.10) à 400ns (Linux 4.14.11) (avec un microbenchmark pas extrêmement représentatif de vrai workloads - sauf peut-être dans des softs au design bizarre - c'est plus par curiosité). Vu la technique utilisée c'est pas juste xN ou +200ns, mais une loi complexe qui démarre avec un surcoût de durée constante au départ, puis un facteur multiplicatif très grand pour les premiers accès mémoires, et qui est progressivement amorti au fur et à mesure que les caches se rechargent. Un microbenchmark à base de getpid() montre un ralentissement d'un facteur 4 sur celui là (mais bon, là vraiment personne ne fait ça, c'est juste pour avoir une idée des cas les plus extrêmes).
Bref certains softs activement maintenus vont se mettre à jouer à un nouveau jeux; éviter les syscalls. Par exemple si l'émission d'une simple trace flush trop de caches userspace, ça va être un peu gênant.
[^] # Re: Concrètement ?
Posté par freem . Évalué à 4.
Un peu comme les allocations mémoire, en fait? Les limiter en traitant un lot plus important de données pour accélérer les perfs? Mais n'est-ce pas déjà le cas, quand les performances sont réellement nécessaires? Je veux dire, un seul appel à, par exemple, read au lieu de 10, c'est probablement plus rapide, non (bon, ok, c'est une fonction de la libc, mais il me semble avoir lu que les syscalls sont déjà considérés comme lents de toute façon)?
[^] # Re: Concrètement ?
Posté par Guillaume Knispel . Évalué à 5.
C'est déjà le cas, mais dorénavant l'impact d'un syscall a, selon le processeurs, des effets indirects élevés qui peuvent être très gênants sur certaines workload, et ça pourrait motiver à réorganiser du code pour éviter des syscalls appelés pas trop fréquemment qui en soit prennent peu de temps mais se mettent maintenant à flusher des caches.
Ainsi alors que certains soft n'auraient eu aucun intérêt à modifier leur code lorsque ce problème n'avait pas été découvert (ils n'en auraient tiré qu'une accélération marginale voire non mesurable), il est fort possible que dorénavant la chasse aux syscalls deviennent bien plus rentable. Ce qui est gênant c'est que du profiling par sampling de %rip pourrait ne pas indiquer parfaitement les endroits où viser, vu qu'une partie du ralentissement est indirect et dilué sur une "longue" période (quand on revient en userspace et que des trucs ont été flushés)
[^] # Re: Concrètement ?
Posté par freem . Évalué à 3.
Je reagis surtout au fait tout le monde semble parler de pertes de performances entre 5 et 30 (ou 50?)%, sans tenir compte de deux faits: d'une part, les syscalls ont toujours ete lents, et les applications qui cherchent vraiment la vitesse y consacrent deja du temps d'optim je pense, et d'autre part, les CPUs, surtout de bureau, passent plus de temps a ne rien faire qu'autre chose (s'ils sont exploites a 20% en mode "eco energie" c'est deja pas mal).
Du coup, soit je suis idiot (pas impossible), soit les chiffres donnes sont mal compris/explicites (genre, tels que donnes, on pense qu'une machine sera 50% plus lente h24, mais si le cpu est, admettons, 50% plus lent, ca voudra dire qu'avec mes chiffres il tournera a 30%, ce qui est encore faux puisque la lenteur sera en fait causee, dans le pire cas par la carte mere) et totalement inutiles, soit un melange des deux (le plus probable ama).
Ceci dit, te remercie pour ta reponse: lue attentivement, elle permettra a certains de dedramatiser, en gros: "certains types de workload seront 5-n% plus lents", et sauf applis specifiques et/ou en environnements sous forte charge, ca n'aura un impact que marginal (la plupart des serveurs de prod tournent'ils vraiment a bloc sus des syscalls? ce serait triste… ). Quoiqu'en disent les bench, xosview m'indique qu'en usage normal, ma machine de dev passe peu de temps en appels systemes apres tout?
Ceci dit, je suis curieux sur un sujet plus general: comment mesurer ou estimer les couts de cache miss/refresh d'une application? Voire, pourquoi pas, d'un systeme complet?
[^] # Re: Concrètement ?
Posté par Guillaume Knispel . Évalué à 4.
Les serveurs de tous genres vont être assez affectés car ils font beaucoup d'IO. Accéder à pleins de fichiers aussi. Tous ce qui fait surtout mouliner le CPU sans faire beaucoup d'IO ne sera pas affecté. Selon les systèmes, certains sous-systèmes ont déjà été optimisés pour diminuer le nombre de syscalls et logiquement l'impact sera négligeable dans ces cas. Enfin on peut s'attendre à des mois voire des années de réoptimisation des différents noyaux pour mitiger l'impact en perf avec toutes les astuces qu'ils trouveront, voire des modifs plus profondes sur l'archi de certaine parties.
Y a des compteurs de perf pour observer les ratios des caches et autres bouts du CPU soit sur un programme soit sur une machine entière: sous Linux, ya entre autre l'outil "perf" pour faire ça.
[^] # Re: Concrètement ?
Posté par windu.2b . Évalué à 6.
Ou, par sécurité, le développeur du patch s'est dit qu'il valait mieux viser TOUS les processeurs 64 bits, en attendant d'en savoir plus. Cf. le commentaire dans le patch :
[^] # Re: Concrètement ?
Posté par richardd . Évalué à 10.
Oui, je ne voulais pas dire qu'ils ont baclé le patch, loin de ça, juste que la période ne s'y prête pas, et vu l'urgence, la priorité est surtout à ne rien casser et à fixer la faille. Les performances c'est très secondaire.
Surtout qu'on ne sait pas trop le contenu de la faille, et le patch est volumineux, il y a eu donc pas mal de réécriture. Et statistiquement, ça veut dire potentiellement pas mal d'optimisation à faire.
Bref, Keep calm and Wait & See
Et réjouissez vous, comme ça, pour les prochains CPU, Intel pourra dire que ses nouveaux processeurs vont au moins 30% plus vite !!
[^] # Re: Concrètement ?
Posté par Papey . Évalué à 2.
Ou alors pour que tout le monde soit pénalisé et pas seulement les possesseurs de processeurs intel, histoire de noyer le poisson et que la concurrence n'est pas (trop) d'avantage comparatif. Manque de bol, AMD a vu le coup venir !
[^] # Re: Concrètement ?
Posté par claudex . Évalué à 8.
En même temps, quand l'embargo sera terminé, il y a des chances qu'elle soit utilisé. Mais sinon, tu as quoi comme source pour dire que ce n'est pas utilisé ?
« 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: Concrètement ?
Posté par Stinouff . Évalué à 3.
Aucune et mon propos était tout à fait faux, volontairement grossi. Navré que cela n'ait pas paru clair. :)
# Faille utilisée ou pas ?
Posté par windu.2b . Évalué à 10.
Je vois plusieurs commentaires dire que cette faille n'aurait pas été utilisée.
J'aimerais bien qu'on m'explique comment on peut affirmer une telle chose, sachant que la faille serait dans les processeurs Intel depuis 10 ans (la faute aux architectures desdits processeurs, qui ont une partie commune depuis tout ce temps).
[^] # Re: Faille utilisée ou pas ?
Posté par Pinaraf . Évalué à 3.
+1
Sachant que même une faille vicieuse comme rowhammer a fini par être exploitée en Javascript, je vais continuer à n'activer le JS sur internet que sur les sites de confiance…
[^] # Re: Faille utilisée ou pas ?
Posté par flagos . Évalué à 2.
Comme je comprends cette affirmation, ca veut juste dire qu'il n'y a pas d'exploit connu qui utilise cette faille et donc on peut rester tranquille pour l'instant. Après il est tout a fait possible que certains aient utilise cette faille a petite échelle, mais si c'est arrive, ils ont su rester sous le seuil de détection du monde de la sécurité.
[^] # Re: Faille utilisée ou pas ?
Posté par Guillaume Knispel . Évalué à 3.
Il n'y a pas de cas publié d'infection large de malwares utilisant cette technique.
Ça veut pas dire qu'il n'y en n'a pas, ni qu'il va pas falloir patcher ASA(reasonably)P, sauf dans des cas (très rares) où les modèles d'attaques ne seront pas applicables et que les régressions de perfs ne sont pas acceptables.
C'est pas possible de trancher avant la publication des infos détaillées.
[^] # Re: Faille utilisée ou pas ?
Posté par Colin Pitrat (site web personnel) . Évalué à 4.
Perso je pense le contraire. Vu le niveau d'agitation, en particulier chez AWS, Azure etc … je pense qu'un exploit existe et probablement un permettant de s'échapper de l'hyperviseur.
[^] # Re: Faille utilisée ou pas ?
Posté par gUI (Mastodon) . Évalué à 4.
Oui, même OVH a communiqué dessus : https://twitter.com/olesovhcom/status/948518635320070144
Je pense que le usecase hyperviseur est de loin le plus critique en effet.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# autre lien
Posté par David Marec (site web personnel) . Évalué à 7.
Un autre lien, un peu plus précis :
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
mais qui spécule aussi surtout sur la réalité de la faille.
D'après AMD, il s'agirait d'un manque de contrôle lorsque le processeur empile de manière prédictive (speculative) les instructions avant de les exécuter (pipelining).
En bref, tout OS qui laisse l'espace utilisateur et l'espace noyau partager le même espace mémoire, le temps d'une mise en cache (TLB?) serait touché.
Il y a vraiment quelle chose là dessous, mais quoi ? pour l'instant, il faut attendre la levée de l'«embargo» pour en connaître les détails.
[^] # Re: autre lien
Posté par Pinaraf . Évalué à 6.
Plus précis mais aussi plus spéculatif. J'ai choisi (en plus il était tard) de ne pas mentionner ces pistes, même si le point d'AMD semble vraiment fiable.
Mais dire «D'après AMD, il s'agirait d'un manque de contrôle lorsque le processeur empile de manière prédictive (speculative) les instructions avant de les exécuter (pipelining).» est incomplet/incorrect. On ne peut pas expliquer cette faille juste en prenant ce point de vue, il faut a priori partir très bas dans le fonctionnement du CPU, la faille serait au niveau du cœur d'exécution des micro opérations et pas de l'exécution des instructions x86 à proprement parler (sinon ça serait corrigeable par microcode).
Donc attendons la levée de l'embargo à la con qui ne protège personne et ne fait que propager inquiétudes et rumeurs…
[^] # Re: autre lien
Posté par David Marec (site web personnel) . Évalué à 2.
Tout dépend jusqu'où on peut aller, en jouant par exemple avec les macros
__builtin_expect:Sauf si on a empilé des instructions, qui, sans contrôle, via la TLB, pourraient sortir de l'espace utilisateur ?
Je me demande si ce n'est pas lié à l'introduction de la fonctionnalité
PCID/INVPCID, qui permet, en gros, à la TLB de partager en son cache des adressages entre plusieurs processus (au lien d'un seul auparavant) et le noyau.C'est trop tard maintenant, on peut y aller sans attendre vendredi.
[^] # Re: autre lien
Posté par Pinaraf . Évalué à 3.
PCID/INVPCID permet d'implémenter KPTI avec un coût moindre. La faille serait présente depuis avant l'introduction de cette fonctionnalité, certains affirmant même qu'elle date du Pentium 1…
[^] # Re: autre lien
Posté par David Marec (site web personnel) . Évalué à 2.
Par «lié», je ne pense pas seulement à la faille, mais à sa découverte, ou sa révélation.
[^] # Re: autre lien
Posté par Guillaume Knispel . Évalué à 2. Dernière modification le 03 janvier 2018 à 15:24.
Hm les instructions x86 ne sont pas exécutées mais décodées vers des uop. Un problème au niveau du décodage ne serait pas forcement corrigible par microcode, mais ce qui n'est pas corrigible est en général mieux testé que le reste (il faut espérer…).
Toujours est-il que l'anticipation du problème pour le side-channel est en effet plus au niveau d'autres parties "câblées", personnellement j'ai un faible pour les BTB (mais je connais pas assez la microarch pour vraiment savoir si c'est une hypothèse raisonnable ou pas, c'est juste que je trouverais ça stylé)
Concernant la spéculation on est a peu près sûr qu'elle rentre en jeu dans le problème, et techniquement les instructions spéculées sont bien exécutées mais pas complètement retirées. L'idée c'est qu'il existe un changement d'état mesurable dépendant des données lues spéculativement dans la microarchitecture. Si vous avez du temps vous pouvez tester toutes les idées qui vous passent pas la tête, et AMA avec un peu de chance vous pouvez retrouver la technique avant la levée de l'embargo. Il est aussi possible qu'il faille une combinaison tordue mettant en œuvre plein d'interactions de pleins de features pour y arriver (ex: transactionnel, hyperthreading, page faults)
# Les prémisses de cette faille
Posté par Pierrick Bouvier . Évalué à 10.
En cherchant un peu plus sur cette faille, je suis tombé sur l'article suivant datant du mois de juillet dernier.
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
L'auteur est la personne qui a reviewé le patch du kernel Linux mergé par torvalds.
La faille semble en effet liée à l'exécution spéculative de certaines instructions. En juillet, celui-ci a réalisé que les données de l'espace noyau pouvaient se retrouver en cache en éxecution non privilégiée, alors que l'accès devrait lever une faute de protection. Il ne peut en revanche pas lire le contenu de la mémoire. Entre ce moment et aujourd'hui, je pense que ce qui a été trouvé est une façon de lire cette mémoire (les détails viendront sûrement dans les jours à venir).
Visiblement, seuls les processeurs Intel sont concernés, les AMD implémentant correctement cette vérification dans le cadre de l'exécution spéculative.
Le fix implémenté par les OS, si j'ai bien compris, est ainsi de complètement séparer les espaces kernel et user (alors que jusqu'à présent, pour des raisons de perf (éviter un flush de TLB lors du passage en noyau), l'espace kernel était mappé en haut de l'espace user (d'où les 3GB de mémoire utilisable seulement sur un processeur 32 bits). Évidemment, l'accès aux pages du kernel est protégé via un bit d'accès User/Supervisor (http://wiki.osdev.org/Paging, section Page Directory). C'est visiblement ce bit qui n'est pas respecté dans le cadre de l'exécution spéculative.
J'imagine que le plus gros bazar dans cela, en plus de forcer un flush de la TLB (ce qui explique la chute des perfs dans les benchmarks), est de pouvoir toujours lire la mémoire user depuis le kernel, ce qui demande de jongler entre les 2 espaces. Je pense que c'est ce qui fait le plus gros du patch intégré au noyau. Et si torvalds l'a mergé sans broncher en insistant, c'est car c'est grave, et qu'il est encore impossible de divulguer cette faille.
Ce bug est donc assez exceptionnel dans le sens où aucune mise à jour côté microcode du cpu ne peut venir corriger ce problème (sur certains CPU avec des bugs hardware, c'est aux compilos de s'adapter). Il reste donc aux OS à corriger ce souci (Linux, Windows, FreeBSD, MacOS, et tous les autres). La question du parano en suspens est: cette faille était-elle connue avant par certains gouvernements et l'ont ils utilisé?
[^] # Re: Les prémisses de cette faille
Posté par Guillaume Knispel . Évalué à 4.
Petite précision: le jeu de page utilisé quand on est en kernel space map aussi l'espace utilisateur. En plus de ça il map, comme d'hab, (presque) toute la RAM physique (presque pcq des fois des trous sont creusés par d'autres features en aval, mais même en ring0 on y a alors jamais accès). C'est uniquement quand on tourne en userspace qu'il y aura moins de pages mappées. Reste que des flushs sont nécessaires en entrée et en sortie de noyau, y compris en cas d'interruption matérielle (flushs plus ou moins larges, selon les capacités matérielles dispo pour limiter un chouilla les dégâts sur les proc récents)
Bref tout cela reste un vrai désastre en terme de perfs.
[^] # Re: Les prémisses de cette faille
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 04 janvier 2018 à 13:41.
La vraie question parano/complotiste serait de se demander si la faille n'a pas été minutieusement conçue et sciemment introduite par des ingénieurs qui seraient payés par des officines gouvernementales étasuniennes. Un canal caché permettant de trouer toutes les machines sous CPU Intel c'est le rêve absolu pour la NSA.
C'est peut-là que les devs OpenBSD vont se mordre les doigts de ne pas vouloir jouer le jeu des embargos. Cela fait plus de 2 mois que les devs Linux bossent sur KAISER/KPTI car c'est un changement fondamental dans le fonctionnement du sous-système de gestion de la mémoire. Et le travail n'est pas complètement terminé.
Si les devs OpenBSD, lors de la levée de l'embargo, doivent pondre en seulement quelques heures une correction ça risque d'être chaud.
[^] # Re: Les prémisses de cette faille
Posté par Guillaume Knispel . Évalué à 3. Dernière modification le 03 janvier 2018 à 15:44.
J'ai parcouru vite fait les patchs et certes il y a plein de détails à régler, mais le plus important est assez localisé, la suite semble relativement dépendant de la propreté de l'OS dans cette zone, et le reste c'est de la limitation des dégâts sur l'impact sur les perfs. Évidemment même faire un truc basique c'est pas trivial, mais en passant par une première étape qui se concentre sur la sécu et si avec un peu de chance le noyau d'OpenBSD est propre dans cette zone (j'en sais rien) c'est jouable de faire un truc semi-rapidement :p (mais qui risque quand même de crasher un peu à droite à gauche au début; y a déjà un rapport de régression pour Athlon 64 pour Linux)
[^] # Re: Les prémisses de cette faille
Posté par patrick_g (site web personnel) . Évalué à 5.
On parle quand même d'un changement représentant 51 patchs et qui, au 18 décembre, en était à la version 163.
Autrement dit c'est pas du tout trivial.
[^] # Re: Les prémisses de cette faille
Posté par Guillaume Knispel . Évalué à 3. Dernière modification le 03 janvier 2018 à 16:37.
C'est pas trivial. Mais faut relativiser un peu : le découpage de la série est très fin. Du style l'ajout d'une option qui ne fait rien (au moment précis de son ajout) prend un patch rien que pour ça.
[^] # Re: Les prémisses de cette faille
Posté par David Marec (site web personnel) . Évalué à 2.
Mouais, enfin, sur ce coup là, ce sont les devs Linux qui n'ont pas joué le jeu, en publiant leur patchs avant l'heure.
Du coup l'embargo est levé, plus ou moins:
Google:
[^] # Re: Les prémisses de cette faille
Posté par anaseto (site web personnel) . Évalué à 2.
Je me demande si FreeBSD, NetBSD, DragonFly, etc. ont été eux prévenus.
[^] # Re: Les prémisses de cette faille
Posté par patrick_g (site web personnel) . Évalué à 7.
Et ça se confirme : https://www.mail-archive.com/tech@openbsd.org/msg43791.html
Donc pour l'instant la faille Meltdown est béante sous OpenBSD et aucun correctif n'est disponible :-(
[^] # Re: Les prémisses de cette faille
Posté par Nitchevo (site web personnel) . Évalué à 7.
Je eux te proposer une autre version:
"Chef! Vous avez vu ce qui se passe si on exécute une instruction conditionnelle en mode noyau sans avoir les droits? Parce qu'elle s'exécute quand même, le résultat est stocké en mémoire et ce n'est qu'ensuite que le proc se posera la question de savoir s'il peut poursuivre mais à ce moment le cache n'est pas vidé…"
"Euh oui c'est embêtant mais tout ce qu'on nous demande c'est d'implémenter des specs pas de les réécrire et en plus on va perdre des mois à réécrire les specs et en plus ça diminue les performances et la concurrence va nous bouffer…."
Ne jamais mettre à priori en cause la malveillance là où la bêtise est une explication plausible.
[^] # Re: Les prémisses de cette faille
Posté par David Marec (site web personnel) . Évalué à 3. Dernière modification le 03 janvier 2018 à 23:07.
Pour ce qui est de FreeBSD, ils viennent de répondre.
Pour dire … qu'ils ne peuvent rien dire.
Avec un nouveau lien en prime, la réponse de Intel.
Attention, ils indiquent qu'ils ne sont pas les seuls concernés, AMD,les ARM le seraient tout autant.
De plus, ils seraient en mesure de patcher le problème pour en atténuer les effets.
[^] # Re: Les prémisses de cette faille
Posté par paulez (site web personnel) . Évalué à 3.
Dans sa réponse Intel indique que “beaucoup de fabricants de processeurs et de systèmes d’exploitations” sont concernés, et qu’ils “travaillent de manière rapprochée avec AMD et ARM”, mais pas directement qu’AMD est concerné.
[^] # Re: Les prémisses de cette faille
Posté par David Marec (site web personnel) . Évalué à 2.
Oui, j'ai lu un peu vite.
Ceci dit, d'une part, ils affirment bien qu'ils ne sont pas les seuls et d'autre part, ce n'est pas leur rôle
non plus de dénoncer les copains.
[^] # Re: Les prémisses de cette faille
Posté par David Marec (site web personnel) . Évalué à 5. Dernière modification le 03 janvier 2018 à 23:54.
Google, par contre, ne se gêne pas pour le dire:
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
fin de l'embargo.
[^] # Re: Les prémisses de cette faille
Posté par paulez (site web personnel) . Évalué à 2.
À noter dans les détails de leurs tests, ils n'ont pas de PoC qui permette de lire un espace mémoire protégé avec un processeur AMD dans une configuration standard. De plus ils mentionnent ARM, et le seul PoC qui fonctionne pour ARM et AMD permet de lire de la mémoire dans le même process en utilisant le concept de l'attaque, donc il n'y a pas vraiment de preuve que ça soit exploitable.
[^] # Re: Les prémisses de cette faille
Posté par paulez (site web personnel) . Évalué à 6.
C’est clairement spécifié sur la page https://spectreattack.com/:
– L’attaque Meltdown affecte tous les processeurs Intel out of order, ce n’est pas clair si elle affecte les processeurs AMD et ARM
– L’attaque Spectre affecte les processeurs Intel, AMD et ARM.
# Garantie et vice caché
Posté par arnaudus . Évalué à 10.
Quand je vois ce genre d'infos, je me dis que le monde de l'informatique (à la fois du software et du hardware) est drôlement bien protégé par la loi, la jurisprudence, et/ou des armées d'avocats. Dans beaucoup de domaines, le constructeur serait obligé (légalement ou pour des raisons commerciales) d'échanger gracieusement le matériel défectueux, puisqu'il s'agit ici assez clairement d'un vice caché.
Bien sûr, techniquement, ça serait très compliqué ; il faudrait déja déterminer qui et comment on démonte les machines, comment on gère la multiplicité de responsables dans la chaine (vendeur, assembleur, etc). Du coup, au final, bah c'est magique : tu as acheté du matériel défectueux, et c'est pour ta pomme, même si ça fait 2 mois que tu l'as, même s'il s'avère que tu es victime d'une attaque qui exploite la faille… C'est pour toi.
C'est la même chose d'ailleurs pour les bugs logiciels. Certaines licences te proposent une mise à jour/correction de bugs et de failles pour un an, et puis il faut payer pour continuer. Comme si les bugs et les failles n'étaient pas des vices dans un produit que tu as acheté, et que le vendeur était tenu de corriger. L'informatique a juste redéfini le code de la consommation sur la base d'arguments techniques : 1) les vices cachés et les défauts de fonctionnement sont «normaux» dans des produits d'une telle complexité, 2) personne n'est responsable pour les dommages directs et indirects liés à ces vices, 3) il est tolérable de demander au client de facturer la correction de ces erreurs.
[^] # Re: Garantie et vice caché
Posté par Ben . Évalué à 4.
Effectivement, c'est assez différent du reste de l'industrie.
Cependant, les contrats de prestations comprennent tous des éléments liés aux dommages directs et indirects. Les dommages indirects sont souvent exclus, les dommages directs sont eux inclus et en général plafonnés selon la valeur du contrat de prestation. (par exemple limités à la valeur du contrat de prestation ou à 200% de la valeur).
[^] # Re: Garantie et vice caché
Posté par Psychofox (Mastodon) . Évalué à 10.
ouais enfin on ne peut pas nier que l'industrie informatique a pour habitude de "baiser" ces clients. Au niveau du matériel l'europe et son obligation de garantie de 2 ans minimum aide un peu, mais pour la partie logicielle le concept de contrat de supports vendus à vil prix pour une grande majorité de logiciels finis à la pisse par leurs éditeurs c'est digne de techniques mafieuses mafia.
Ça fait plus de 25ans que je travaille dans le domaine et ça m'étonne toujours autant qu'une dsi puisse accepter de payer des factures à une société pour une solution informatique qui est au mieux bancale et au pire pas du tout fonctionnelle des mois après son introduction.
[^] # Re: Garantie et vice caché
Posté par arnaudus . Évalué à 8.
Attends, tu es en train de me dire que les contrats de maintenance d'un parc de serveurs inclut le remplacement des procs Intels par des processeurs équivalents sans le bug hardware dont on parle ici? :-) À mon avis, non. Ton contrat couvre les pannes mécaniques, pas les défauts de conception. On peut aussi citer les BIOS/UEFI daubés, le hardware qui n'implémente pas correctement les normes, etc. Dans un journal précédent, quelqu'un parlait par exemple d'une imprimante certifiée Linux par son constructeur. Au final, il fallait hacker un truc avec le driver windows, et l'imprimante fonctionnait mal quand même. Résultat? Dans le fion. La seule chose que le constructeur admet, c'est que le matos doit sortir de l'usine tel qu'il était conçu. S'il est tellement mal foutu qu'il est inutilisable pour toi, tu dois attendre un éventuel geste commercial du vendeur (reprise et échange, par exemple). L'impunité est quasi-totale, y compris vis-à-vis de pubs totalement mensongères ou trompeuses (sur les capacités des supports de mémoire, sur la mémoire vive, sur la fréquence des processeurs…). C'est vraiment la jungle, c'est juste le marché qui s'est établi comme ça.
[^] # Re: Garantie et vice caché
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Heu non. Je suis dans un bâtiment (public) assez neuf (moins de 5 ans) et malgré les défauts multiplement signalés depuis l'origine, on se démerde pour bidouiller notamment le logiciel de GTC pour trouver non pas un fonctionnement optimal mais un fonctionne qui marchouille a peu près… Je ne parle pas du scotch que j'ai du mettre aujourd'hui sur une gaine de ventilation pour éliminer un sifflement insupportable !
[^] # Re: Garantie et vice caché
Posté par claudex . Évalué à 9.
Je ne suis pas sûr que beaucoup d'industries remplacent le matériel pour 5% de diminution de perf, peut-être une petite ristourne. Parce que les cas à 30%, il ne va pas en avoir des masses.
Ça dépend des bugs mais je suis d'accord. Cependant, combien de temps les failles de sécurité devraient-elles être corrigées ? Est-ce que Microsoft devrait toujours fournir des patchs pour MS-DOS 1.0, ou plus raisonnablement, NT 4.0? Est-ce que Linus devrait toujours maintenir la branche 1.0?
« 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: Garantie et vice caché
Posté par arnaudus . Évalué à 6.
C'est clair que ça dépend de l'industrie. Sur un panneau photovoltaïque, 5% de perfs, ça peut être assez sensible. Pour une bagnole, 5% de consommatipn en plus, ça se chiffre en milliers d'euros sur la vie du produit. Sur un avion, 5% de perfs sur un moteur, ça repart à l'usine.
Sur un parc de serveurs, 5% de CPU en plus ou en moins, c'est pas rien. Il faut racheter du matériel pour compenser, ça a un coût réel.
Mais sur le fond, je pense que le problème n'est pas la question des perfs, de toutes manières, c'est la question de la faille de sécurité. C'est aussi de la chance qu'elle puisse être bouchée par le kernel pour un côut raisonnable en termes de performances.
C'est peut-être quelque chose à régler dans le contrat de licence. Je ne sais pas comment font les constructeurs automobiles, par exemple. Après 10 ans, est-ce qu'ils acceptent encore de réaliser les opérations visant à corriger les problèmes de sécurité? Je pense que oui, mais je ne sais pas s'il y a beaucoup de cas (en même temps, c'est compliqué, parce qu'une voiture, ça s'entretient, il y a des pièces d'usure, etc, donc celles-là ne sont pas couvertes par le constructeur).
En fait, je ne sais pas s'il existe une autre industrie qui se permet de commercialiser des produits aussi mal testés et mal finis que l'industrie du logiciel. Évidemment, le problème de base, c'est la complexité des systèmes informatiques, mais cette complexité, elle est beaucoup liée à des décisions techniques et industrielles, voire commerciales (et même politiques) ; il y a peu de problèmes réellement intrinsèques au principe de commercialiser un logiciel.
[^] # Re: Garantie et vice caché
Posté par moi1392 . Évalué à 4.
Les utilisateurs/clients ne sont pas complètement à mettre hors de cause.
Beaucoup préfères un clickodrome bogué, mal conçu, qui rame et a des tas de souçis qu'un système plus sain mais plus complexe à appréhender et à maîtriser.
Du coup les efforts de développement vont plus facilement dans ce sens. Et c'est normal d'un point de vue commerciale pour une boite, sinon elle coule faute de clients.
[^] # Re: Garantie et vice caché
Posté par Thomas Douillard . Évalué à 5.
Fausse dichotomie. Le « clicqodrome » plus pratique expose plus facilement un ensemble de fonctionnalité plus restreint, donc théoriquement plus facile à fiabiliser.
Alors que le truc plus paramétrable est plus ouvert reporte la fiabilisation sur chacun mais permet aussi des configurations improbables probablement bourrées de failles car utilisées par 3 pékins qui ont l’impression de tout maîtriser mais qui, si on pense en terme de couverture de test par exemple, ont des tas de chemins de code qui n’ont jamais été empruntés.
https://xkcd.com/1172/
De ce que tu dis, j’ai l’impression que tu penses que fiabiliser des briques de base est simple, et que fiabiliser un système plus intégré est plus difficile. Sauf que la solution est sans doute de proposer à l’utilisateur des solutions intégrées et testées basées sur des briques de base fiables. Parce qu’il y a une complexité à tous les niveaux. Et c’est une affaire de professionnel de la gérer, pas à ta grand mère infirmière retraitée qui veut juste faire une vidéoconf avec son arrière petit fils de se demander quelle solution de cryptage elle doit utiliser pour téléphoner.
[^] # Re: Garantie et vice caché
Posté par moi1392 . Évalué à 1.
je parlais rétrospectivement de ce que j'ai vu/su de l'histoire récente de l'informatique (depuis le milieu de année 90 je dirais)
Je n'ai pas dit que ce qui était plus simple à utiliser était forcément moins fiable, mais que dans les fait récents, souvent, une relative simplicité d'utilisation allait de pair avec une fiabilité moindre, et que le choix des utilisateurs/acheteurs/clients allait dans ce sens là.
On choisi la simplicité d'utilisation même dans les cas où c'est moins fiable (en terme de bugs ou de sécurité), et mon étude très sérieuse basée sur la subjectivité de ma mémoire pifomètrisée me dit que cela à bien plus souvent été le cas que le contraire (plus simple et plus fiable)
Après, on peut discuter ce point bien sur.
[^] # Re: Garantie et vice caché
Posté par fasthm . Évalué à 10.
Les constructeurs automobiles allemands quand ils se font prendre à gruger ? Ah non, pas en Europe.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: Garantie et vice caché
Posté par Arkem . Évalué à 2.
Ou plutôt d'un défaut de conception / fabrication sensé être couvert par la garantie. Un vice connu, mais caché par le vendeur, ça relève plutôt de la justice il me semble… au risque de me faire l'avocat du diable, rien ne prouve pour l'instant que le vice était connu dans cette affaire… sauf pour les processeurs achetés récemment, en tout cas
[^] # Re: Garantie et vice caché
Posté par arnaudus . Évalué à 4. Dernière modification le 05 janvier 2018 à 14:10.
Non non, ça n'a rien à voir. Dans une vente entre un professionnel et un particulier (ou une entreprise qui n'a pas le même secteur d'activité), la garantie contre les vices cachés est une garantie légale en France. "Caché", c'est dans le sens qu'il n'était pas détectable par l'acheteur au moment de la vente, que le vendeur soit au courant ou non. Cette garantie n'a pas de limite dans la durée, même 10 ans après l'achat, on peut la faire jouer. Là où on peut ergoter, c'est que le problème doit être majeur, rendre l'objet inutilisable, ou au moins influencer la décision d'achat (on ne l'aurait pas acheté, ou pas au même prix, si on avait été au courant). C'est pas complètement évident pour les puces Intel, si on parle de 5% de perfs, c'est pas clair, mais si c'est 10 ou 20%, ça peut faire une différence. Je pense que l'argument 5% de perfs en moins -> 5% de ristourne pourrait fonctionner.
Dans le cas d'une transactions entre particuliers, il est possible pour le vendeur de ne pas se soumettre à cette garantie, mais ça doit être écrit et accepté par l'acheteur. Et ça n'est valable que si le vendeur n'était pas de mauvaise foi (s'il était au courant du vice caché, il devra remplacer ou rembourser). C'est peut-être à cette situation là que tu faisais référence, mais ça n'est pas applicable à Intel.
# Quid du POWER ?
Posté par Dabowl_75 . Évalué à 4.
Si le POWER n'a pas été cité, pourrait-il être concerné ?
D'après ce que j'ai compris, le POWER utilise l'ERAT (Effective to Real Address Translation) et le TLB dans la translation d'adresse.
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0956.html?Open
Une comparaison avait été faite entre le power8 et intel sur les aspects de TLB :
https://www.anandtech.com/show/10435/assessing-ibms-power8-part-1/3
Le TLB est plus gros sur le power, si on en vienait à devoir le flusher, les impacts pourraient-ils être plus importants ?
Ce sera intéressant d'observer le discours d'IBM sur le sujet…le silence ou bien le marketing pour brandir un avantage concurrentiel.
Pour l'heure, l'action d'intel ne baisse pas vraiment…
[^] # Re: Quid du POWER ?
Posté par David Marec (site web personnel) . Évalué à 4.
D'après cette page:
https://access.redhat.com/security/vulnerabilities/speculativeexecution
La gamme IBM est aussi touchée.
[^] # Re: Quid du POWER ?
Posté par Dabowl_75 . Évalué à 4.
Je viens aussi de recevoir le bulletin redhat.
C'est moche :-/
# Infos détaillées
Posté par Jean-Max Reymond (site web personnel) . Évalué à 2.
Il semble que désormais Google communique avec les cas d'erreurs:
https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html
[^] # Re: Infos détaillées... et des logos
Posté par Al . Évalué à 5. Dernière modification le 04 janvier 2018 à 00:13.
Les attaques ont à présent un site, des noms (Meltdown et Spectre), des jolis logos et des explications détaillées :
https://spectreattack.com/
[^] # Re: Infos détaillées
Posté par ®om (site web personnel) . Évalué à 9. Dernière modification le 04 janvier 2018 à 01:20.
Voici un petit résumé de ce que j'ai compris.
L'idée est de faire en sorte que des accès mémoire "non autorisés" soient réalisés en "exécution spéculative". Par exemple, lorsque
lengthn'est pas en cache dansif (index < length) { … }, le processeur exécute déjà spéculativement les instructions du blocif. Ce ne devrait pas être un problème, car une fois toutes les informations connues – dans cet exemple,length–, si la condition est fausse, l'exécution est "oubliée".C'est sans compter sur les effets de bords : les loads effectués dans l'exécution spéculativent restent en cache L1. Ainsi, il est possible de provoquer un chargement en cache selon une valeur en mémoire "non autorisée" qu'on veut leaker. Ensuite, en mesurant le temps pour accéder à ces mêmes données, on est capable de savoir si elles étaient en cache ou non, donnant indirectement des informations sur la valeur en mémoire qu'on voulait récupérer.
Voir notamment la theoretical explanation de Variant 1 dans le post googleprojectzero.
blog.rom1v.com
# Ça pue pas mal
Posté par Albert_ . Évalué à 3.
A fix may not be available for Spectre until a new generation of chips hit the market.
Meltdown semble bien specific à Intel et vu l'impacte en terme de performances AMD doit pas être mécontent…
# ARM et AMD aussi ?
Posté par gUI (Mastodon) . Évalué à 2.
Il semblerait que finalement ce soit bcp plus général !
https://twitter.com/rhhackett/status/948654425824022530
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: ARM et AMD aussi ?
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 04 janvier 2018 à 08:07.
Google le dit clairement : https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.
… et Intel aussi (mais là, il y a un parti pris :) ) : https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: ARM et AMD aussi ?
Posté par claudex . Évalué à 10.
Il y a deux failles, une interprocess uniquement pour Intel et une intraprocess pour tout le monde.
« 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
# Détails techniques
Posté par TilK . Évalué à 10.
Les détails techniques ont été publiés par Project Zero, ici et là.
Pour les décideurs pressés, il semble y avoir 3 failles :
Les deux premières ont été nommés Spectre et la troisième Meltdown.
L'équipe a réalisé 4 PoC :
Pour être franc, je n'ai pas compris tous les détails de ces PoC, mais ils semblent être toutes construits de la même façon. Je vais donc parler du premier, qui semble le plus simple à comprendre. Le PoC semble être quasiment le même mais au niveau assembleur plutôt qu'en C.
Le code en question est :
En gros, dans un bloc conditionnel qui sera toujours faux, une demande de lire un bit de la mémoire en faisant un débordement de buffer. Puis en fonction du résultat de la lecture, on va écrire dans un buffer accessible par l'utilisateur dans un offset différent suivant si c'est un 0 ou 1.
Dans un second temps (non montré dans le code), on va tester la vitesse de lecture de ce buffer au deux offsets. Celui dans la lecture est le plus rapide indiquera la valeur du bit lu précédemment.
Comment cela fonctionne ? En gros, le CPU va penser que le bloc conditionnel sera vrai, et donc va chercher à l'évaluer en avance de phase. C'est de l'Exécution_spéculative et cela fait gagner du temps au CPU. En fonction de la valeur lue, on va écrire la donnée dans un offset particulier d'un tableau. Cela va donc charger cette case mémoire en cache. Quand le CPU va voir que la condition est fausse, il va donc défaire les calculs qu'il a déjà fait, l'offset du tableau ne contiendra pas la valeur calculée, néanmoins il restera en cache.
Quand on cherchera a tester les temps d'accès au offsets en question, celui chargé en mémoire sera plus rapide, et donc on pourra savoir qu'elle est la valeur lue.
Ce PoC ne sert pas à grand chose, mais permet de comprendre comme la gamme de failles fonctionne.
Dans une branche qui ne doit pas être exécutée, mais que le CPU exécutera "au cas ou", on essayer d'accéder à de la mémoire qu'on ne doit pas pouvoir lire. Même si cette exécution sera défaite par la suite, on cherche un moyen de connaitre la valeur de la lecture en utilisant un canal caché (présence d'objet dans un cache par exemple).
[^] # Re: Détails techniques
Posté par windu.2b . Évalué à 2.
Merci pour ces explications.
Si je comprends bien, la solution (matérielle ou logicielle) pour corriger ça reviendrait à désactiver cette exécution spéculative ? Et c'est la perte de cette optimisation qui coûterait 5% à 30% de plus de temps de traitement ?
[^] # Re: Détails techniques
Posté par TilK . Évalué à 5.
En fait, non.
La solution qui semble avoir été retenue, est de séparer très fortement la mémoire du kernel et la mémoire des processus. De cette façon, il n'y a plus moyen d'accéder depuis un processus à la mémoire du kernel.
A cause de cela, à chaque appel de fonction du kernel (syscall), il est nécessaire de recharger la mémoire du kernel (avant elle était disponible), ce qui peux coûter très cher.
[^] # Re: Détails techniques
Posté par erdnaxeli (site web personnel) . Évalué à 3.
Ça fixe une des failles (lire la mémoire kernel depuis l'espace utilisateur), mais pas toutes. Ça n'empêche pas de s'échapper d'une sandbox ou d'un hyperviseur (exemple : accéder en js à toute la mémoire du navigateur). Dans ces cas il faut des patches par logiciel.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Détails techniques
Posté par Dabowl_75 . Évalué à 2.
Est-ce à cause du du flush de la TLB que la MMU doive remapper les pages ?
[^] # Re: Détails techniques
Posté par ®om (site web personnel) . Évalué à 2.
A priori, il suffirait que cette exécution spéculative n'ait pas d'effets de bords.
Je n'y connais rien en matériel, mais serait-il possible d'avoir un cache spécifique à l'écriture par l'exécution spéculative? Le code exécuté spéculativement pourrait lire le cache "normal", mais ne pourrait écrire que dans un espace qui lui est réservé, qui serait ensuite commité sur le cache normal une fois la branche "validée". Ainsi, les effets de bords exploités dans ces attaques seraient supprimés.
blog.rom1v.com
[^] # Re: Détails techniques
Posté par Kerro . Évalué à 2.
Je dirais plutôt qu'il faut que l'exécution spéculative tienne compte des autorisations d'accès à la mémoire. Ou je n'ai pas pigé quelque chose ?
[^] # Re: Détails techniques
Posté par ®om (site web personnel) . Évalué à 4.
De ce que j'ai compris, si l'exécution spéculative lit des données "non-autorisées", ce n'est pas grave (ça reste interne au CPU), tant qu'il n'y a pas d'effets de bords permettant d'extraire ces données.
blog.rom1v.com
[^] # Re: Détails techniques
Posté par David Marec (site web personnel) . Évalué à 3.
Attention avant de conclure que seul Intel est seul concerné par Meltdown.
Les auteurs ne sont pas aussi catégoriques.
Ils expliquent juste que leur «POC» (qu'ils appellent «toy») n'a pas réussi à obtenir de résultat.
Par contre, leur tests et leurs mesures laissent supposer que c'est possible.
Il n'y sont juste pas arrivé avec leur outil, (technique de
Flush+Reloadque vous indiquez):Comme il existe d'autre techniques pour stresser attaquer un cache …
Bref, ce n'est pas fini.
Ceci dit une simple interdiction des appels à
rdtscp(pour détecter la mise en cache) peut bloquer ce genre d'attaque.Il semble que c'est déjà le cas de certains hyperviseurs.
[^] # Re: Détails techniques
Posté par TilK . Évalué à 5.
Tout à fait,
J'ai eu un peu plus de temps pour lire l'article sur Meltdown, et je comprends que c'est différent de ce que j'avais écrit.
Spectre utilise l'Exécution_spéculative alors que Meltdown utilise l'Exécution_dans_le_désordre et le fait que la vérification des droits d'une lecture est faite en parallèle de cette lecture.
A priori, le code semble être organisé comme cela (n'hésitez pas à me contredire si je dis des conneries, c'est grandement probable) :
A cause du "Out-of-order execution", l'instruction 2 sera exécutée avant/en même temps que l'instruction 1. La lecture de l'instruction 2 sera faite en parallèle de la vérification des droits de cette lecture. On espère que cette vérification des droits sera lente et que l'instruction 3 puisse être exécutée avant l'instruction 2. Au final, soit l'exception de l'instruction 1 est levée, soit la vérification des droits de l'instruction 2 va râler, et on va défaire les instructions 2 et 3.
Mais comme pour Spectre, les caches seront modifiés, et on peut connaitre la valeur lue au travers de ce canal caché.
Les auteurs ne sont pas arrivés à reproduire la faille entièrement sur AMD, mais ils pensent que c'est possible. AMD annonce le contraire.
Sous Linux, cela permet d'accéder en lecture à la mémoire du kernel, qui contient l'ensemble de la mémoire physique de la machine et donc la mémoire utilisée par les autres processus. Sous Windows, cela permet d'accéder à la mémoire du kernel, et une partie seulement de la mémoire physique. Cela permet de casser les containers par exemple.
PS : Pour Spectre, il existe un POC en javascript qui permet de fuiter la mémoire de Chrome :-/
# Bordel ?
Posté par liberforce (site web personnel) . Évalué à 5.
Toute cette histoire pue comme les couches de la veille. C'est la boîte de pandore qui vient d'être ouverte. Une énorme majorité des processeurs est touchée, des mises à jour sont en train d'être peaufinées pour déploiement et… ne seront jamais déployées, parce que:
Même pour ceux qui auront les mises à jour, il va s'écouler du temps avant qu'elles ne soient disponibles. Google parle de correctifs pour Chrome pour la fin du mois, les constructeurs de smartphone qui ont des produits sous Android affectés ne sont souvent pas des plus réactifs… Cela laisse des machines vulnérables à tous les maichants qui doivent bosser dur pour exploiter cette faille le plus vite possible. Dès qu'ils vont trouver moyen d'exploiter la faille en javascript, Internet va être un endroit beaucoup moins fun…
J'ai peur que les premières exploitations de ces failles soient dévastatrices. C'est grave docteur ?
[^] # Re: Bordel ?
Posté par Pinaraf . Évalué à 5.
Certaines mesures d'hygiène informatique (souvent casse-couilles) diminuent considérablement l'impact tout de même.
Pour meltdown, les détenteurs de CPU Intel n'ont pas le choix, mise à jour du noyau et activation de KPTI…
Pour spectre, sur nos machines perso, la plus grosse attaque possible serait du code JavaScript qui va lire la mémoire du navigateur web (et donc des infos sur les autres sites). Je me sens moins concerné, j'utilise en permanence 4 instances de navigateur web, selon le type de site visité et la sensibilité des données qu'il manipule. Pour à travers spectre voler des infos sur mon compte bancaire, il faudrait que, depuis son domaine (NoScript bloquerait le reste), une de mes banques en attaque une autre.
De manière générale, il serait temps de se demander pourquoi on laisse n'importe quelle page web exécuter du code sur nos machines. Est-ce-que ça en vaut vraiment la peine ?
Et pourquoi Google a laissé pendant tant d'années (et semble continuer encore) des fabricants de smartphone vendre des Android sans garantie de maintenance sur la durée ?
[^] # Re: Bordel ?
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Surtout, pourquoi la France n'impose pas une garantie de 2 (ou 3) ans minimum sur tous les téléphones ainsi qu'une obligation de maintenance (pièce détachée…) par exemple 5 ans après la vente du dernier téléphone, comme dans l'automobile (ou il me semble que c'est 10 ans) ? D'ailleurs, on pourrait généraliser cela à une grande partie du matériel informatique afin de limiter l’obsolescence programmé.
[^] # 2 ans de garantie
Posté par dovik (site web personnel) . Évalué à 2.
C'est déjà 2 ans la garantie en France.
La garantie "légale" c'est 2 ans, la garantie "contre les vices cachés" c'est 2 ans après la découverte.
La garantie "commerciale" (celle mise en avant par les commerçants) peut-être moins longue (et payante) mais ne te prive pas de la garantie légale.
[^] # Re: Bordel ?
Posté par Renault (site web personnel) . Évalué à 3.
C'est une question complexe.
Augmenter la durée de garantie est toujours possible mais ce n'est pas gratuit. Pour des produits assez bas de gammes, la hausse de prix peut-être non négligeable ce qui peut impacter de nombreux utilisateurs.
L'autre soucis c'est que l'environnement, les normes et autres évoluent aussi. Typiquement dans 10 ans, la 2G et la 3G vont probablement disparaître. La radio et la télévision analogiques aussi. Est-ce que garantir des appareils si dépendants d'infrastructure si longtemps est pertinent ?
En plus, un logiciel a toujours des bogues, plus ou moins importants. Comment évaluer quels bogues doivent être corrigés ou non et sur qu'elle durée ? Jusqu'ici c'est l'éditeur qui le décide mais si on souhaite des garanties plus fortes cela ne devrait pas être le cas. Et gérer cela n'est pas évident du tout.
[^] # Re: Bordel ?
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
En pratique, cela impose aux vendeurs de ne pas vendre de la merde. J'ai été en Asie centrale, les marchés sont envahis par des produits super bas de gamme : jouet, pile, électronique… Tout cela finit rapidement à la poubelle.
Il arrive un moment ou pour la planète, il faut protéger l'acheteur contre lui même donc les produits trop peu chers !
Comment faire ? Là est toute la question.
[^] # Re: Bordel ?
Posté par Renault (site web personnel) . Évalué à 2.
Attention, je ne dis pas qu'une garantie légale plus longue est dénuée d'intérêt. Je comprends parfaitement que cela évite d'avoir des objets trop peu fiables.
Mais le corollaire, c'est que cela impose d'utiliser des composants plus durables (et donc souvent plus chers), d'avoir une meilleur conception (donc plus de temps et d'ingénieurs qui bossent dessus) et pour compenser les pertes liés aux défauts durant la garantie ils vont sans doute augmenter leur marge prévisionnel sur le produit. Sans compter pour le logiciel une équipe à payer plus longtemps pour suivre le produit et le maintenir (ce n'est pas gratuit).
Au total pour des produits peu chers (pensons globalement aux téléphones d'en dessous de 200€), la hausse peut être assez conséquente. C'est bon pour la planète et la durée de vie du produit, mais pour certains utilisateurs la hausse risque de faire mal au portefeuille (on peut penser à une hausse de prix de 10 à 30% du prix d'achat actuel).
C'est un exercice compliqué, d'autant qu'avec l'évolution des logiciels, des normes et des technologies, avoir un téléphone portable qui tient 10 ans n'est pas forcément très pertinent. Au delà de 5 ans déjà tu risques de faire de la surqualité (beaucoup d'utilisateurs changeront de téléphone avant même que le produit ne soit défectueux).
Je pense sincèrement qu'il faut établir des garanties sectorielles qui tienne compte de cela. Tant que l'informatique évoluera vite, imposer une longue garantie n'est pas forcément pertinent de part ces contraintes de coûts et du remplacement naturel avant défaut. Il semble évident que pour l'électroménager ou une voiture par exemple, ce soit différent car la longévité de ces produits es de fait plus longue.
[^] # Re: Bordel ?
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
Disons que ta réponse aurait du sens si les téléphones actuels avaient une chance de durer 5 ans. C'est loin d'être le cas.
Notamment parce que pour avoir des mises à jour logicielles (et donc sécurité + applis qui fonctionnent) pendant 5 ans à partir du moment où tu l'as acheté (et pas le moment où le téléphone est sorti), tu peux un peu te gratter.
Mis à part chez Apple, bizarrement.
Rien qu'avoir un engagement de 3 ans, ce serait déjà pas mal…
[^] # Re: Bordel ?
Posté par Kerro . Évalué à 7.
Mon téléphone a 6 ans. Il fonctionne sans problème.
Celui de ma femme a 5 ans. Je ne m'en suis jamais occupé, donc ce n'est pas ma patte qui est en jeu.
--> qu'est ce qui empêche tes téléphones de fonctionner 5 ans ?
[^] # Re: Bordel ?
Posté par GG (site web personnel) . Évalué à 4.
Le miens à plus de 5 ans, et ça fait longtemps qu'il n'a plus de màj de sécurité, même les dernières que je n'avais pas pris le temps d'appliquer ne sont plus disponibles.
Il fonctionne encore, mais il n'est pas sécurisé (et j'ai quelques bugs pénibles sur certaines fonctionnalités).
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Bordel ?
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
Le matériel de ton téléphone, oui (avec potentiellement un changement de batterie).
Le logiciel qui est dessus, pour l'énorme majorité des smartphones (un non smartphone est tout de suite moins exposé), n'est pas supporté pendant 5 ans (tu as de la chance quand c'est supporté 1 an…). Donc tu as potentiellement tout un tas de failles de sécurité.
Pour moi, c'est un tout. Avoir un téléphone pas sécurisé du tout, ça craint quand même pas mal.
[^] # Re: Bordel ?
Posté par Renault (site web personnel) . Évalué à 6.
Mis à part un changement de batterie qui est souvent indispensable dans les 5 ans, le reste fonctionne souvent très très bien au bout de 5 ans.
En fait le problème vient du fait que l'informatique reste un domaine un peu spécial. Tu achètes une machine avec des specs X, mais avec le temps les applications (par la loi de Worth) attendent des specs Y pour fonctionner correctement. Mais l'utilisateur lui veut toujours exploiter les derniers logiciels disponibles, à jour, avec plus de fonctions, etc.
Le constructeur, quand il vend son engin, il vend des specs matériels (voire logiciels) figés et peut difficilement faire autrement. Ton processeur ne va pas magiquement au bout de 2 ans être plus performant. Par contre au bout de 5 ans, à part la batterie qui est souvent fragile, le reste du matériel fonctionne souvent aussi bien que lors des premiers jours.
Mais tu ne le vois pas, car les applications se mettent à jour pour des raisons de sécurité mais aussi pour proposer plus aux utilisateurs (et exploiter des capacités des derniers téléphones). Mais comme ta machine n'évolue pas, forcément cela te paraîtra plus lourd, moins réactif, voire difficile de mettre à jour.
Le constructeur n'est pas responsable de ces évolutions. Il n'est pas responsable que le Bluetooth 2.1 ne permet pas de rapidement transférer des fichiers multimédias toujours plus lourds, qu'un processeur bas de gamme de 2011 puisse difficilement lire le fichier vidéo 4K que ton copain a fait depuis son dernier iPhone, ou naviguer de manière fluide sur des sites lourds actualisés comme Amazon ou Facebook. Il n'est pas responsable non plus si le dernier Candy Crush a besoin de plus de specs graphiques qu'à l'époque de l'achat.
Contractuellement, il t'a vendu un processeur de 2011, avec 1 Gio de RAM et c'est tout. Si le reste évolue de sorte à le rendre inopérant, est-ce de la faute du constructeur ? Non.
C'est en ça que l'informatique est un peu exceptionnel, on a du matériel qui va exécuter des logiciels très différents suivant les utilisateurs et des logiciels qui vont évoluer dans le temps. En général quand tu achètes un produit, son cas d'usage est limité dès l'achat et il n'y aura pas évolution de ce dernier. Ma machine à laver lave mon linge de la même manière que le jour de son achat. Il ne permet pas plus, ni moins et ne le pourra jamais sauf bien entendu lorsqu'il y aura panne. Ton téléphone exécute des logiciels qui n'existait pas le jour de son lancement. Et le fera encore dans les mois et années à venir, que ce soit par les mises à jour de ces applications ou par la création d'une nouvelle.
Le code de la consommation et la mentalité des consommateurs ne sont pas vraiment taillés pour cette nouvelle donne. C'est un changement important. Le code de la consommation stipule que ton téléphone doit fonctionner tel que vendu le jour de la vente pendant 2 ans. Et à part une panne d'un composant, c'est très souvent respecté pendant 2-5 ans. De plus, l'utilisateur s'attend à ce que le logiciel soit mise à jour durant ce laps de temps, mais tu connais un secteur où pendant X temps ton produit sera amélioré, corrigé de manière importante pendant la garantie ? À part changer des pièces défectueuses, personnellement je ne vois pas.
Le soucis est souvent extérieur, de part les mises à jour de sécurité ou fonctionnelles. Tu ne peux le reprocher aux constructeurs. Ils ne sont pas parfaits, mais ils ne sont pas responsables de tout les soucis qu'on rencontre actuellement. De plus, une partie des soucis pour les mises à jour viennent aussi de la difficulté de suivre et de pousser son travail dans le noyau par exemple faute d'API stable. Comment veux-tu contraindre légalement un fondeur comme Qualcomm de tout mettre dans le noyau officiel ? Ou comment contraindre légalement Linux d'être assez stable dans le temps en interne pour rendre ce genre de travaux plus simples et abordables économiquement ?
Ce sont vraiment des questions délicates, je bosse de l'embarqué, je suis confronté à ces questions régulièrement dans différents contextes, et il n'y a pas de solution universelle à ce jour à tout ceci pour que tout le monde soit content.
[^] # Re: Bordel ?
Posté par Guillaume Smet (site web personnel) . Évalué à 0.
Le téléphone, oui. Le logiciel qui le fait tourner bof, comme tu le soulignes.
Après, pour le téléphone, tu as quand même le souci des performances. Faire tourner un OS de + 5 ans sur un ancien téléphone, ce n'est pas si simple. Avoir des backports des problèmes de sécurité serait quand même une bonne idée.
Typiquement, je serai curieux de voir le nombre de téléphones qui vont obtenir des mises à jour suite aux failles dont on parle là.
Une solution existe : faire moins de modèles avec moins de combinaisons de matériels possibles et c'est tout de suite plus facile de les supporter plus longtemps. Eviter les surcouches d'interfaces spécifiques qui ne seront pas maintenues…
Et même comme ça, typiquement, sur iPhone, tu ne peux pas garder une ancienne version d'iOS encore maintenue. Tu mets forcément à jour vers la majeure suivante (alors que tu ne le souhaites pas forcément).
Après, le souci est quand même que les gens n'ont pas l'air de trop s'en plaindre. Je suppose que ça attendra la première grosse faille/gros virus pour que les gens s'en inquiètent.
[^] # Re: Bordel ?
Posté par Renault (site web personnel) . Évalué à 6.
Question de définition.
La notion de garantie, dans le droit, n'implique pas que le logiciel doit évoluer au cours du temps pour corriger tous les défauts logiciels que l'on peut identifier.
Par exemple le réseau 2G et 3G sont d'un point de vue sécurité des horreurs. Mais ils sont conservés pour des raisons d’interopérabilité. On doit faire quoi, attaquer les opérateurs et les constructeurs de les maintenir ? Un tel geste pourtant serait qualifié d'obsolescence programmée (ce qui serait ridicule mais passons).
Globalement ce débat c'est la quadrature du cercle, nous voulons un système fiable, à jour, pas cher, qui dure dans le temps et puisse faire un maximum de choses dont des trucs non existants à l'époque de la sortie du téléphone. Le tout sans faille de sécurités et de bogues avec un maximum de garanties X années après la sortie du périphérique. Ce n'est pas possible, soit tu auras un produit cher (globalement Samsung, Apple et Google ont un bon suivi durant la période des 2 ans de leur produit, mais sont souvent chers), ou alors tu vas devoir concéder un peu sur le reste. Et pas tout le monde est d'accord sur la question, beaucoup de gens préfèreront un téléphone troué mais pas cher. Suffit d'en parler dans son entourage non technicien pour comprendre que les mises à jour ne sont clairement pas une priorité.
Ton téléphone, si tu ne le mets pas à jour pendant les 5 ans, il tournera comme au premier jour ou presque. C'est ça que la garantie légale t'offre et dans l'ensemble c'est assez respecté. Toi tu veux plus, tu veux une maintenance dans le temps ce qui va au delà de la notion de garantie.
Personnellement les produits habituels que j'achète dans le commerce, je dois payer pour le faire évoluer ou le maintenir à niveau sauf défaut rendant mon produit inopérant. Mais en général, si je n'applique pas la mise à jour du constructeur, le produit fonctionne très bien, je m'expose à des fuites de données ou à certaines attaques mais le produit restera fonctionnel comme lors de l'achat. Et en général les constructeurs (automobiles par exemple) ne font des rappels sur les produits que pour les problèmes mettant en dangers la vie humaine ou ayant un impact très important. Pour un téléphone, c'est délicat à utiliser cet argument.
Facile à dire.
Un OS complet, ce sont des tonnes de composants que tu dois faire interagir. Toutes ces briques ne sont pas maintenues dans le temps par leur développeurs originaux, et parfois passer à la version suivante n'est pas possible (besoin de changer de versions pour d'autres produits, pertes fonctionnelles, etc.). Tu peux te retrouver à tout maintenir toi même et à tout backporter. Ce travail est énorme et n'est pas gratuit.
Honnêtement, maintenir l'OS complet d'un téléphone sérieusement (donc gens compétents et matériels à la hauteur et qui font un travail de qualité), cela peut vite revenir à plusieurs millions d'euros par an et par modèle. Pour des téléphones bas / milieu de gammes, c'est impossible à tenir sans une hausse de prix significative.
Je n'ai rien contre cela, je pense même qu'on va se diriger à terme vers une maintenance des produits via un système d'abonnement pour régler la question. Mais ce que tu souhaites ne ferait pas le bonheur de tous les clients, loin de là.
D'autant qu'on parle d'un domaine où les gens changent de produit spontanément régulièrement, beaucoup changer d'iPhone ou autre téléphone haut de gamme chaque année voire tous les deux ans pour avoir le dernier même si l'ancien fonctionne très bien pour eux. Maintenir en vie l'OS sur une longue durée, cela n'intéresse donc pas tout le monde. Et je pense que ceux que cela intéresse (à juste titre) devront le payer d'une façon ou d'une autre (appareil plus cher à l'achat, ou par abonnement).
C'est une solution. Je pense que beaucoup de constructeurs pourraient avantageusement simplifier leur gamme.
Mais bon, tu oublies que les réglementations ne sont pas mondiales, par exemple sur les fréquences radio. Du coup il te faut souvent des firmware différents voire des composants différents suivant le continent. Cela fragmente forcément le développement et la maintenance pour seulement produire un modèle.
Tu oublies aussi des raisons commerciales. Les constructeurs doivent se démarquer les uns des autres. Du coup forcément il faut produire différents modèles, et développer sa couche logicielle propre pour ne pas trop ressembler aux voisins. Et c'est bénéfique pour les consommateurs aussi, j'en connais qui ne jurent que par l'interface Android de Samsung, d'autres par celle native de Google, etc. Tous les goûts sont dans la nature et l'interface Android native ne convient pas à tous, tout comme iOS n'a pas convaincu tout le monde non plus. Difficile de leur reprocher de vouloir faire ça, même si certains abusent sans doute de la situation.
Pour la question d'Android en tout cas, je dirais que les opérateurs ne devraient pas être dans la boucle. Ça ne sert à rien (ils n'installent que des applications, ils ne touchent pas à l'interface) et ce n'est pas leur boulot. Ça éliminerait un obstacle pour diffuser les mises à jour.
C'est un soucis souvent oublié : le gros des clients s'en foutent et tant que cela sera le cas, la question ne bougera pas. Suffit de voir les réticences à quitter XP malgré les mises en garde de Microsoft lors de la fin de la maintenance. Beaucoup l'utilisent après encore. Personnellement, à part mon entourage informaticien, personne ne se préoccupe de la maintenance de l'OS de son téléphone. Les rares qui ont un avis dessus est même négatif (cela ralentit mon téléphone, ajoute des bogues, etc.). On est loin du client qui souhaite une mise à jour dans la durée. Et si c'était le cas, beaucoup de constructeurs feraient un effort là dessus.
[^] # Re: Bordel ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
On aurait un boot un peu standard et un système de reconnaissance du matériel aussi sur ARM (type BIOS ou équivalent) qu'on pourrait envisager bien plus facilement de basculer sur des OS alternatifs. Il me semble qu'ARM a amélioré les choses ces dernières années mais si cela ne bouge pas plus, le jour ou Intel (là ils sont bien occupés par autre chose) fait une puce x86 aussi puissante et qui consomme moins, il aura du mal à se maintenir…
[^] # Re: Bordel ?
Posté par Renault (site web personnel) . Évalué à 4.
Cela ne fait pas tout.
Pour moi l'OS alternatif n'est qu'un pis aller, je ne trouve pas que le fait qu'on puisse installer un Linux sur une machine avec Windows rende le tout au niveau garantie comme acceptable. Car la quasi totalité des utilisateurs vont conserver l'OS d'origine (éventuellement à jour mais cela en restera là).
Ce que tu cites règle qu'une partie des soucis avec nos téléphones. Et certains problèmes resteront vraisemblablement insolubles tout comme pour nos ordinateurs.
Car un téléphone c'est quand même un gros travail d'intégration logicielle et matérielle. Typiquement si tu veux un bon rendu des photos, le pilote du capteurs bas niveau doit être fait aux petits oignons et l'application qui l'exploitera utilisera bon nombres d'informations du capteur pour améliorer le rendu. Il ne suffit pas juste d'un pilote générique avec un logiciel standard pour avoir un rendu aussi bon que celui vendu par le constructeur. Et c'est ça pour de nombreux composants.
Tu peux voir ce phénomène sur PC aussi, où l'autonomie et certaines fonctionnalités ne sont disponibles que sous Windows, faute d'un support suffisant ailleurs grâce au travail fourni par le constructeur lui même.
L'autre problème persistera toujours : les logiciels grossissent et c'est un phénomène naturel. Nos machines devenant plus puissantes, ne pas l'exploiter serait un gâchis. Comment garantir donc que l'usage d'une application ou la consultation d'un site Web donné soit possible dans le futur avec la même machine ? Le garantir aurait un coût énormes car il faudrait potentiellement maintenir plusieurs versions en parallèle. À part changer de logiciels pour utiliser des alternatives moins gourmandes ou réduire la voilure dans ses usages, il n'y a pas beaucoup de solutions.
Ce phénomène existe sur PC, avec le temps à usage constant les ralentissements apparaissent. J'ai un ordinateur de 6 ans d'âge, sans changer d'usage quotidien ce n'est clairement pas la même réactivité et le matériel n'est pas en cause. Tous les logiciels ont pris de l'embonpoint et pour de bonnes raisons (il y a beaucoup de nouvelles fonctionnalités, ou la qualité du contenu visionné est plus haute en moyenne aussi). Que j'utilise Linux, Windows sur un téléphone ou un PC n'a qu'un impact marginal sur la question.
Il faut réaliser tout cela, tous ces impacts. Blâmer uniquement le constructeur de votre téléphone est une erreur, le problème vient de l'ensemble des acteurs (du fondeur des différentes puces, aux constructeurs, aux développeurs de toutes les applications et aux utilisateurs eux mêmes) et il est difficile de concilier tout le monde (d'autant que tous les développeurs et tous les utilisateurs n'ont pas les mêmes attentes).
La situation n'ira probablement mieux que le jour où les performances stagneront, pour des raisons physiques ou économiques. D'ailleurs depuis le ralentissement de l'augmentation des performances de téléphones (qui a été frénétique au début des années 2010) la situation semble s'améliorer sur ce point, un téléphone bas ou milieu de gamme est capable de tenir de plus en plus longtemps.
[^] # Re: Bordel ?
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 3.
À noter qu'il y a eu une nouvelle version de Firefox sortie aujourd'hui pour limiter le risque : https://www.mozilla.org/en-US/firefox/57.0.4/releasenotes/
[^] # Re: Bordel ?
Posté par patrick_g (site web personnel) . Évalué à -3. Dernière modification le 04 janvier 2018 à 13:41.
En même temps c'est aussi aux utilisateurs de faire les bons choix dans leur vie numérique.
J'ai un smartphone Nexus 5X et je vais donc recevoir dans les prochains jours le correctif de janvier de Google : je serai protégé.
J'ai un laptop sous Arch et je vais donc recevoir dans les prochains jours le noyau 4.14.11 qui contient KPTI : je serai protégé.
C'est sûr que si le user a un Windows pirate qui ne reçoit aucune maj et un vieux android qui ne reçoit aucune maj ben il est dans la merde : mais c'est en grande partie la faute du user !
[^] # Re: Bordel ?
Posté par mahikeulbody . Évalué à 8. Dernière modification le 04 janvier 2018 à 13:41.
Il est fort probable que beaucoup de smartphones avec un Android pas vieux (moins de deux ans) ne recevront pas de mises à jour pour corriger ce problème. Ce sera aussi la faute du user parce qu'il n'avait qu'à acheter un Nexus ?
[^] # Re: Bordel ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Je dirais que la faute est partagée. C'est un scandale que les compagnies ne mettent pas à disposition les patchs de sécurité pour leurs produits…mais le user doit également se renseigner un minimum avant d'acheter. Il y a d'innombrables articles qui informent les gens au sujet des compagnies qui maintiennent correctement leurs produits et celles qui ne font rien. Dire que le user n'y est pour rien alors qu'il achète comme un somnambule c'est un peu gros.
[^] # Re: Bordel ?
Posté par ff9097 . Évalué à 8. Dernière modification le 04 janvier 2018 à 15:22.
Les gens sont dépassés à ce niveau. Pour quelqu'un qui s'y connait un peu, c'est relativement facile. Après, est-ce que ça doit devenir le critère d'achat n°1 ou n°5 ? Il y en a tellement. Pour le Nexus 5X, je me souviens très bien. Très cher à sa sortie par rapport à d'autres. Évidemment aujourd'hui on pourrait dire que c'était un bon choix mais il y a 2 ans c'était moins évident. Mettre 100/150 € de plus pour ce critère c'est pas simple
[^] # Re: Bordel ?
Posté par ckyl . Évalué à 3.
Effectivement. L'autre solution c'est de miser sur les modèles qui ont historiquement un bon support LineageOS (tu ne peux jamais savoir au moment de l'achat) et ton téléphone sera mort avant que tu n'ai plus de mises à jour. Mais c'est pas forcément très grand publique :(
Avec cette stratégie tu as le beurre (MAJ) et l'argent du beurre (un moto G c'est donné)
[^] # Re: Bordel ?
Posté par mahikeulbody . Évalué à 2. Dernière modification le 04 janvier 2018 à 18:02.
@patrick_g : Ton argument tient (un peu) si Google produit une mise à jour pour un truc un peu plus ancien comme la Nexus 7 par exemple. Est-ce que cela sera le cas ?
[^] # Re: Bordel ?
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Il faut arrêter de rêver. Voir mon post plus haut sur une expérience en Asie centrale. Si on veut protéger la planète, on ne peut pas dire que l'acheteur doit juste se renseigner. Cela ne fonctionne tout simplement pas !
Si on veut passer des 5 ou 10% d'acheteur qui achètent en pensant développement durable à 90%, il faut contraindre plus les choses avec des critères plus sévères. Le juste : les gens sont intelligents et vont donc faire le bon choix ne marche pas, en tout cas, je n'y crois pas sur ce cas là. Les prix bas sont trop irrésistibles pour une majorité d'entre nous !
[^] # Re: Bordel ?
Posté par windu.2b . Évalué à 5.
Tout à fait. C'est, dans un tout autre registre, ce qui a été fait avec la TIPP (devenue TICPE, depuis) après le choc pétrolier. Elle a été considérablement augmentée !
À l'époque, ça n'était pas pour des raisons écologiques, mais pour limiter la consommation (donc l'importation) de carburants. En l'augmentant, on a dit aux automobilistes "Si j'étais toi, je m'achèterais une voiture qui consomme moins…". Et c'est ce que les automobilistes ont fait, forçant ainsi les constructeurs automobiles à proposer des modèles moins gourmands. Il n'y a qu'à comparer les consommations des voitures en France, avec celles des voitures aux États-Unis, pour s'en rendre compte.
[^] # Re: Bordel ?
Posté par Olivier Serve (site web personnel) . Évalué à 9.
J'ai un Nexus 5, il n'y a plus de mises à jour depuis Octobre 2016. J'avais pourtant choisi ce modèle précisément pour avoir plus de suivi. Et il fonctionne encore parfaitement bien.
Comme quoi, il ne suffit pas de faire attention à l'achat…
[^] # Re: Bordel ?
Posté par oinkoink_daotter . Évalué à 2.
Le Nexus 5 a eu 3 ans de support et deux upgrade majeurs d'android. C'est pas si mal pour un téléphone android.
[^] # Re: Bordel ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 5.
Ce n'est pas si mal, et je suis dans un cas semblable avec un Sony Z1, n’empêche:
- Les 3 ans de support (chez les bons) sont calculés depuis la sortie du modèle, et non de l'achat. Combien de support pour celui qui achète neuf en fin de vie commerciale du produit?
- Une fois les 3 ans écoulés, il est possible de changer la batterie pour 20 à 50 euros ce qui remet le tel à neuf d'un point de vue fonctionnement et stabilité.
Mais Avec une industrie un peu plus écologique, il serait possible de racheter 2 à 3 ans de support à Google/Sony/watever… Parce que franchement, un tel équipé d'un Snapdragon 8xx et de 2 ou 3Go de RAM, toujours au niveau et supérieur au milieu de gamme actuel, se voir finir à poubelle pour une absence de MAJ logicielle est franchement un beau gâchis.
[^] # Re: Bordel ?
Posté par oinkoink_daotter . Évalué à 2.
Ce n'est, effectivement, pas du tout le modèle économique de l'industrie, particulièrement chez les constructeurs de tel Android. J'ai beau chercher, je n'en ai pas trouvé qui fassent comme la pomme des téléphones en assez petit nombre et supportés relativement longtemps (quoi qu'on en dise sur la polémique autour des batteries). Après y a les ROM Android alternatives, qui posent d'autres problèmes.
[^] # Téléphones…
Posté par Arthur Accroc . Évalué à 3.
Voilà, c’est pour ça que je garde mon vieux feature phone (acheté d’occasion en 2011) : les smart phones sont jetables. Trois ans seulement, c’est lamentable (pour le client et encore plus du point du vue écologique), surtout si ce n’est que pour les appareils les mieux supportés.
En plus, pour avoir les fonctionnalités auxquelles je tiens, je vais être assez ennuyé :
– un appareil photo pas trop mauvais → ça élimine les téléphones pas smart actuels ;
– pouvoir récupérer facilement (sans passer par iTunes) les photos et mes contacts sur ordinateur → ça élimine les iPhones ;
– sans mouchard, notamment que les numéros qui m’appellent ne fuitent pas chez Google (ou autres) → ça élimine Android…
Je suppose que la solution la plus simple serait LineageOS sur un téléphone bien choisi et peut-être que ça permettrait aussi une durée de vie un peu moins ridicule, mais en fait, je ne suis pas tellement pressé de devoir administrer mon téléphone, je vais donc essayer de faire encore durer celui que j’ai.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Téléphones…
Posté par oinkoink_daotter . Évalué à 3.
Alors :
Conclusion, sauf à être vraiment branché sur l'utilisation d'un câble, ça doit pouvoir se gérer. Y a d'autres problèmes avec iOS (notamment tout ce qui tourne avec le compte Apple), mais pas ceux là.
[^] # Re: Téléphones…
Posté par ff9097 . Évalué à 2.
Il ne faut plus iTunes ?
[^] # Re: Téléphones…
Posté par oinkoink_daotter . Évalué à 3.
Pour les photos, non.
[^] # Re: Bordel ?
Posté par Maclag . Évalué à 8.
Et toi, quand tu achètes à manger, tu sais bien évidemment comment les plantes sont cultivées et si elles peuvent contenir des résidus d'engrais, pesticides et autres, et l'impact potentiel de chacun d'entre eux?
Non? Tu achètes comme un somnambule alors?
L'idée que le grand public doit être expert dans "son" domaine de prédilection est quasiment universelle. L'informatique touche tout le monde… tout comme l'agriculture, l'électronique, la construction de bâtiment, l'ingénierie civile, l'énergie, etc.
Non, tu ne peux absolument pas exiger du consommateur qu'il soit éclairé en sécurité informatique, ce qui veut dire au minimum ici:
-qu'il comprenne bien ce qu'est une faille de sécurité et ses conséquences
-qu'il comprenne les mises à jour (combien de fois ai-je entendu "je ne laisse jamais mon smartphone faire ses mises à jour, il marche bien, je ne veux pas introduire un problème!")
-qu'il se tienne informé des failles de sécurité (ben oui, c'est pas tout de savoir ce que c'est, il faut faire de la veille!)
-et donc qu'il soit capable de détecter le bullshit des constructeurs s'ils lui expliquent que "t'inquiète, tout va bien!"
On est en 2017, et les informaticiens pensent toujours que l'informatique est réservée aux experts!
C'est pour ça qu'Apple cartonne: ils vendent l'idée que leurs utilisateurs n'ont pas besoin d'être des experts techniques.
[^] # Re: Bordel ?
Posté par Thomas Douillard . Évalué à 4.
Ça sera plus simple de faire passer le message quand les mises à jour n’introduiront pas de régression en perf par course à la fonctionnalité et optimisation pour les nouveaux modèles, naturellement.
[^] # Re: Bordel ?
Posté par voxdemonix . Évalué à 3.
Quand les mises à jours ne sont tout simplement pas bloquées.
[^] # Arch
Posté par Arthur Accroc . Évalué à 3.
Dès aujourd’hui si tu veux.
J’ai lancé une mise à jour, le noyau 4.14.11 est déjà dans les dépôts.
Et il prend bien en compte la faille :
Cela dit, ça te protège de MeltDown. Il ne semble y avoir aucune solution en vue contre Spectre (à part peut-être ressortir un Pentium 1…). L’année commence bien !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Arch
Posté par patrick_g (site web personnel) . Évalué à 9.
Si, si apparemment Google a des patchs sous le coude pour GCC et LLVM afin de contrer Spectre : https://support.google.com/faqs/answer/7625886
[^] # Failles totalement couvertes ou pas ?
Posté par Arthur Accroc . Évalué à 3.
Si je suis bien, ça implique pour les distributions, au minimum, de mettre à jour les paquets des compilateurs et de recompiler en priorité tous les logiciels susceptibles d’exécuter du code tiers (langages interprétés, navigateurs…).
Par contre, il y a un cas qui ne me semble pas couvert : qu’est-ce qui empêchera l’utilisateur (légitime ou qui a réussi à pirater un compte) d’un serveur accessible en ssh ou d’un VPS d’utiliser un code malveillant compilé par lui-même avec un compilateur non patché ?
S’il n’y a pas de solution à ce problème, ça veut quand même dire que tous les serveurs (ou au moins leurs processeurs) laissant plusieurs utilisateurs lancer librement des exécutables devront être changés avec de futurs processeurs non vulnérables.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Failles totalement couvertes ou pas ?
Posté par Pinaraf . Évalué à 2.
Les patchs protègent le binaire compilé heureusement, ce n'est pas des patchs à appliquer sur le binaire «assaillant».
[^] # Re: Failles totalement couvertes ou pas ?
Posté par Arthur Accroc . Évalué à 4.
En fait, la question qui se pose et dont la réponse ne m’est pas apparue clairement dans les articles que j’ai lus, c’est : la faille Spectre permet-elle d’accéder uniquement à la mémoire du processus courant ou plus largement à d’autres zones de mémoire ?
C’est probablement évident pour quelqu’un qui connaît bien le fonctionnement actuel de la MMU, mais je ne le connais pas assez bien pour que ça le soit pour moi.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Failles totalement couvertes ou pas ?
Posté par Pinaraf . Évalué à 3.
Spectre c'est processus courant. Ou un voisin dans lequel t'arrives à influencer l'exécution du code. C'est pas un accès ouvert à toute la mémoire. Pas comme meltdown qui permet d'accéder à la mémoire du noyau…
[^] # Re: Arch
Posté par patrick_g (site web personnel) . Évalué à 3.
Pour la nouvelle version du noyau effectivement c'est déjà dispo dans les dépôts Arch.
Après une maj :
[patrick@laptop]: ~>$ uname -aLinux laptop 4.14.11-1-ARCH #1 SMP PREEMPT Wed Jan 3 07:02:42 UTC 2018 x86_64 GNU/Linux[patrick@laptop]: ~>$ grep "model name" /proc/cpuinfo | uniqmodel name : Intel(R) Core(TM) i7-3540M CPU @ 3.00GHz[patrick@laptop]: ~>$ grep bugs /proc/cpuinfo | uniqbugs : cpu_insecure[^] # CentOS 7, Ubuntu 16.04 LTS
Posté par Arthur Accroc . Évalué à 2.
Sous CentOS 7, un noyau tout frais d’hier :
Difficile d’être sûr que Meltdown soit prise en charge, vu qu’il n’y a pas de ligne bugs dans /proc/cpuinfo (c’est un noyau relativement ancien…), mais ce serait quand même une curieuse coïncidence qu’ils aient sorti un nouveau noyau juste maintenant sans ce correctif.
Sous Ubuntu 16.04 LTS… rien pour l’instant :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: CentOS 7, Ubuntu 16.04 LTS
Posté par atarakt . Évalué à 2.
Pour centos, tu as la bonne version du kernel, il y a aussi 2 autres fixes:
https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html
https://lists.centos.org/pipermail/centos-announce/2018-January/022697.html
https://lists.centos.org/pipermail/centos-announce/2018-January/022698.html
[^] # Re: CentOS 7, Ubuntu 16.04 LTS
Posté par patrick_g (site web personnel) . Évalué à 6.
Pour Ubuntu ils indiquent qu'ils ont été pris de cours par la divulgation avant la date prévue du 9 janvier :
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown
The original coordinated disclosure date was planned for January 9 and we have been driving toward that date to release fixes. Due to the early disclosure, we are trying to accelerate the release, but we don't yet have an earlier ETA when the updates will be released.
[^] # Re: Bordel ?
Posté par Anonyme . Évalué à 4.
Oui, mais en attendant le Nexus 5X a un gros problème matériel qui le fait redémarrer en boucle : https://duckduckgo.com/?q=nexus+5x+bootloop.
Pour les conseils sur les choix de vie numérique, on repassera.
# Incroyable !
Posté par Leniwce . Évalué à -10. Dernière modification le 04 janvier 2018 à 13:28.
Cette histoire et ce patch démontre aujourd'hui le niveau d'infection du noyau linux par un groupe d'industriels. Franchement c'est quoi ce patch de merde ? Pourquoi AMD doit-il en subir les conséquences négatives alors que des développeurs ne cessent de communiquer a ce sujet ?
Ca veut dire quoi cette facon d'agir ! Faudra t-il renommer le noyau linux en noyau intel ? Bande de vendus et
FUCK YOU LINUS
attention chérie ça va moinsser
[^] # Re: Incroyable !
Posté par patrick_g (site web personnel) . Évalué à 10.
Faut se calmer, c'est pas bon pour ta tension cet énervement :-)
Le patch qui désactive KPTI pour les processeurs AMD a été accepté par Linus : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce
Le commentaire du patch : "Exclude AMD from the PTI enforcement. Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead".
[^] # Re: Incroyable !
Posté par Leniwce . Évalué à -10. Dernière modification le 04 janvier 2018 à 15:47.
Et il faudrait peut-etre aussi en plus le remercier !
Oui bonhomme, AMD "is so confident" et il en revient pas ! On voit pour qui il tourne le Linus.
Dans peu de temps le suprême annoncera a sa communauté qu'il passe chez AMD, lol :)
attention chérie ça va moinsser
[^] # Re: Incroyable !
Posté par Martin Peres (site web personnel) . Évalué à 3.
Tu es en train de lire le message de Thomas Gleixner, pas Linus. Linus a simplement accepté de fusionner le code.
[^] # Re: Incroyable !
Posté par Maclag . Évalué à 3.
Euh… et toi, tu bosses pour AMD?
Nan parce que dans le doute, moi je préfère que ça ralentisse mon ordi pour quelques semaines le temps qu'ils confirment qu'ils ne sont pas concernés plutôt que de me prendre une attaque violente d'ici là.
Et puis, Linus a adopté le patch Intel puis le patch pour assurer que ça n'impacte pas AMD.
Donc il doit être effectivement vendu… à tous les industriels… ce qui veut dire… qu'il est plutôt neutre à la fin!
[^] # Re: Incroyable !
Posté par KiKouN . Évalué à 2. Dernière modification le 05 janvier 2018 à 16:05.
Seul problème, c'est que s'ils laissent les AMDs bridés et qu'il n'y a pas de raison, personne ne va faire la mise à jour pour débridés les AMDs à part quelques fanboys et admin fou de perf. Alors que s'ils sont pas bridés et que l'on découvre que la faille marche aussi, il y aura une mise à jour de sécurité, tout le monde sera prévenu et tout le monde mettra à jour. Fin les possesseurs d'AMD du moins.
[^] # Re: Incroyable !
Posté par Maclag . Évalué à 2.
Ce que tu essaies de dire, c'est quoi?
Je ne comprends pas où tu veux en venir!
[^] # Re: Incroyable !
Posté par KiKouN . Évalué à 3.
Je ne me rappelle pas avoir dit qu'amd se fout des perfs ni parler de notion de sécu et encore moins de la politique d'intégration d'un patch dans le kernel. Peut-être que mon css me cache cela.
Juste qu'il peut être plus judicieux pour amd de patcher leurs processeurs que si cette faille est prouvée sur leurs processeurs. Pas avant. C'est plus une question d'expérience utilisateur (surtout qu'elle remonte seulement) que de sécurité à tout prix.
Amd joue peut être avec le feu. Peut être ont-ils autre chose sous la main. C'est à eux de savoir quelle est la bonne politique pour leur société.
# Ca sent pas bon chez IBM aussi
Posté par Dabowl_75 . Évalué à 6.
Même si on parle de "potential impact", c'est que ça doit puer très fort quand même…
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
On y apprend que non seulement il y aura un patch pour AIX et iSeries (anciennement AS400), seulement disponible le 12 février (LOL!), mais également une mise à jour du firmware/microcode pour toutes les dernières générations de Power.
Jusqu'alors, un des avantages compétitifs avancé par IBM était que le couple Power / PowerVM était davantage sécurisé que l'offre VMWare / x86, surtout quand on regarde le nombre de faille découvertes.
C'est tout qui vole en éclat.
Comme le suggère certains sur la toile, se reconvertir en guide de haute montagne ou en éleveur de chèvres gagne en intérêt.
[^] # Re: Ca sent pas bon chez IBM aussi
Posté par Anonyme . Évalué à -1.
La faille Spectre touche la totalité des processeurs out-of-order donc rien ne vole en éclat plus qu'ailleurs.
[^] # Re: Ca sent pas bon chez IBM aussi
Posté par claudex . Évalué à 3.
« 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: Ca sent pas bon chez IBM aussi
Posté par Dabowl_75 . Évalué à -1.
Tu réponds un peu à côté
[^] # Re: Ca sent pas bon chez IBM aussi
Posté par Anonyme . Évalué à -2.
Non. Tu prends une faille qui touche tous les fabricants et là dessus tu ironises sur le marketing d'IBM. Je vois pas en quoi ton propos est constructif.
[^] # Re: Ca sent pas bon chez IBM aussi
Posté par Dabowl_75 . Évalué à 3.
Mon propos ne concerne pas uniquement le CPU, mais le couplage CPU / Hyperviseur.
Comme un lecteur a tenté de te le rappeler d'ailleurs.
Jusqu'alors, le marketing de même que les faits, donnaient un peu raison à IBM.
vmware : 854 results :
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=vmware
powervm : 0 result
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=powervm
Alors oui la surface d'exposition n'est pas la même, oui c'est du discours marketing blablabla.
Le fait que ça vole en éclat avec ces failles, et pour tout le monde en même temps, remet sérieusement les pendules à l'heure.
Si je t'ai fait connaitre ou découvrir powervm, j'en suis ravi.
[^] # Re: Ca sent pas bon chez IBM aussi
Posté par Anonyme . Évalué à 3.
"tenter" le mot est fort. C'est qu'une citation.
D'ailleurs ta réponse était à peine meilleure. Mais merci d'avoir ensuite explicité.
Pas tout à fait. Il reste les failles de l'Intel ME (on en a eu une belle l'année dernière) et celles à prévoir du côté du PSP d'AMD qui repose sur Trustzone (qui a déjà été exploité). Power garde l'avantage d'avoir moins de surface d'attaque potentielle et ce indépendamment de l'hyperviseur.
J'ai aussi découvert IBM i, je ne connaissais que AIX. :)
[^] # Re: Ca sent pas bon chez IBM aussi
Posté par Pinaraf . Évalué à 5.
Une faille de type Remote Code Execution sur le PSP est passée dans mes flux RSS ce week-end…
Je vais reprendre des anti-dépresseurs…
# Quid des nouveaux processeurs annoncés chez les uns ou les autres ?
Posté par mahikeulbody . Évalué à 2.
Ou, en posant la question autrement, dans combien de temps peut-on espérer que les nouveaux processeurs à venir ne soient plus vulnérables à ces deux failles (hors palliatifs logiciel) ? Est-ce une remise en cause profonde de l'architecture ou bien un correctif, certes matériel, mais "facile" à effectuer sur les prochaines versions de processeurs ?
[^] # Re: Quid des nouveaux processeurs annoncés chez les uns ou les autres ?
Posté par Renault (site web personnel) . Évalué à 3.
Tout dépend je pense depuis quand la faille a été clairement identifié par chaque fondeur, de l'importance du changement à faire (à priori cela ne devrait pas être si délicat) et des éventuels effets de bords.
Car n'oublions pas, peut être que le problème identifié est présent dans d'autres parties du CPU (ou GPU) qui n'ont pas été encore révélées. Il faudra sans doute de longs audits internes pour colmater l'ensemble.
Comme concevoir un processeur prend du temps (plus d'un an pour une nouvelle génération) et qu'un grand nombre de tests sera nécessaire pour s'assurer qu'il n'y aura pas de grands effets de bords pour les applications actuelles. Il me semble peu probable que quelque chose sorte en 2018 des usines. Faut compter je pense sur 2019 / 2020 pour avoir une généralisation des différentes corrections au sein de tous les produits de tous les fondeurs impactés.
[^] # Re: Quid des nouveaux processeurs annoncés chez les uns ou les autres ?
Posté par Anonyme . Évalué à 1.
C'est très optimiste, les fabricants de processeurs ont plutôt des projets qui prennent quatre à cinq ans de recherche et développement.
Si on parle de Meltdown, Intel proposera certainement une correction hardware d'ici deux ans pour mitiger la baisse de performance et se mettre au même niveau que les autres. C'est ça la correction "facile" mais ça n'est que la surface.
Pour Spectre, c'est toute la mécanique d'exécution spéculative et de prédiction de branchement qui est à revoir donc on touche vraiment aux fondements des processeurs et là ce sera plutôt quatre ans (donc plutôt Zen 2 ou 3 que le prochain Zen+ chez AMD). De plus, c'est un nouveau vecteur d'attaque entier à explorer donc on va certainement trouver d'autres choses.
[^] # Re: Quid des nouveaux processeurs annoncés chez les uns ou les autres ?
Posté par Renault (site web personnel) . Évalué à 3.
2020 c'est dans deux ans (voire trois si on considère fin 2020), c'est un objectif qui est réaliste. Et Spectre apparemment est connu des fondeurs depuis plusieurs mois (voire une demi-année).
Mouais, je n'en suis pas si sûr.
En admettant que Spectre ne génère pas de petits (ce qui dans ce cas demandera sans doute du temps pour immuniser toute la puce), je ne crois pas que cela soit si fondamental.
Faire un nouveau processeur prend du temps, mais ce n'est pas la micro-architecture qui prend tout ce temps. Car dedans tu as la conception de la finesse de gravure, des nouvelles instructions à fournir, ajouter des nouveaux standards qui peuvent être complexes (une nouvelle norme DDR, USB ou PCIe cela n'est pas un petit travail à ajouter). Sans compter aussi toute la partie graphique ou encore de la consommation d'énergie où notamment Intel a beaucoup d'efforts à fournir.
Non pas que la question du pipeline et de la mémoire cache ne soit pas importante, mais les 4 ans de R&D pour une génération ne sont pas consacrées à ces questions en général.
Pour l'instant nous ignorons si Spectre est plutôt simple à résoudre d'un point de vue matériel ou non, et si Spectre va induire la découverte d'autres soucis similaires. 2020 ne me semble pas déconnant dans le cas simple ou normal. Ce qui est certains c'est que il ne faut rien attendre en 2018.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.