![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>La solution optimale serait de ne transf\u00e9rer que les corrections et vuln\u00e9rabilit\u00e9s les plus importantes, mais isoler ces erreurs du flot g\u00e9n\u00e9ral repr\u00e9sente le principal probl\u00e8me. La majorit\u00e9 des probl\u00e8mes \u00e9mergents r\u00e9sulte de l'utilisation du langage C, qui n\u00e9cessite une grande rigueur dans la manipulation de la m\u00e9moire et des pointeurs. La situation est aggrav\u00e9e par le fait que de nombreuses corrections potentielles de vuln\u00e9rabilit\u00e9s ne re\u00e7oivent pas d'identifiant CVE, ou en obtiennent un seulement apr\u00e8s un certain temps apr\u00e8s la publication du correctif. Dans ces conditions, il est tr\u00e8s difficile pour les \u00e9diteurs de distinguer les correctifs secondaires des probl\u00e8mes majeurs affectant la s\u00e9curit\u00e9. Selon les statistiques, plus de 40 % des vuln\u00e9rabilit\u00e9s sont corrig\u00e9es avant l'attribution d'un CVE, et le d\u00e9lai moyen entre la publication du correctif et l'attribution d'un CVE est de trois mois (c'est-\u00e0-dire qu'au d\u00e9but, le correctif est per\u00e7u comme une simple erreur, mais il devient clair plusieurs mois plus tard qu'il s'agissait d'une vuln\u00e9rabilit\u00e9).<\/p>\nEn cons\u00e9quence, sans une branche s\u00e9par\u00e9e pour les corrections de vuln\u00e9rabilit\u00e9s et sans obtenir d'informations sur le lien avec la s\u00e9curit\u00e9 d'un probl\u00e8me donn\u00e9, les fabricants de produits bas\u00e9s sur le noyau Linux doivent continuellement transf\u00e9rer tous les correctifs des nouvelles branches stables. Cependant, ce travail n\u00e9cessite une grande quantit\u00e9 de ressources et fait face \u00e0 une r\u00e9sistance au sein des entreprises en raison de la crainte d'introduire des changements r\u00e9gressifs susceptibles de perturber le bon fonctionnement du produit.<\/p>\n
Rappelons qu selon Linus Torvalds, toutes les erreurs sont importantes et les vuln\u00e9rabilit\u00e9s ne doivent pas \u00eatre s\u00e9par\u00e9es des autres types d'erreurs et class\u00e9es dans une cat\u00e9gorie de priorit\u00e9 sup\u00e9rieure. Cette opinion s'explique par le fait que pour un d\u00e9veloppeur ordinaire, qui ne se sp\u00e9cialise pas dans les questions de s\u00e9curit\u00e9, il n'est pas \u00e9vident de faire le lien entre un correctif et une vuln\u00e9rabilit\u00e9 potentielle (pour de nombreux correctifs, seul un audit s\u00e9par\u00e9 permet de comprendre qu'ils concernent la s\u00e9curit\u00e9). Selon Linus, la t\u00e2che de distinguer les vuln\u00e9rabilit\u00e9s potentielles du flot g\u00e9n\u00e9ral des correctifs doit \u00eatre assum\u00e9e par des sp\u00e9cialistes en s\u00e9curit\u00e9 des \u00e9quipes responsables du soutien des paquets avec le noyau dans les distributions Linux.<\/p>\n
Kees Cook estime que la seule solution pour maintenir la s\u00e9curit\u00e9 du noyau \u00e0 des co\u00fbts raisonnables \u00e0 long terme est de transf\u00e9rer \u00e0 des ing\u00e9nieurs des entreprises la t\u00e2che de porter les corrections dans des compilations locales du noyau, pour collaborer de fa\u00e7on coordonn\u00e9e \u00e0 l'entretien des correctifs et des vuln\u00e9rabilit\u00e9s dans le noyau principal (upstream). Dans l'\u00e9tat actuel des choses, de nombreux fabricants utilisent des versions du noyau qui ne sont pas les plus r\u00e9centes et effectuent des backports des correctifs par leurs propres moyens, ce qui signifie que les ing\u00e9nieurs de diff\u00e9rentes entreprises doublent leurs efforts en s'attaquant au m\u00eame probl\u00e8me.<\/p>\n
Par exemple, si 10 entreprises, chacune avec un ing\u00e9nieur s'occupant de backporter les m\u00eames corrections, r\u00e9orientent ces ing\u00e9nieurs vers la correction des bugs dans l'upstream, ils pourraient au lieu de porter une seule correction, r\u00e9soudre 10 bugs diff\u00e9rents pour un b\u00e9n\u00e9fice commun, ou participer \u00e0 la r\u00e9vision des modifications propos\u00e9es afin d'\u00e9viter d'inclure des codes erron\u00e9s dans le noyau. Les ressources pourraient \u00e9galement \u00eatre dirig\u00e9es vers la cr\u00e9ation de nouveaux outils pour tester et analyser le code, permettant d'identifier automatiquement, d\u00e8s les premi\u00e8res \u00e9tapes, les classes d'erreurs r\u00e9currentes.<\/p>\n
Kees Cook propose \u00e9galement d'utiliser plus activement les tests automatis\u00e9s et de fuzzing directement dans le processus de d\u00e9veloppement du noyau, d'appliquer des syst\u00e8mes d'int\u00e9gration continue et d'abandonner la gestion archa\u00efque du d\u00e9veloppement par email. Actuellement, le test efficace est entrav\u00e9 par le fait que les principaux processus de test sont s\u00e9par\u00e9s du d\u00e9veloppement et se d\u00e9roulent apr\u00e8s la formation des versions. Kees recommande \u00e9galement de r\u00e9duire le nombre d'erreurs en utilisant des langages assurant une meilleure et de confidentialit\u00e9 des utilisateurs est promis, ainsi que des standards ouverts. Un des arguments avanc\u00e9s est l'utilisation de l'algorithme Signal. Le syst\u00e8me prend \u00e9galement en charge la recherche et la consultation illimit\u00e9e de l'historique des messages, le partage de fichiers, les communications vocales et vid\u00e9o. De plus, il existe des fonctionnalit\u00e9s telles que des notifications de saisie, des confirmations de lecture, des notifications push et une recherche c\u00f4t\u00e9 client.<\/a>, comme Rust.<\/p>\n