![\"Kis](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>La soluzione ottimale sarebbe quella di trasferire solo le correzioni e le vulnerabilit\u00e0 pi\u00f9 importanti, ma il problema principale consiste nell'identificare tali errori all'interno del flusso generale. Il numero maggiore di problemi emergenti \u00e8 il risultato dell'uso del linguaggio C, che richiede grande attenzione nella gestione della memoria e dei puntatori. A complicare la situazione c'\u00e8 il fatto che molte potenziali correzioni delle vulnerabilit\u00e0 non vengono fornite con identificatori CVE o ottengono simili identificatori solo dopo un certo periodo dalla pubblicazione della correzione. In tali condizioni, \u00e8 molto difficile per i produttori distinguere le correzioni secondarie dai problemi importanti legati alla sicurezza. Statistiche indicano che oltre il 40% delle vulnerabilit\u00e0 viene risolto prima di ottenere un CVE e in media il ritardo tra la pubblicazione della correzione e l'assegnazione del CVE \u00e8 di tre mesi (cio\u00e8 inizialmente la correzione viene percepita come un errore ordinario, ma solo dopo alcuni mesi diventa chiaro che si trattava di una vulnerabilit\u00e0 risolta).<\/p>\nDi conseguenza, non avendo un ramo separato per le correzioni delle vulnerabilit\u00e0 e non ricevendo informazioni sul legame di sicurezza di un determinato problema, i produttori di prodotti basati sul kernel Linux sono costretti a trasferire continuamente tutte le correzioni dai nuovi rami stabili. Tuttavia, questo lavoro richiede notevoli risorse e incontra resistenze nelle aziende a causa della paura di possibili cambiamenti regressivi, in grado di compromettere il normale funzionamento del prodotto.<\/p>\n
Ricordiamo che secondo Linus Torvalds, tutti gli errori sono importanti e le vulnerabilit\u00e0 non dovrebbero essere separate da altri tipi di errori e collocate in una categoria a priorit\u00e0 maggiore. Questa opinione \u00e8 motivata dal fatto che per uno sviluppatore medio, non specializzato in questioni di sicurezza, non \u00e8 chiaro il legame tra una correzione e una potenziale vulnerabilit\u00e0 (per molte correzioni solo un audit separato consente di comprendere che riguardano la sicurezza). Secondo Linus, la questione dell'individuazione delle vulnerabilit\u00e0 potenziali all'interno del flusso generale delle correzioni dovrebbe essere gestita da esperti di sicurezza delle squadre responsabili del supporto ai pacchetti del kernel nelle distribuzioni Linux.<\/p>\n
Kees Cook ritiene che l'unica soluzione per mantenere la sicurezza del kernel a costi ragionevoli a lungo termine sia il trasferimento degli ingegneri delle aziende impegnati nella portabilit\u00e0 delle patch alle versioni locali del kernel, per una collaborazione coordinata nella gestione delle patch e delle vulnerabilit\u00e0 nel kernel principale (upstream). Attualmente, molti produttori utilizzano versioni non aggiornate del kernel nei loro prodotti e portano indietro le patch con le proprie forze, il che significa che gli ingegneri di diverse aziende duplicano il lavoro l'uno dell'altro, affrontando lo stesso problema.<\/p>\n
Ad esempio, se 10 aziende, ognuna con un ingegnere impegnato nella portabilit\u00e0 delle stesse patch, reindirizzassero quegli ingegneri alla correzione di errori nell'upstream, potrebbero invece risolvere 10 diversi errori a beneficio collettivo o partecipare alla revisione delle modifiche proposte, evitando cos\u00ec l'inclusione di codice errato nel kernel. Le risorse potrebbero anche essere dirette verso la creazione di nuovi strumenti per il testing e l'analisi del codice, che consentirebbero di identificare automaticamente le classi comuni di errori che emergono ripetutamente.<\/p>\n
Kees Cook propone anche di utilizzare pi\u00f9 attivamente il testing automatizzato e il fuzzing direttamente nel processo di sviluppo del kernel, adottare sistemi di integrazione continua e abbandonare la gestione antiquata dello sviluppo tramite email. Attualmente, un'efficace attivit\u00e0 di testing \u00e8 ostacolata dal fatto che i processi di testing principali sono separati dallo sviluppo e avvengono solo dopo la creazione delle release. Kees ha anche raccomandato di utilizzare linguaggi che garantiscano una maggiore un alto livello di sicurezza<\/a>, come Rust.<\/p>\n