![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>La soluzione ottimale sarebbe trasferire solo le correzioni e le vulnerabilit\u00e0 pi\u00f9 importanti, ma isolare tali errori dal flusso generale rappresenta il problema principale. Il numero maggiore di problematiche emergenti \u00e8 il risultato dell'uso del linguaggio C, che richiede grande attenzione nella gestione della memoria e dei puntatori. La situazione \u00e8 aggravata dal fatto che molte potenziali correzioni delle vulnerabilit\u00e0 non vengono fornite con identificativi CVE o ricevono tale identificativo solo dopo un certo periodo dalla pubblicazione della correzione. In tali circostanze, per i produttori \u00e8 molto difficile distinguere le correzioni secondarie dai problemi importanti che influiscono sulla sicurezza. Secondo le statistiche, oltre il 40% delle vulnerabilit\u00e0 viene risolto prima dell'assegnazione del CVE e in media il ritardo tra il rilascio della correzione e l'assegnazione del CVE \u00e8 di tre mesi (cio\u00e8, inizialmente la correzione \u00e8 percepita come un errore comune, ma solo dopo alcuni mesi diventa chiaro che si tratta di una vulnerabilit\u00e0 risolta).<\/p>\nDi conseguenza, senza un ramo separato per la correzione delle vulnerabilit\u00e0 e senza informazioni sui legami con la sicurezza di un determinato problema, i produttori di prodotti basati sul kernel Linux devono continuamente trasferire tutte le correzioni dalle nuove versioni stabili. Tuttavia, questo lavoro richiede un grande impegno e incontra resistenze nelle aziende a causa della paura di possibili cambiamenti regressivi che potrebbero compromettere il funzionamento normale del prodotto.<\/p>\n
Ricordiamo che, secondo Linus Torvalds, tutti gli errori sono importanti e le vulnerabilit\u00e0 non dovrebbero essere separate dagli altri tipi di errori e classificate in una categoria prioritaria a parte. Questa opinione \u00e8 spiegata dal fatto che per un normale sviluppatore, che non \u00e8 specializzato in sicurezza, non \u00e8 evidente il legame tra una correzione e una potenziale vulnerabilit\u00e0 (per molte correzioni, solo un audit separato permette di capire che riguardano la sicurezza). Secondo Linus, le questioni relative all'individuazione delle vulnerabilit\u00e0 potenziali nel flusso generale delle correzioni devono essere trattate dagli specialisti della sicurezza dei team responsabili del supporto dei pacchetti con il kernel nelle distribuzioni Linux.<\/p>\n
Kis Kuk ritiene che l'unica soluzione per mantenere la sicurezza del kernel a costi a lungo termine ragionevoli sia la cooperazione tra le aziende di ingegneri impegnati nel porting delle correzioni nelle build locali del kernel. Questa collaborazione dovrebbe mirare alla gestione coordinata delle correzioni e delle vulnerabilit\u00e0 nel kernel principale (upstream). Attualmente, molti produttori utilizzano versioni non aggiornate del kernel nei loro prodotti e retroportano le correzioni autonomamente, il che porta a una duplicazione del lavoro tra gli ingegneri di diverse aziende, che si trovano a risolvere lo stesso problema.<\/p>\n
Ad esempio, se 10 aziende, ognuna con un ingegnere che si occupa del backporting delle stesse correzioni, riorientassero questi ingegneri verso la risoluzione di bug nell'upstream, potrebbero invece riparare 10 diversi bug per un beneficio comune, oppure partecipare alla revisione delle modifiche proposte per evitare l'inclusione di codice errato nel kernel. Le risorse potrebbero anche essere reindirizzate alla creazione di nuovi strumenti per il testing e l'analisi del codice, che permetterebbero di identificare automaticamente, in fase precoce, classi ricorrenti di errori che si ripresentano continuamente.<\/p>\n
Kees Cook suggerisce di utilizzare in modo pi\u00f9 attivo il testing automatizzato e il fuzzing direttamente nel processo di sviluppo del kernel, di implementare sistemi di integrazione continua e di abbandonare la gestione dello sviluppo obsoleta tramite email. Attualmente, l'efficacia del testing \u00e8 ostacolata dal fatto che i principali processi di testing sono separati dallo sviluppo e avvengono solo dopo la creazione delle versioni. Kees ha anche raccomandato di utilizzare lingue di programmazione che garantiscano maggiore alto livello di sicurezza<\/a>, come Rust.<\/p>\n