Renault a écrit 7161 commentaires

Ps : bon, sinon LinuxFr toujours pas dispo en IPv6, ça fait sourire pour des gens sensés être en avance sur les autres, cordonnier mal chaussé :) (après, hébergement gratos et bénévoles, certes)

Il peut être intéressant d'avoir un mot des admins pour expliquer pourquoi ce n'est pas fait, car beaucoup de sites webs et d'autres services ne sont pas compatibles IPv6.

Est-ce que cela demande un gros travail pour eux (et forcément pas prioritaire) ? Peut être que c'est leur hébergeur qui ne le propose pas, du moins pas gracieusement. Ou peut être autre chose (juste une option à activer mais qui n'a pas été fait car pas sensibles à la question). Ou pire, l'hébergeur n'est pas prêt du tout pour ce genre de services.

Cela pourrait donner une explication sur l'absence d'IPv6 sur autant de sites web.

Oui, c'est vrai que la France n'a aucune loi et que personne ne respecte rien c'est bien connu. Les opérateurs sont réputés pour faire vraiment tout ce qu'ils veulent.

Quand même, je veux bien que la France ne soit pas parfaite, que nos opérateurs ne soient pas des divinités, mais bon, à t'écouter c'est vraiment comme si c'était le cas. C'est affligeant.

Mais pour des équipements dit "embarqué", comme c'est surement le cas pour beaucoup de caméras de vidéo surveillance connectées (pas chère) : il est probable qu'elles fonctionnes juste avec des microcontrôleurs sans MMU donc pas de linux ni de *BSD donc pas d'OS avec de pile IPV4+v6 toute faite.

Je travaille dans l'embarqué, je suis conscient de tout cela. Mais à part pour des appareils en réseaux fermés (type un avion), c'est une problématique de plus en plus prise en charge. De moins en moins d'appareils n'ont pas de MMU ou un OS ne gérant par l'IPv6.

Je ne nie pas leur existence à ces engins, mais de là à dire que cela bloque le déploiement de l'IPv6 il ne faut pas abuser. Nombre de pays ont une meilleure pénétration de l'IPv6 que nous sans poser le moindre problème.

L'ARCEP ne peut rien faire au plan mondial, elle peut s'occuper des opérateurs français et encore.

Tu me parles d'État et de plan étatique pour la télévision (donc limité à un État) mais pour l'Internet cela doit être forcément mondial ? Ce n'est pas cohérent.

Je veux dire, l'IPv6 peut se déployer en France via des textes français, la coordination mondiale n'est pas plus nécessaire que sur d'autres sujets. Car sinon je peux te parler des fréquences TV qui ne sont pas uniformes dans le monde entier (donc les constructeurs doivent prendre en compte), ni même les normes de diffusion (typiquement NTSC / PAL / SECAM quand c'était analogique).

Mais on parle d'IPv6 là, pas du mobile.

Des sujets sur lesquels l'État a un pouvoir règlementaire via l'ARCEP entre autre et cela fonctionne plutôt bien.

Mais après, on peut parler du déploiement de l'ADSL ou de la 4G et aller dans des coins très sympathiques, mais dépourvus de la moindre antenne ou du moindre DSLAM. Donc, le «partout» est sans doute un peu trop fort.

Le plan THD doit se finir à l'horizon 2025, dire qu'aujourd'hui il n'est pas fini c'est un peu logique…

Mince, l'ARCEP n'existe pas ! Les opérateurs font vraiment tout ce qu'ils veulent, sans plan.

C'est fou, Orange a obtenu ses fréquences mobiles unilatéralement, sans contraintes, et il n'y absolument aucun plan national (et même européen) pour avoir la THD partout.

Si l'État contrôle plus le domaine télévisuel que les télécoms, cela n'empêche pas que l'État a un pouvoir régulateur fort dans ce domaine aussi. Et j'ai envie de dire, tant mieux que l'ARCEP ne soit pas comme le CSA.

Je crois plutôt que les opérateurs misent sur l'absence de compétences techniques des utilisateurs pour les manipuler avec des chiffres trompeurs. Je ne compte plus le nombre de gens qui ne comprennent pas les données fournies par leurs FAIs.

Ce n'est pas parce l'utilisateur ne comprend pas les chiffres indiqués qu'ils sont trompeurs. Au contraire même, parfois c'est dans son intérêt d'avoir une mesure physique standard qui facilite les comparaisons entre opérateurs et qui évitent justement la tromperie.

Un exemple bien connu : l'énergie où tout repose sur le concept d'un kWh. Unité peu glamour, souvent mal comprise mais qui permet sans problème de comparer les fournisseurs d'énergie et de calculer l'impact d'un appareil électrique sur sa facture.

Perso, quand je souscrit à un réseau, c'est le débit réel du réseau qui m'intéresse. Dans le cas du réseau internet, c'est donc juste le débit à partir d'IP

IP 4 ou 6 ? Ce qui a une incidence non nulle (la taille de l'en-tête n'est pas identique).
Je pense qu'il est délicat d'exprimer justement la taille maximale du tuyau loué en fonction d'une technologie vouée à évoluer. Présenter le chiffre physique comme c'est fait aujourd'hui évite le risque de tromperie car l'un utilise l'IPv6 et l'autre l'IPv4 dans le calcul commercial. Cela permet aussi de comparer l'évolution de la chose dans le temps car indépendant de la technologie employée.

je suis censé être libre d'utiliser du TCP, de l'UDP, ou les autres.
Du coup, penses-tu que la plupart des gens ont conscience du ratio utile des protocoles qu'ils utilisent? Je ne le pense pas.

Justement, c'est là où tu es bancal. Tu dis que les histoires d'en tête protocolaires c'est trop complexe pour l'utilisateur moyen (et je suis d'accord) mais tu veux que l'opérateur te communique un chiffre au niveau de l'IP. C'est trompeur car cela ne prend pas en compte les en-têtes des protocoles au dessus (ce que l'utilisateur ne saura pas mesurer lui même de toute façon, donc au niveau IP il ne gagne rien) mais c'est pire car tu rends ta mesure dépendant d'une technologie. Or l'utilisateur avancé, comme toi, est capable de mesurer facilement l'impact à partir de la valeur commerciale.

Bref, justement, ta proposition va amener de la confusion à l'utilisateur, sans rien lui apporter, tout ça pour t'épargner quelques calculs bateaux.

Je pense, et si je pouvais me tromper ça serait génial, que les gens pensent qu'un fichier de 1Gio, avec une connection de 1Mio/s, ça se télécharge en 1000 secondes, et qu'ils appliquent cette "règle" élémentaire simple à tous leurs débits.

Mais ta solution ne règle pas cette question, car il y a toujours HTTP, TCP et tout à prendre en compte. Que le FAI ne peut pas faire à ta place. Le mieux qui peuvent faire c'est de présenter des calculs du genre combien de temps pour télécharger un film ou des musiques d'une taille donnée. Mais c'est biaisé car lié à la technologie employée (IPv4 vs IPv6, TCP vs UDP, HTTP vs Torrent, etc.).

Alors que je suis quasi sûr que les FAIs regardent eux le débit réel.

Tout à fait, et comme je l'ai expliqué, c'est très bien ainsi. C'est la meilleure solution.

D'ailleurs l'ARCEP (qui fait un boulot colossal et pertinent dans l'ensemble) a un observatoire consacré à ce sujet : https://www.arcep.fr/index.php?id=13169

Cela permet d'avoir une vue d'ensemble de la situation française et de constater que cela évolue bien.

Beaucoup appareils que nous possédons fonctionnent en IPv4 seulement.

Je ne sais pas où tu vis, mais tous les équipements et systèmes vendus dans le commerce aujourd'hui, et depuis de nombreuses années d'ailleurs (à part de rares exceptions ?) sont compatibles IPv6. Même les boxs des FAI.

Le plus gros problème vient bien entendu de la mise à disposition de l'IPv6 par les opérateurs car cela demande un gros chantier en interne. Mais en France la situation se débloque peu à peu. En Belgique l'opérateur national Proximus (qui détient environ 50% du marché fixe) a activé l'IPv6 pour tous, rendant la Belgique numéro 1 en pénétration de la technologie.

Mais si pour le fixe la situation progresse plutôt rapidement ces derniers temps, le mobile est encore à la traîne, je ne connais pas d'opérateurs européens le faisant (ni même dans le monde en fait) et il ne semble pas y avoir des expérimentations en ce sens.

Selon Google, une requête sur 5 se fait en IPv6, ce n'est pas si mal : https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption&tab=ipv6-adoption

Par contre, qui sera le premier opérateur à ne fournir que de l'IPv6 et quand ? Cela risque d'être long d'arriver à ce résultat.

Ça dépend. Quand on dit que ton réseau est 1 Gbit/s cela prend en compte les en-têtes Ethernet, IP, TCP, HTTP, etc. Tout ceci est déjà pris en compte. C'est-à-dire qu'au niveau applicatif le maximum théorique d'une telle connexion est de 1 Gbit/s moins la taille de toutes les entêtes de la pile réseau employée par requête multipliée par le nombre de requêtes dans la seconde.

Donc je ne vois pas où tu veux en venir.

C'est plus du tout pareil que :

Je parlais de la représentation accessible aux OS. Que l'UEFI travaille sur ces données ou non est une question totalement indépendante.

Le problème c'est que ce genre de chose ne sert à rien, ça ajoute beaucoup de complexité pour rien.

La méthode simple (qui marche souvent, à savoir faire UTC + fuseau horaire + décalage d'heure d'été) ne prend que quelques lignes et apparemment quelques octets seulement pour sauvegarder ces infos. Très compliqué en effet.

La véritable difficulté c'est de faire une fonctionnalité parfaite, mais apparemment personne ne s'en préoccupe outre mesure. Et sans mises à jour régulière c'est voué à l'échec.

ça sera 1000x mieux qu'une interface passé au google-translate

Comme beaucoup d'UEFI sont programmés en Asie, en réalité c'est l'anglais qui est une traduction. :-)

Je comprend bien que l'UEFI permet une abstraction qui standardise et fait qu'on peut installer n’importe quel OS sur n’importe quel PC; mais l'UEFI n'as pas besoin d'être un OS pour faire ça.

Honnêtement tu te focalises sur des détails de l'UEFI, c'est quand même assez fou. L'UEFI fait beaucoup de chose bien plus complexes (tout comme le BIOS en son temps) c'est dans l'ordre des choses que ce soient des OS à part entière. D'ailleurs NERF semble les remplacer par du noyau Linux, preuve que cela fait sens.

Tu sais que GRUB, U-boot et tout qui ne sont que des chargeurs de démarrage sont également d'une complexité importante ? Bah oui, initialiser le matériel, gérer des systèmes de fichier, de la cryptographie, du réseau, etc. c'est du gros boulot.

Merci je sais très bien la difficulté de représenter le temps, je suis d'ailleurs en plein dedans.

Mais comme mentionné dans d'autres sujets, parfois il vaut mieux quelque chose qui fonctionne bien pour 90% des cas et dont le problème pour les autres est mineurs que de n'avoir rien du tout.

Et comme cela a été indiqué, l'UEFI peut jouer avec ces données pour en tirer quelque chose (à l'affichage de son menu par exemple). Cela n'en est pas une obligation, et globalement l'OS au dessus est responsable de maintenir l'heure réelle sous-jacente (après tout, c'est lui qui a accès au NTP et à la configuration de l'utilisateur directement).

Comme on peut s'en douter la plupart de ces cas impliquent un programme complexe et surtout des mise à jour régulière, quel intérêt à faire ce genre de chose au niveau de la carte mère ?

La question est : pourquoi pas ? Est-ce grave si la carte mère pour de l'affichage essaye d'afficher une donnée intéressante même si ça peut être faux dans quelques cas ?

Tu vas reprocher à des constructeurs de proposer l'affichage de leur interface UEFI en chinois mais pas en français car tant que toutes les langues ne seront pas dispo ce ne sera pas parfait ? (cas d'une carte mère chez moi, anglais ou mandarin). Je trouve vraiment que tu t'emportes pour pas grand chose dans ce cas-ci.

Et l'UEFI a au moins unifié la politique de manière universelle (car à priori d'autres architectures que l'x86 vont reprendre la spec). Et quelque soit l'OS. Avec les BIOS d’antan, c'était un peu la loterie, suffit de constater les bogues de l'heure quand tu passais de Windows à Linux en dualboot…

Tant qu'on y est pourquoi pas y mettre un OS ? au wait

Quel est le problème ?

Le matériel est devenu un centre de technologie très complexe. Le processeur Intel / AMD / IBM / ARM / autre n'est plus maître à 100% de la machine. Il est guidé par des dizaines de processeurs ou microcontrôleurs avec leur propres logiciels voire mini-OS dedans. Et je ne parle même pas des cartes graphiques qui sont presque des ordinateurs complets à eux seuls. Il est naïf de croire que tu vas retrouver le contrôle de l'ensemble avec ton Linux logé dans le disque dur.

Mais cela a aussi un avantage, comme le processeur principal ne gère pas cela lui même, Linux n'a pas à le faire non plus, et avec la quantité astronomique de combinaison possible, c'est une bonne chose pour la portabilité de nos systèmes et leur fiabilité.

En clair un petit malin peut recuperer l'ensemble de tes donnees si il le souhaite grace a cette magnifique technologie qu'est UEFI.

Tout à fait, de même s'il a inséré une porte dérobée dans ton processeur, le firmware de ton espace de stockage ou le noyau de ton OS.

L'UEFI est un composant parmi d'autres qui a de grandes possibilités sur ta machine, mais heureusement son accès n'est pas aisé, généralisable à grand échelle (l'UEFI d'un constructeur n'est pas compatible avec un autre en terme de code et d'initialisation, seule l'API l'est). Et ce n'est pas le seul dans ce cas.

Le role d'un BIOS c'est juste d'initialiser le hardware et de s'effacer lorsqu'un O/S demarre

C'est un point de vue, mais qui globalement ne colle pas à la réalité.
Même avec l'UEFI, si tu dialoguais directement avec le BIOS tu pouvais jouer à faire des trucs rigolo. Le BIOS sur x86 ne s'est jamais totalement effacé devant l'OS en fait.

Et c'est d'ailleurs un intérêt du BIOS que de fournir une petite abstraction de la machine en dessous pour aider le noyau dans cette tâche. N'oublions pas que c'est en partie cela qui fait que l'ARM est une plaie à gérer car la l'initialisation et la découverte du matériel doit se faire à la main.

C'est secure serieusement ?

Il faut faire attention à distinguer un standard sécurisé et son implémentation qui peut ne pas l'être.

Ce qui soit dis en passant n'est pas un problème. Pourquoi l'UEFI de la carte mère devrait être incapable d'afficher l'heure réelle de chez moi quand j'y vais dedans ? D'autant que ce n'est pas si compliqué avec un OS qui supervise cela au dessus de lui.

Alors là je me demande : le BIOS gère donc tous les fuseaux horaires et changements d'heure !!?? mais pourquoi faire ? C'est pas plutôt à l'OS de gérer ça ? … soit j'ai mal compris : l'UEFI ne calcule pas lui même les changements d'heure mais dispose juste d'un champ "timezone" et d'un champ "DST rules" qui permet à l'OS de le faire ;

C'est ça, en gros l'UEFI permet aux différents OS de gérer l'heure matérielle de la machine proprement de manière univoque.

Cela évite les soucis du passé où Windows et Linux n'interprétait pas le BIOS de la même façon à ce sujet, donnant des heures différentes selon l'OS que tu employait si tu passais de l'un à l'autre.

Je vais déjà essayer d'installer visual code studio sous mon ubuntu.

Visual Code Studio n'est de souvenir qu'un éditeur de texte. Cela ne te sera d'aucune aide pour le faire fonctionner sous Linux.
Cependant le code est en C# (et non en C), tu devrais regarder du côté de mono (ou autre outil .NET pour Linux) pour voir s'il n'est pas possible de le faire tourner sous Linux facilement.

C'est incomplet.

En effet ta Debian n'a pas tous les derniers correctifs concernant le noyau pour ces failles. Mais il en a probablement une partie.

En fait la commande citée repose sur un correctif arrivé plus tard pour décrire en détail ce qui est appliqué ou pas. Mais certains correctifs existaient avant. Mais pas tous.

De plus comme tu n'as pas la dernière version du noyau, tu devras attendre l'application de ces correctifs par Debian ou d'autres développeurs assurant la maintenance du noyau que tu utilises. Cela prend un peu de temps, d'autant que Debian n'est pas du genre à avoir une politique de mise à jour rapide.

Mais, dans ce cas, pourquoi je n'ai pas d'informations précises dans mon /proc/cpuinfo quant au CPU?

Ça y est :

bugs : cpu_meltdown spectre_v1 spectre_v2

Après cela ne signifie pas où en est la correction, mais cela liste les erreurs du matériel. Tu y as accès.

et je doute que la vulnérabilité soit testée par le noyau, à mon avis, c'est juste du bon gros hardcode pas propre, à vérifier

Ce n'est pas sale d'établir une liste du matériel concernée (avec éventuellement des jokers sur les id pour une plage complète). C'est même plus fiable et plus performant qu'un test du noyau à chaque démarrage.

Pour moi, le rôle du kernel n'est pas d'informer sur les failles du hard, mais d'en permettre l'usage (du hard, hein) de manière uniforme sans (trop) s'inquiéter de comment fonctionne le matériel (parce que je pense qu'il est quand même bon de connaître l'archi globale d'un PC, info qui n'est d'ailleurs dans aucune page de manuel de mon système, à moins que je ne sois passé à côté…).

Le but du noyau est de faire le lien entre le matériel et le logiciel. De la façon la plus exhaustive que possible. C'est aussi une sorte de machine virtuelle pour les logiciels, à priori ton shell n'a pas à se conformer aux specs du matériel mais à ceux de Linux. Linux faisant le lien entre son API et le matériel.

Donc oui le noyau doit permettre cette abstraction, mais pas que. Parfois tu as envie d'avoir accès à tous les détails de ton matériel pour en retirer certaines fonctionnalités ou plus de performances. Ou même tout simplement savoir ce qui se passe.

Ces failles ayant un impact (en terme de sécurité ou de performances), il est bon que le logiciel en dessous (et l'utilisateur) en soit conscient ou du moins puisse l'être. Je serais content aussi que le noyau me prévienne si jamais le bogue sur le calcul des flottants de la part d'Intel (pour un processeur des années 90) revienne pour que le logiciel et l'utilisateur soient capables de tirer parti de cette information.

On est pleinement dans le rôle du noyau.

En plus, les chiffres étaient rond parce que les systèmes sont conçues en assemblant des modules par basés sur des puissances de 2.

Tout à fait, c'est pourquoi globalement toute l'informatique emploient des unités en base deux : nos ordinateurs sont en général l'association de composants qui reposent eux même sur la base 2. Et pourquoi s'en est ainsi ?

Outre le fait que l'information est stockée sous forme de bits, n'oublions pas qu'en électronique il est très courant de juste recopier un motif de composants ou de fils pour les doubler, quadrupler, etc. On retrouve la base 2 dans ce procédé.

Cependant, il y a un endroit de stockage où la base 2 ne fonctionne pas : le stockage de masse magnétique. Les disquettes comme les disques durs, de par leur conception et géométrie n'ont pas ces propriétés des autres composants électroniques comme le processeur, la RAM ou la mémoire flash. C'est à cause de ces composants que le flou entre Ko et Kio ont commencé à émerger.

Le soucis est le manque de cohérence autour de ces unités. Par exemple globalement sous GNU/Linux, l'ensemble utilise les préfixe type Kio. Mais sous Windows, c'est les Ko qui sont affichés (alors qu'en interne cela utilise bien des Kio pour les calculs). Les fabricants des disques durs utilisent aussi les Ko probablement pour des raisons commerciales. Cela est trompeur, de nombreux utilisateurs ne comprennent pas pourquoi un disque dur de 1 To n'en fait en réalité que 900 Gio (suffit de voir la quantité de messages à ce sujet sur Internet).

Mais bon, le manque de cohérence ne se limite pas là. Techniquement on devrait utiliser en anglais aussi les octets au lieu des bytes. Le premier étant explicitement un regroupement de 8 bits alors que le second est le plus petit mot compréhensible pour la machine. Globalement les deux sont identiques depuis 20 ans, mais cela n'a pas toujours été le cas et techniquement, rien ne dit que cela durera éternellement. En plus d'être source d'erreur car à une majuscule près, un facteur 8 est compté ou pas (bits au lieu de bytes).

Comme je l'ai dit, l'information que les personnes malveillantes veulent est disponible quoiqu'il arrive. Tu ne vas pas les retenir longtemps en cachant les fichiers en question.

De plus, étant donnée les failles en question, je doute qu'un script kiddie puisse faire quoique ce soit. Cela demande quand même des compétences, l'outillage et de l'analyse.

Suffit donc de lire le fichier /proc/cmdline qui est accessible à tous, ou alors lire les sorties de dmesg ou de journalctl (de même, c'est accessible à tous) pour avoir cette information.

Bref, rien de très sorcier. Les exploitants des failles dont on parle sont je pense assez compétent pour être capables de récolter ces informations très rapidement.

Je trouve cela sain que l'utilisateur puisse connaître le degré de sécurité de sa machine même s'il n'a pas les possibilités de résoudre cela lui même directement. Sauf en avertissant son administrateur système préféré par exemple.

En tout cas je ne trouve pas non plus de justification qui rende cette divulgation un problème. Si ce n'est pas un problème particulier, autant l'afficher. Cela me paraît normal.

Si tu veux on peut discuter de tout le /sys ou /proc où bon nombre d'infos ne sont pas pertinents pour la quasi totalité des gens, est-ce une raison suffisante pour masquer cela ? Bof

L'utilisateur n'est pas forcément un sudouser donc oui c'est bien plus facile pour lui que de devoir chercher sur le web une liste des noyaux concernés ou pas par la faille. Surtout que l'utilisateur n'est pas forcément un expert.

Tu mets en acces libre /etc/shadow? Si non pourquoi? C'est de la securite par l'obscurite.

Sauf que l'utilisateur lambda n'a pas de moyen d'accéder aux infos de /etc/shadow en dehors de l'accès au fichier lui même.

Concernant les failles, à priori, connaître la version du noyau est suffisant. Information que tu retrouves partout : chargeur de démarrage, démarrage du noyau (ou dmesg / journalctl une fois lancée), uname -a, etc.

Bref, ajouter cette information ne fait gagner que très peu de temps à l'attaquant, et il ne va probablement gagner aucune information supplémentaire qu'avec les moyens que j'ai listé plus haut. Par contre cela simplifie grandement la visibilité de la situation pour l'administrateur et l'utilisateur de la machine.

Pas convaincu que de masquer l'information soit efficace.
Avec la version du noyau normalement tu as une bonne idée de la surface d'attaque. Un uname -a peut donc fournir l'information nécessaire.

Sans compter que la sécurité par l'obscurité n'est pas efficace de manière générale. Miser là dessus me paraît un brin cavalier.

Disons que pour Meltdown, le débit de fuite c'est jusqu'à 500KB/s, c'est-à-dire beaucoup et c'est en partie là le problème qui rend la vulnérabilité vraiment pratique.

Je le sais bien. Mais bon, le contenu dans le cache est très mouvant (pour des caches de plusieurs Mio, ce qui devient de plus en plus courant, cela est difficile de tout récupérer avant un changement important de son contenu).

Puis encore faut-il, avec un dump du cache, réussir à comprendre la signification de la donnée récoltée pour en tirer quelque chose. Loin d'être impossible, mais ce n'est pas non plus immédiat et cela réduit le risque (je pense) d'une attaque d'envergure.