L'heure de rendre des comptes arrive. J'espère que partout dans le monde cela fait être un peu la même histoire, car le problème n'est pas resté cloisonné aux Etats-Unis.

Sinon, je pense qu'un petit article sur les différentes responsabilités (civil, commercial, pénal, etc.) des éditeurs en cas de problèmes avec leur logiciel, cela sera pas mal. Par exemple, est-il possible de se dédouaner de toutes responsabilités via la licence d'utilisation ? Ou de limiter les dommages et intérêts à un plafond, à la localisation de l'entreprise ou d'un pays ? etc.

En tout cas, je serais très preneur ! Sans oublier l'open source, avec des logiciels qui ont souvent une clause d'absence de garantie. Un logiciel open-source pourrait-il être tenu responsable si un tel fiasco se produisait ? La personne ayant choisi d'utiliser un tel logiciel pourrait-elle alors être tenue responsable ? etc.

Bref, une idée d'article ^^

[edit]
Pour aller plus loin dans l'idée d'article, aborder aussi la notion de compétence. Un client français peut-il attaquer un éditeur américain par exemple ? Si oui, dans quelle condition ? Car par exemple, si l'éditeur américain ne cible que les Etats-Unis, mais que le petit client français achète quand même la solution, c'est radicalement différent de l'éditeur qui va se prendre un .fr, monter un site en français, avoir une filiale en France et faire payer en euro. Et si on inverse les rôles ? Si c'est un éditeur français qui veut être poursuivi par un client américain ? Quel est la juridiction compétente ?

Par exemple. Même si les conséquences n'étaient pas du tout les mêmes. D'un côté, c'était plutôt l'exfiltration de données. De l'autre, l'arrêt complet, que l'on pourrait presque assimilé à un DOS avec l'arrêt complet de certaines activités !

[edit] Rajout de la partie en italique.

Ah ben désolé, j'ai spoilé ^^

Au sujet du message perso : toujours partant. C'est juste compliqué depuis quelques mois niveau timing et j'avoue que je n'ai pas mis les pieds à La Rochelle depuis des lustres donc yes, ça me tente bien à la rentrée, quand les touristes seront partis. Et autre détail : je suis "sans voiture" actuellement. J'ai une C3 victime des airbags Takata...

A mon avis, c'est loin d'être aussi simple. Pour créer une API spécifique :
- il faut que tout les besoins soient clairement identifiés (ce qui est difficile dans ce genre de situation)
- très certainement remodelé une partie du coeur même du noyau (opération hautement critique).

Sans compter qu'un des points forts de Microsoft reste la rétrocompatibilité. Faire un tel changement aurait sans doute cassé quelques trucs. Je ne connais pas beaucoup d'OS qui permettent de prendre un programme vieux de 25 ans (par ex. sous Windows 98) et de le faire tourner sur un Windows 10 ou 11 juste en cliquant dessus (et non, Linux ne rentre pas dans cette catégorie, il faudra au mieux recompiler le programme si tant est que l'opération reste possible).

Faire en sorte que sa solution soit au même niveau que les autres, c'est potentiellement abaisser la sécurité globale du système. Pas vraiment souhaitable donc.

Rendre les solutions plugables dans Hyper-V n'aurait pas résolu les problèmes. Pour ce qui est virtualisé, sans doute. Pour le reste non.

Là, on est dans une situation qui est un bel exemple de la Loi de Murphy. La situation a été catastrophique, car :
- le driver est un driver noyau
- la solution est très répandue
- la solution est utilisée dans des infrastructures visibles (aéroports, hopitaux, etc.)
- la gestion de la mise à jour est faite par l'éditeur
- un driver en espace noyau lit un fichier de configuration en espace utilisateur
- l'éditeur pousse une mise à jour d'un fichier de configuration chez tous ses clients en même temps
- les clients n'ont pas vraiment de moyen de contrôler la mise à jour de ce fichier de configuration
- la mise à jour faisait planter quasi-systématiquement le système (au point qu'on se demande si elle a été testé !)

Enlève ne serait-ce qu'un de ces points, et la situation critique que nous avons connu il y a quelques jours n'aurait pas eu lieu.

L'argument avancé par Microsoft peut tout à fait tenir la route (je n'ai pas suffisamment d'éléments pour dire si c'est effectivement le cas ou non). Je dis juste qu'il est tout à fait plausible, et le démonter ne sera pas si facile que ça.

[edit]
Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.

Je suppose que c'est parce que le système avait le temps de booter entièrement.

Quan je dis mode sans échec, c'est un abus de langage. Pour moi, il commence avec le menu présenté au démarrage, où on indique ce que l'on veut faire :
- démarrer normalement
- démarrer en mode sans échec
- démarrer en mode sans échec avec prise en charge réseau
- ouvrir une console
etc.

Mais sinon oui, tu as tout à fait raison : un démarrage en mode sans échec sans intervention de l'utilisateur, c'est une mauvaise idée.

Alors je vais essayer d'éclaircir.

L'espace noyau, c'est, comme son nom l'indique, l'espace noyau (je sais, Lapalisse n'aurait pas fait mieux). C'est le coeur du kernel de l'OS. C'est le truc qui doit impérativement être hyper stable, sous peine de créer des BSOD ou kernel panic (pour prendre l'équivalent Linux)

L'espace utilisateur, c'est ce qui est externe à l'espace noyau, et que potentiellement, un utilisateur peut modifier. Un fichier sur disque par exemple, c'est de l'espace utilisateur. Le fichier de configuration fait partie de l'espace utilisateur, car réside sur un espace de stockage externe au noyau.

Un driver, avant d'être chargé, est en espace utilisateur. Maintenant, il existe des mécanismes pour assurer l'intégrité du driver entre son chargement et son activation effective au sein de l'espace noyau, pour éviter qu'un driver modifié (=fichier modifié sur le système de fichier) par un utilisateur quelconque ne soit chargé.

L'UEFI, décrié par certains, est un mécanisme qui permet justement d'assurer l'intégrité de l'espace noyau dès le démarrage du système.


Maintenant, que la lecture du fichier de configuration se fasse directement par le noyau ou par un programme utilisateur qui transmet ensuite l'information au driver, qu'importe, le résultat est le même : la configuration est transmise depuis l'espace utilisateur vers l'espace noyau, et doit donc, à ce titre, est (re)validé côté noyau. C'est une règle de base de la sécurité : ne jamais accepter sans vérification une entrée utilisateur (le bogue classique en contexte applicatif "classique" de cette règle étant l'injection SQL).


J'espère avoir été plus clair ;)

J'avoue avoir utilisé ces termes dans un sens peu conventionnel, notamment du point de vue d'un dev.

Je pensais que le contexte général suffirait à comprendre. Il semblerait que non. Mea culpa.