{"id":122013,"date":"2025-02-20T14:22:05","date_gmt":"2025-02-20T12:22:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/mnenie-grega-kroa-hartmana-i-kejsa-kuka-o-prodvizhenii-rust-v-yadro-linux"},"modified":"2025-02-20T14:22:05","modified_gmt":"2025-02-20T12:22:05","slug":"mnenie-grega-kroa-hartmana-i-kejsa-kuka-o-prodvizhenii-rust-v-yadro-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/mnenie-grega-kroa-hartmana-i-kejsa-kuka-o-prodvizhenii-rust-v-yadro-linux","title":{"rendered":"Il parere di Greg Kroah-Hartman e Case Cook su come promuovere Rust nel kernel Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Greg Kroah-Hartman, responsabile del supporto della versione stabile del kernel Linux, ha espresso il suo sostegno allo sviluppo di nuovi componenti del kernel in linguaggio Rust. Come figura centrale attraverso cui passano tutte le informazioni sui bug e le vulnerabilit\u00e0 del kernel Linux da 15 anni, sostiene che la maggior parte degli errori nel kernel \u00e8 causata da caratteristiche del linguaggio C che non vengono considerate (corner case), tutte completamente escluse nel codice scritto in Rust. <\/p>\n
Con l'uso di Rust, sar\u00e0 possibile mettere da parte problemi quali l'accesso alla memoria dopo il suo rilascio, il buffer overflow (in parte), una errata liberazione delle risorse in caso di gestione degli errori e il mancato controllo dei codici di ritorno degli errori, permettendo cos\u00ec ai manutentori di concentrarsi su errori reali come le condizioni di gara e problemi di logica, anzich\u00e9 disperdere l\u2019attenzione sulle piccole questioni durante la revisione. <\/p>\n
Il codice esistente in C rimarr\u00e0 dov'\u00e8, ma per il nuovo codice e i nuovi driver, l'implementazione di Rust permetter\u00e0 di migliorare notevolmente la qualit\u00e0. L'introduzione di Rust faciliter\u00e0 anche la strutturazione delle interfacce di programmazione interne del kernel, riducendo praticamente gli errori nell'uso delle API interne \u2014 nel kernel si sono accumulate troppe API complesse e confuse, che creano un grande carico di lavoro per i manutentori nel garantire che queste API vengano utilizzate correttamente. Nel processo di sviluppo dei wrapper Rust, i manutentori avranno l'opportunit\u00e0 di ripensare e mettere ordine nelle API, portando vantaggi a tutti, incluso chi utilizza il linguaggio C. <\/p>\n
Greg non considera Rust una 'palla d'argento' capace di risolvere tutti i problemi nel kernel, ma questo linguaggio sicuramente aiuter\u00e0 in un gran numero di situazioni. Il supporto per Rust soddisfer\u00e0 anche la necessit\u00e0 dei programmatori di driver, che sperano di ottenere uno strumento che consenta di scrivere codice per il loro hardware, eliminando molti tipi di errori. Per quanto riguarda la mescolanza di pi\u00f9 linguaggi, Greg non vede un grosso problema; a suo avviso, in passato i programmatori del kernel hanno affrontato compiti ben pi\u00f9 complessi, e non c'\u00e8 motivo di rifiutare l'introduzione nel kernel di nuove buone idee che possano garantire il successo del progetto per i prossimi 20+ anni. <\/p>\n
Alla discussione ha partecipato anche Kees Cook, ex amministratore di sistema di kernel.org e leader del team di sicurezza di Ubuntu. Kees ha chiarito che non si tratta di riscrivere il codice gi\u00e0 esistente nel kernel, ma di fornire la possibilit\u00e0 di utilizzare Rust per creare nuovi driver e sottosistemi. L'uso di Rust per il nuovo codice non solo ridurr\u00e0 il numero di errori nella gestione della memoria, ma accorcer\u00e0 anche i tempi di sviluppo. La velocit\u00e0 di sviluppo aumenta grazie alla diminuzione degli sforzi necessari per il debug e alla presenza nel linguaggio di garanzie rigorose che permettono di individuare errori in una fase iniziale della scrittura del codice, prima ancora dell'inizio del collaudo del prodotto. <\/p>\n
L'efficacia della strategia di utilizzo di Rust per migliorare la qualit\u00e0 del nuovo codice \u00e8 gi\u00e0 stata dimostrata da Google sulla piattaforma Android. \u00c8 stato dimostrato che la principale fonte di problemi di sicurezza \u00e8 il nuovo codice, e che la qualit\u00e0 di quest'ultimo merita una particolare attenzione. Per il codice obsoleto si osserva una dipendenza esponenziale della sicurezza dal tempo (ad esempio, il codice di 5 anni ha in media una densit\u00e0 di vulnerabilit\u00e0 3,4 volte inferiore rispetto al nuovo codice). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"