Le créateur du noyau Linux aimerait supprimer le support de ces vieux processeurs, officiellement mis à la retraite en 2007 par Intel. Ils avaient été introduits en 1989, à une époque où de nombreuses cartes mères avaient encore un slot dédié au coprocesseur.
Torvalds argumente : le support du i386 a été supprimé en 2012 et s’il existe encore des personnes se servant d’un 486, elles pourront rester sur un noyau LTS. Au rang des bénéfices bien sûr, un coup de ménage et la suppression de vieux pans de code, réduisant la surface d’attaque et augmentant d’autant la sécurité.
Si l’on en croit les premières réponses d’autres développeurs, supprimer ce support n’aurait rien de complexe. Phoronix, qui relaie l’information, pense que la version 6.1 du noyau pourrait être la prochaine mouture LTS. La 6.2 pourrait être la première à ne plus avoir de support pour l’architecture i486.
Commentaires (54)
#1
Qu’est-ce qu’on peut faire en 2022 avec un 486 ? Plus aucun X ne doit tourner normalement, et même en serveur, je ne vois pas bien le cas d’un usage un simple Raspberry Pi est probablement 10x plus puissant en consommant 2-3x moins !
#2
@fofo9012 : Du matériel industriel. C’est très fréquent de voir des robots, des outils lourds qui ont une CM qui a quelques générations de retard. Parce que ladite machine a demandé quelques années pour sa conception, parce que le matériel informatique a été choisi par le fabricant pour sa robustesse éprouvée, et parce que les entreprises clientes n’ont aucun besoin de remplacer des engins qui chiffrent facile à 6 décimales avant la virgule.
#2.1
Cet argument est habituellement utilisé pour justifier l’existence de Windows 3.11 dans un SI. Il y a des cas d’usages de postes de contrôle de ce genre de machine industriel qui soit sous Linux ?
De toute mon expérience pro, les seuls postes clients que j’ai vu sous Linux étaient des bornes publiques dans une administration. Le reste, c’était du parc serveur qui est du matériel régulièrement renouvelé (et dont la question ne se pose plus vraiment avec la virtualisation).
#2.2
D’ailleurs, vu l’écart entre les durées de vie des moyens industriels et des supports de Windows, ce dernier devrait être banni des équipements industriels.
Qu’il y ait un Windows en passerelle pour pouvoir faire l’interface avec un SI full MS et authentification AD pourquoi pas, il s’agirait d’un équipement purement IT donc maintenable et qui peut évoluer. Mais en pilotage direct, c’est une aberration d’utiliser du Windows.
#2.4
Bah le choix de Windows pour du poste client est souvent basé sur le fait que c’est un standard de fait de part sa position sur le marché. Tout est question d’intégration avec le SI ensuite comme évoqué par d’autres intervenants ici.
Un cas que j’ai connu aussi, le service comm’ d’un de mes premiers clients qui avait un scanner format A3 branché en SCSI avec un driver qui n’était pas compatible avec Windows XP SP2. Il était hors réseau et les utilisateurs se servaient d’une clé USB pour récupérer les documents scannés (oui, heureusement le PC avait des ports USB).
Et ce fut folklo le jour où ce PC a clamsé car d’un, j’ai du réussir à retrouver le même modèle pour lui greffer la carte SCSI (on a du aller en chercher un auprès d’une antenne régionale à 250km dont le parc n’avait - heureusement - pas encore été totalement renouvelé !) et ensuite faire du Frankenstein avec le master XP pour l’empêcher d’installer le SP2 (vu qu’en natif il claquait direct le SP3 même
). Au vu du nombre de jours qu’il a fallu pour réussir à refaire marcher ce scanner, j’avais estimé à l’époque le coût de l’opération à quelques 10k€ vu la logistique et le nombre de personne qui a du travailler sur le sujet. Je sais pas combien coûtait ce bousin, mais je suis pas certain que l’opération fut rentable vis à vis de sa fréquence d’utilisation.
#2.5
A première vue c’est 5k€ après il faut aussi tout réapprendre aux utilisateurs (IHM différente).
Plutôt que XP SP1 tu aurais dû installer Win2K ;)
C’est bizarre une machine windows chez des graphiste, d’ailleurs le SCSI c’était surtout utilisé sous mac (oui je sais il y avait aussi du SCSI sur les serveurs windows pour gérer le RAID)
#2.6
J’avais pas de master Windows 2000 sous la main, j’étais en bout de chaîne de ce point de vue
Pour le reste ………… C’est historique ™
C’était pas un serveur, une tour ordinaire mais les modèles plus récents avaient juste deux petits soucis (trois fois rien) : ni les ports sur la carte mère, ni l’espace physique pour installer la carte (trop large par rapport à la tour)
#2.12
Il doit me rester un CD Select si tu veux ;)
Je ne dis pas que le SCSI n’est pas utile pour un graphiste, je dis qu’un PC Windows n’est pas le plus adapté pour un graphiste alors qu’un MAC est SCSI nativement.
Typiquement c’est très important, dans l’imprimerie, que les couleurs d’un document scanné soit identiques à l’impression. Et étalonner un PC sous XP c’est pas la panacée.
Effectivement et le jour où CISCO arrêtera ses cartes XoT ils seront dans la merde…
Si tu prends un Teleperm XS par exemple il a besoin de mise à jour des données d’entrée et il peut s’appuyer sur une architecture informatique dédiée.
#2.7
Quand il s’agit d’un équipement qui chiffre en millions, le faire fonctionner de manière dégradée ou non optimale parce que des commerciaux ont vendu le fait que “tout le monde connaît Windows” (argument de vente des baies robot Kuka !), c’est vraiment pas un bon choix technique.
J’ai bossé dans un grand groupe, pour une garantie de qualité, à chaque nouvelle pièce la machine devait récupérer le programme sur le réseau pour garantir de toujours avoir utilisé la bonne version. La DSI ne connaît que la bureautique, pas de réseau séparé pour l’industriel, donc la machine doit s’authentifier avec un compte du domaine pour accéder au répertoire de stockage des programmes. Donc un Windows qui embarque aussi l’applicatif automate et interface.
Un incompétent arrive à la DSI groupe, paranoïaque parce qu’incompétent, et décrète que tous les PC connectés au réseau doivent être en W10 et passer toutes les mises à jour dès diffusion. Spoiler alert, il est fréquent que des mises à jour Windows perturbent le noyau automate, le constructeur recommande de ne passer que certaines vraiment liées à des failles de sécurité. Pour des machines plus anciennes, le constructeur du PC-qui-fait-tout ne supporte pas la migration Windows 10 (une petite boîte du nom de Siemens) et reste en Windows 7, donc PC industriel à 5k€ à racheter et programme automate complexe à faire migrer.
Bien entendu, la DSI interdit les réseaux hors AD, interdit l’utilisation d’un PC passerelle, interdit la connexion d’un PC qui ne soit pas en Windows 10 et propose de… voir avec le fournisseur pour qu’il se démerde pour faire une solution qui rentre dans leurs exigences.
Résultat, les machines sont débranchées du réseau, les programmes transférés à la clé USB et une traçabilité manuelle doit être mise en place pour vérifier si la bonne version de programme a été utilisée pour réaliser la pièce.
#2.8
Roh j’ai le même soucis avec des automates Siemens Win7 qui ne sont pas upgradable Win10, ils ont été coupé du réseau et fonctionnent en mode dégradé, tant pis
De mon côté SI, je ne comprends même pas que des boites comme Siemens developpent ce genre de machine sous Windows ! pourquoi ne pas utiliser un Yocto sur mesure qui réduirait énormément les surfaces d’attaques, et pourrait rester dans un vlan sur le réseau.
Prendre Win7, Win10 dans un produit industriel est une hérésie…
#2.9
Ils sont au courant que les ESU existent ?
#2.10
Je sais pas pour Siemens, mais pour d’autres marques d’automates, les builds du systèmes sont parfois modifiées un peu “trop” en profondeur, et du coup, appliquer une màj OS ou modules systèmes générique est plus que périlleux. Perso, je le ferai jamais sauf si le constructeur me valide la manipe…
#2.11
On parle bien des windows embedded standard ? Dans ce cas ça ne devrait pas trop poser de problème (je crois que la MAJ s’adapte aux composants installés et au pire c’est facile à tester en machine virtuelle par ex, excepté niveau driver). Après pour du windows CE, c’est plus compliqué en effet.
Le mieux mais c’est pas toujours possible malheureusement est d’avoir un exemplaire de test.
#2.13
En effet, je parlais CE…
#2.3
Dans le cas d’une machine industrielle il suffit de ne pas mettre à jour le système informatique associé, le fait qu’il existe des noyaux plus récent ne va pas subitement empêcher les anciens de fonctionner, il n’y a pas de time bomb dans les noyaux linux, et comme en principe on ne relie pasz ce genre de choses à un réseau avec accès extérieur voir pas de réseau du tout ça ne pose pas vraiment de problème de sécurité.
De toutes façons dans ce genre de cas la machine est souvent fournie “clé en main” par son fabricant avec le système informatique adapté et c’est ce même fabricant qui s’occupe des mises à jour(aussi bien soft que hard) s’il y a lieu, jamais l’utilisateur
J’ai eu le cas dans une ancienne boite où on avait une machine très spécifique pilotée par un PC sous Win95 et donc l’applicatif ne marchait correctement que sous cet OS (ouais je sais c’est cocasse
), elle était simplement déconnectée de tout réseau et la seule façon de lui entrer des données de travail était via son lecteur de disquette.
#3
Cool j’aie 80 486 chez moi … reste plus qu’a trouver le PC qui va avec !
#4
Presque vrai. Il n’y a qu’un cas qui peut être problématique (et je commence à le voir de plus en plus) : la mise à jour des protocoles de sécurisation. Montée en version de TLS et abandon de SSL, abandon de protocole non sécurisé (RC4 et compagnie) font qu’il est parfois compliqué de dialoguer avec une machine industrielle par le réseau.
La solution est alors de passer par une passerelle, mais beaucoup semblent ne pas connaitre cette solution !
#4.1
https://www.tri-m.com/index.php/product/tri-m/pc104-cpu-modules/vdx104-plus-detail
On en trouve encore.
Ceci dit ce genre de matos n’est plus non plus mis à jour coté software, donc le fait que linux tourne plus dessus est pas hyper gênant… :-)
Ya une problématique énergétique aussi pour les nouveaux designs, autant partir sur de l’ARM.
Le pb alors c’est la puissance CPU , donc de toute façon la passerelle devient requise en effet.
#4.2
Ce produit n’utilise pas un i486 mais un Vortex86DX qui est compatible avec les jeux d’instruction i586. Il ne serait donc pas concerné par l’arrêt du support du i486.
Et contrairement à ce que tu dis, Linux est supporté.
Tu aurais pu avoir ces informations en cliquant sur l’onglet Specifications.
#5
Si ton automate ne supporte que SSLv3 mais que le reste de ton réseau est en TLSv1.2 ou supérieur, ton automate ne peut plus communiquer. En quoi est-ce un problème de puissance CPU ?
#6
J’avais compris l’inverse :
Si le reste du réseau évolue mais que ton automate (ou ton système indus spécialisé) ne suis pas.
Les also de chiffrement récents s’appuient parfois sur des instructions spécifique (je pense à AES), et du coup sur de vieux processeurs le temps utilisé sera plus important.
Je n’avais pas compris cela: J’ai bien vu que c’était un processeur compatible , mais j’avait pas vu que c’était i586 et non i486 (il y a une version du Vortex qui n’est pas compatible i586, j’ai confondu, notamment à cause du nom : 86DX m’a fait trop penser à 486DX , alors qu’en pentium il n’y avait plus ces notations).
j’avais aussi vu des versions de CPU “compatible” (vieux ! En cyrix & tout) dont l’implémentation de cmpxchg8b était pas fiable et donc désactivée.
Alpine Linux est encore compilé en terme de userland pour le support des i386, ça peux faire une bonne base si besoin de mettre à jour de vieux systèmes, mais bon c’est un truc que j’ai eu à faire depuis ~ 2015 .
#6.1
Après malheureusement beaucoup de drivers sont abandonnés, ce qui réduit l’intérêt de compiler un kernel pour des vieilles machines. J’ai vu dans un environnement industriel un debian sur kernel 2.2 qui n’était plus upgradé car perte du support dans les kernels supérieur de la carte raid. (Sur un Pentium pro 150 je crois). C’est marrant de revoir KDE de l’époque!
Pour info, pour avoir déjà essayé d’utiliser une distribution récente sur du vieux matos pour de la récup de donnée par exemple, c’est bien souvent inutile : les supports de FS sont souvent mauvais et dangereux (exemple le xfs qui ne supporte plus les vieux XFS) mais qui essaie quand même de vouloir le réparer, les mauvais support matériels pour les cartes SCSI… donc finalement, est-ce que le support du 486 est toujours intéressant ?
#7
Il y a aussi antiX Linux, une Debian qui tourne avec le noyau 4.
#8
Il a raison : les puces sont faites pour être grattées.
#9
Vu il y a quelques mois dans une entreprise qui fabrique des pièces métalliques de précision une machine-outil dont l’OS est OS/2 sur un processeur i286. Le chargement des données pour les travaux à effectuer se fait via un lecteur de bande qui est la seule mémoire de masse compatible entre 30 ans d’évolution technologique et dont on trouve encore assez facilement les consommables.
Du coup la mise à jour du système sur ce genre de machine
#9.1
J’ai bossé 20 ans dans le cinéma, la bande perforée c’était le support de stockage par excellence pour les données d’étalonnage car ça prend pas trop de place (la bande tient dans la boite de la bobine pour conserver les 2 ensemble) ça ne se détériore que très peu dans le temps, c’est lisible avec un appareillage ultra basique et au pire c’est même déchiffrable par un humain qui connait un peu le système.
C’est absolument pas bizarre du tout, surtout pour des graphistes.
) ma machine perso tournait avec des disques U2W (des IBM Ultrastar à 10k tr/min si ma mémoire est bonne), ça valait une blinde mais ça mettait une fessée à n’importe quel disque UDMA, y compris les WD Black de l’époque, tant en taux de transfert qu’en temps d’accès.
Avant l’arrivée du SATA, et même un peu après, la seule solution pour avoir un minimum de perfs en stockage c’était le SCSI.
Quand j’étais encore chez mes parents (donc que j’avais un peu moins de soucis financiers
#10
Tant que personne ne priorise la sécurité avant le profit, les catastrophes industrielles (adjectif fort à propos) continueront à disposer d’un terreau fertile.
Concernant l’aspect économique, on peut arguer qu’une machine-outil aussi rentable que cela, si elle l’était vraiment, serait du coup très facilement remplaçable, car rapidement amortie (bien plus rapidement que ce que la comptabilité légale prévoit).
Et je pars du postulat de l’auteur sur une telle rentabilité. On pourrait aussi la remettre en question, à l’aune de la répartition des coûts de la machine dans les coûts de production de… la production.
Il n’y a aucun argument pragmatique respectable quant au maintien en vie d’équipements non-supportés ou normes/standards insécurisés.
Cela fait maintenant des décennies que l’industrie se déresponsabilise des risques qu’elle crée.
Quelqu’un ? Non ? Il n’y a que moi ?
#11
J’ajoute à mon commentaire précédent que le matériel pourrait être sorti d’un chemin critique, et si trop compliqué à maintenir, pourrait être donné à des structures de type ludique aux budgets restreints, type associatif ou individus souhaitant apprendre en s’amusant.
Cela leur évitera d’acheter du matériel neuf dont ils n’ont pas besoin sans créer de risque de sécurité.
#11.1
Facile de dire cela, quand tu as des machines qui coutent des centaines de milliers d’euro et que tu calculs leurs rentabilité sur 20 ans à l’achat, tu ne les changes pas pour une version d’OS.
#11.2
En industrie si tu mise sur 20 ans pour rendre rentable un investissement tu as tout faux.
De mémoire et sauf erreur de ma par j’avais appris qu’un investissement “matériel” devait être amortis en 4 années maximum.
#11.3
4 ans c’est pour le tertiaire, en industrie ça peut aller jusqu’à 40⁄50 ans
#11.4
cela me semble absolument énorme!!!
#11.5
C’est bien le problème de faire cohabiter des éléments qui n’ont pas du tout des échelles de temps comparables : 4-5 ans max pour l’IT, 20-40 ans pour l’industrie.
#11.6
Si tu prends les systèmes automatisés de sécurités d’un haut fourneau ou d’une centrale nucléaire, on ne va pas tout changer simplement parce que Microsoft ne maintient plus
WindowsDos 3.Bien sur que tous les matériels n’ont pas 40 ans, mais certains représentent le coeur de métier de l’industrie.
Il y a 5 ans je travaillais encore sur des matériels qui communiquent en X25
#11.7
Exactement. Il n’y a pas si longtemps que ça (7 ans maintenant quand même), l’aéroport d’Orly a été bloqué suite à une panne d’informatique. Le système tournait sous… Windows 3.1 !
Beaucoup ont crié leur indignation, qu’il était inadmissible d’avoir un système qui n’était plus maintenu, etc…
Pour ma part, sachant que Windows 3.1 n’a pas de connexion réseau, ce n’est pas gênant. Et pour un système aussi critique, je préfère largement avoir un applicatif qui tourne bien, testé et approuvé depuis des années qu’un nouveau truc dont on n’est pas encore sûr…
#11.8
D’accord avec toi sur le besoin de fiabilité mais bosser avec du matériel antique c’est vraiment chercher les ennuis.
Pour les besoins vraiment spécifiques il faudrai pas dépasser les 20 ans avant de renouveler l’installation sinon tu prends un risque avec la vétusté du matériel et pas forcément de pièces de rechange facilement disponibles, mais aussi le risque avec les gens compétents pour administrer ces équipements qui quittent l’entreprise, la boite qui te la vendue qui a mis la clé sous la porte etc.
#11.9
Si tu es sur un site Seveso avec des centaines d’automates classés, tu remplaces tout et tu repasses la qualification ou tu maintiens l’existant, quitte à passer par des brockers pour les pièces de rechange ?
Typiquement j’ai eu énormément de mal à trouver des vrais adaptateur USB/RS232 qui respectent scrupuleusement la norme. Certains nécessitaient même un PC avec port série intégré parce que le logiciel de configuration, propriétaire ne tournait que sous dos.
#11.12
J’ai eu le même problème que toi Tandhruil, j’ai “écumé” eBay pour faire un stock de pièces de rechange en tenant compte de la durée de vie restante de l’installation industrielle et du nombre de pièces des produits informatiques “consommées” précédemment. Abaque foireuse, mais j’avais pas mieux…
Quand tu te frottes à des installations industrielles qui sont lourdes et avec un cycle de vie en plusieurs dizaines d’années, c’est là où tu prends conscience que le mode d’itération en “bureautique” est totalement inadapté à ce monde. Dans le premier cas, tu privilégies la mise à jour et l’évolution de la solution le plus possible, et dans l’industriel, a contrario, tu privilégies le “tombé en marche” et le MCO par l’immobilisme le plus strict possible.
Ghimo, si je pouvais, je te ferai visiter une installation assez imposante dont la sécurité structurelle est assurée par un antique “automate” qui n’est qu’un PC 386 sous DOS 3.2 avec un logiciel dédié qui tourne, par je ne sais quel miracle, en temps réel… qui communique ses données par disquette 5”1⁄4 et dont la supervision se fait par port série à 4800 Bds exclusivement !
#11.11
En fait, il n’y a pas de souci tant que l’OS n’est pas sur un réseau, mais généralement ce qui se passe c’est que pour des raisons de praticité, tous les appareils industriels se sont retrouvé sur le même réseau que la bureautique, les dev, la prod, etc…
Et comme chez les industriels, faire du DevSecOps, c’est un truc inutile qui coute de l’argent pour rien (des mises à jour de sécurité ? c’est quoi ? ) on se retrouve avec des machines pleines de trous sur le réseau (souvent le seul réseau, pas de vlan nada)
Et, comme il n’y a pas un jour sans que l’on entende qu’une boite s’est faite crypter toutes ses données, ça flippe (à raison) dans les DSI.
Et on part dans l’extrême inverse –> OS Obsolète, pas de maj de sécu ? –> Hors réseau, oubliez le vlan ou la passerelle, on veut pas le voir, pas de clé USB vous vous démerdez.
Si vous voulez le revoir sur le réseau, achetez l’upgrade si ça existe, ou changer de produit, bref débrouillez-vous ^^
#11.10
Ca dépend du secteur d’activité, dans le cinéma j’ai bossé sur des machines qui dataient du début des années 70, et qui étaient très précieuses car elles faisaient des choses qu’aucune machines plus moderne n’était capable de faire aussi bien, ou aussi simplement.
Depuis avec la numérisation les effets spéciaux, déformation d’image, et conversions de formats se font en numérique mais à l’époque tout ce faisait en optique et pour le coup quand tu savais dépanner ce genre de machines pré circuit intégrés, donc avec que de la logique câblée à base de boites à relais, de miroirs et de prismes, disons que même en cas de charrette ton poste était pas le premier à être en danger quoi
#11.13
ne mélangeons pas tout. on parlait de rentabilité!
je suis convaincue que certaine machine ne sont pas facilement remplaçable seulement leur cout d’achat à été amortis depuis le temps.
Et oui je peux concevoir que bien que l’outil de production soit amortis on ne souhaite pas investir pour sont remplacement pour diverse raison.
Du reste l’exemple de Thandhruil est pas vraiment des investissements machine mais de l’infrastructure trés lourde.
#12
C’est très con d’avoir interdit le PC Passerelle. L’intérêt d’une passerelle de ce type c’est justement de créer soi-même un SPOF afin de mettre tous les efforts de contrôle possibles sur ce point.
Là, les employés vont utiliser des clés USB pour transférer le logiciel. En terme de vulnérabilité, les clés USB qu’on branche à tout va c’est autrement plus compliqué à gérer qu’un PC passerelle.
#12.1
C’est dire l’incompétence crasse des “managers” IT, ils ont peur de leur ombre, tout ce qu’il veulent ce sont des audits totalement vierges et des contrats de support pour avoir un coupable externe en cas de souci.
#13
J’approuve ce message.
#14
Notre dernier serveur à en faire à l’époque avait senti le vent venir, la carte a cramé un mois avant l’arrêt du réseau par France Telecom
Ce fut l’occasion de migrer le dernier flux qui traînait dessus pour lequel le service concerné rechignait.
#14.1
Transpac a été fermé en juin 2012, mais là, il parle de 2017. Il s’agissait probablement d’un réseau X25 privé.
#14.2
Oui en effet nous c’était le service Transpac.
Ca me rappelle quelques années encore avant, la supervision du service audiotel et minitel d’un client. Tu regardais les logs des serveurs pour voir l’activité… L’audiotel, tabassé, logique. Le service minitel, les seules connexions depuis deux ans c’étaient le robot de test
#15
Pour faire du MODBUS RTU, il faut désactiver l’envoi différé sinon tu casse le timing des trames. Les convertisseurs à base de puces FTDI se débrouillent bien mieux sur ce type d’usage.
De même si tu es sur une liaison RS485, c’est également les FT232 qu’il faut pour gérer la validation de l’amplificateur d’émission.
#15.1
C’est pour ça précisément que je garde mes adaptateurs Schneider RS232 et 485 qui fonctionnement si bien. Et que je les ai toujours dans petite sacoche. Des fois, ça te sauve la vie !
#16
J’étais intervenu déjà en 2017 dans cette boîte post cyberattaque. Visiblement, mes précos n’ont pas été suivies… Et du coup, seconde attaque et mise en redressement judiciaire cf Ici. Donc des fois, ça flippe pas suffisamment je pense…
#17
Pour les hauts fourneaux, je ne sais pas mais pour les centrales, il n’y a pas d’OS: C’est pas sûr. Dans ce type de systèmes, on doit tout maîtriser jusqu’au matériel.
Pas d’OS, pas de processeurs non prédictifs (exit les pentiums qui réorganisent les instructions), pas de bibliothèque tierce, pas de processeur avec un micro-code modifiable, rien qui ne soit pas maîtrisé comme il faut.
#17.1
Tu es sûr de ton coup pour les CNPE ? Tu parles de ceux en construction ou du parc installé ?
#17.2
Sur le parc actuel. Il est en cours de modernisation et les processeurs 8 bits du début des années 80 sont remplacés par des processeurs d’il y a seulement 25 ans.
Sans OS et sans JAVA, on est en sécurité.
En //, il y a aussi des systèmes sans aucun composant programmable, même pas un circuit logique configurable. Ce type de système continue d’être développé pour des raisons évidente de fiabilité et de sûreté.
#18
Je n’ai pas encore pratiqué le TXS. Le problème vient des timings serrés comme pour MODBUS TCP ou du fait que le soft veux causer avec un 8250 natif ? windows XP émulait le hardware pour éviter ces problèmes avec les vieux logiciels accédant en direct au hardware.