Kees Cook realitzo una publicació de bloc en la qual ha expressat la seva preocupació pel procés de correcció d'errors en curs en les branques estables de el nucli de Linux i és que esmenta que setmana a setmana s'inclouen al voltant de cent correccions a les branques estables, la qual cosa és massa i requereix molta cura a mantenir productes basats en el nucli de Linux.
segons Kees, El procés de gestió d'errors de l'nucli es passa per alt i el nucli no té al menys 100 desenvolupadors addicionals per treballar de manera coordinada en aquesta àrea. A més de que esmenta que els principals desenvolupadors de el nucli corregeixen errors amb regularitat, però no es garanteix que aquestes correccions es transfereixin a variants de el nucli de tercers.
Amb això, esmenta que els usuaris de diversos productes basats en el nucli de Linux tampoc tenen forma de controlar quins errors es corregeixen i quin nucli s'utilitza en els seus dispositius. Al final, els proveïdors són responsables de la seguretat dels seus productes, però davant una taxa molt alta de pegats a les branques estables de el nucli, es van enfrontar a l'opció de migrar tots els pegats, migrar selectivament els més importants o ignorar tots els pegats.
Els desenvolupadors de nucli ascendents poden corregir errors, però no tenen control sobre el que un proveïdor descendent tria incorporar als seus productes. Els usuaris finals poden triar els seus productes, però generalment no tenen control sobre quins errors es corregeixen ni quin nucli s'usa (un problema en si mateix). Al final, els proveïdors són responsables de mantenir segurs els nuclis dels seus productes.
Kees Cook suggereix que la solució òptima seria transferir només les correccions i vulnerabilitats més importants, Però el problema principal és separar aquests errors de l'flux general, ja que la major quantitat de problemes emergents és conseqüència de l'ús de l'llenguatge C, que requereix molta cura a l'treballar amb la memòria i els punters.
Per empitjorar les coses, moltes possibles correccions de vulnerabilitats no estan etiquetades amb identificadors CVE o no reben un identificador CVE algun temps després que es publiqui el pegat.
En un entorn així, és molt difícil per als fabricants separar les correccions menors dels problemes de seguretat importants. Segons les estadístiques, més de l'40% de les vulnerabilitats s'eliminen abans de l'assignació de CVE i, de mitjana, el retard entre la publicació d'una solució i l'assignació d'una CVE és de tres mesos (és a dir, a l'inici, es percep una solució com un error comú,
Com a resultat, al no tenir una branca separada amb correccions per a les vulnerabilitats i al no rebre informació sobre la connexió amb la seguretat d'aquest o aquell problema, els fabricants de productes basats en el nucli de Linux han de transferir contínuament totes les correccions de les noves branques estables. Però aquest treball és intensiu en mà d'obra i enfronta resistència a les empreses a causa dels temors de canvis regressius que podrien interrompre el funcionament normal del producte.
Keys Cook creu que l'única solució per mantenir el nucli assegurança a un cost raonable a llarg termini és traslladar als enginyers de pegats a les compilacions de el nucli bojal perquè treballin junts de manera coordinada per mantenir els pegats i les vulnerabilitats en el nucli ascendent. Tal com està, molts proveïdors no fan servir les últimes versions de l'nucli en els seus productes i arranjaments de backport pel seu compte, és a dir, resulta que els enginyers de diferents empreses dupliquen la feina dels altres, resolent el mateix problema.
Per exemple, si 10 empreses, cadascuna amb un enginyer que dóna suport a les mateixes correccions, reorienten a aquests enginyers per corregir errors en sentit ascendent, en lloc de migrar una correcció, podrien corregir 10 errors diferents per al benefici general o unir-se per revisar els canvis proposats. I evitar incloure codi amb errors en el nucli. Els recursos també podrien usar-se per a crear noves eines d'anàlisi de codi i proves que detectarien automàticament en una etapa primerenca les classes d'error típiques que sorgeixen una i altra vegada.
Keys Cook també proposa utilitzar de forma més activa les proves automatitzades i fuzzing directament en el procés de desenvolupament de l'nucli, utilitzar sistemes d'integració contínua i abandonar l'arcaica gestió de el desenvolupament a través de l'correu electrònic.
font: https://security.googleblog.com