Google sponsorizza due sviluppatori per la sicurezza del kernel Linux

[woddy68]

Qualche giorno fa, proprio sulle pagine del sito della The Linux Foundation, è apparsa una notizia per cui Google, insieme alla fondazione stessa, hanno annunciato la prioritizzazione di fondi per il pagamento di due sviluppatori specifici per lo sviluppo della sicurezza del Kernel. Perchè questa scelta?

https://www.miamammausalinux.org/2021/0 ... nel-linux/

[mich85]

A parte il discorso del cambio di linguaggio, per il resto mi pare una bella notizia.

[DoctorStrange]

Hanno proposto come linguaggi Go e Swing? Non mi sembra garanzia di efficienza. Per me nel kernel si dovrebbe usare solo il C.

[Filoteo]

Hanno proposto come linguaggi Go e Swing? Non mi sembra garanzia di efficienza. Per me nel kernel si dovrebbe usare solo il C.

Go, Swift e Rust sono più sicuri del C perché gestiscono automaticamente la memoria evitando di lasciare l'onere al programmatore. Non sono altrettanto efficienti ma è il prezzo da pagare se l'alternativa sono le centinaia di bug che vengono scovati nel kernel ogni mese.

[woddy68]

Hanno proposto come linguaggi Go e Swing? Non mi sembra garanzia di efficienza. Per me nel kernel si dovrebbe usare solo il C.

Go, Swift e Rust sono più sicuri del C perché gestiscono automaticamente la memoria evitando di lasciare l'onere al programmatore. Non sono altrettanto efficienti ma è il prezzo da pagare se l'alternativa sono le centinaia di bug che vengono scovati nel kernel ogni mese.

...è possibile utilizzare altri linguaggi, quello che è stato invece respinta è l'idea di riscrivere il kernel in un altro linguaggio, ma oggi Rust, Go e Swift già vengono utilizzati.

[Filoteo]

...è possibile utilizzare altri linguaggi, quello che è stato invece respinta è l'idea di riscrivere il kernel in un altro linguaggio, ma oggi Rust, Go e Swift già vengono utilizzati.

Già vengono utilizzati? Link? Io non li ho trovati.

[woddy68]

...è possibile utilizzare altri linguaggi, quello che è stato invece respinta è l'idea di riscrivere il kernel in un altro linguaggio, ma oggi Rust, Go e Swift già vengono utilizzati.

Già vengono utilizzati? Link? Io non li ho trovati.

Non so se sono utilizzati, ma sicuramente sono utilizzabili, perlomeno così dice l'articolo

Tanti sono i linguaggi alternativi ad oggi utilizzabili (nell’articolo si citano il Rust, Go e Swift), ma cambiare in toto il linguaggio utilizzato per lo sviluppo di un progetto colossale come il kernel Linux non è ne una cosa implementabile in tempo breve, né sicuramente accettata subito di buon grado da tutti gli sviluppatori.

[DoctorStrange]

Go, Swift e Rust sono più sicuri del C perché gestiscono automaticamente la memoria evitando di lasciare l'onere al programmatore.

Non volermene ma, di solito il fatto che siano i programmatori a gestire la memoria dovrebbe essere una buona cosa.

E' per questo, che ci vogliono programmatori espertissimi per sviluppare il kernel, e non mi metto a farlo io

Ogni volta che mi sono trovato a confrontarmi con oggetti che gestivano in automatico risorse vitali come RAM, carico processore, o risorse in genere, il piu delle volte mi sono trovato fra le mani con problemi di saturazione o abuso di risorse.

I bug ci saranno sempre ma, sono convinto che il kernel linux, per come è stato concepito, sia sicuramente piu sicuro di altri sistemi operativi.

[noel80]

viewtopic.php?f=67&t=641400
(https://news.ycombinator.com/item?id=23689147)

[Filoteo]

Il C è notoriamente difficile da usare in modo sicuro e in un progetto così grande e complesso come il kernel Linux, anche i programmatori esperti commettono errori, e difatti ci sono migliaia di bug scoperti con regolarità, così tanti che solo una minima parte viene corretto nelle distribuzioni e formalmente riconosciuto come bug di sicurezza (CVE): https://events19.linuxfoundation.org/wp ... Google.pdf (senza entrare nei tecnicismi, fino a pagina 15).

[woddy68]

Il C è notoriamente difficile da usare in modo sicuro e in un progetto così grande e complesso come il kernel Linux, anche i programmatori esperti commettono errori, e difatti ci sono migliaia di bug scoperti con regolarità, così tanti che solo una minima parte viene corretto nelle distribuzioni e formalmente riconosciuto come bug di sicurezza (CVE): https://events19.linuxfoundation.org/wp ... Google.pdf (senza entrare nei tecnicismi, fino a pagina 15).

Beh però dai...stupirebbe il contrario. Nel senso che i bug ci sono in tutti i software a prescindere dal linguaggio che essi utilizzano, un software gigantesco e complicato come il kernel è ovvio che abbia molti bug, ma non conosco software che ne sia esente.
Io non sto dicendo che utilizzare un'altro linguaggio è una cattiva idea, anzi forse sarebbe meglio (non ho la competenza per dirlo), dopodiché riscrivere un kernel come quello di Linux in un altro linguaggio, occorre capire se i benefici giustificano lo sforzo.
Immagino poi che molti sviluppatori del kernel, abbiano più confidenza con il linguaggio attuale, quindi anche questo è un aspetto da valutare.

[noel80]

Con la 5.9 ci dovrebbe seere anche quello che e' sattato fuori dalla questione "GPL condom"...
(non so' quale sia il sito opinionista o opinabile preferibile ) https://techtudor.blogspot.com/2020/08/ ... idias.html

[woddy68]

Con la 5.9 ci dovrebbe seere anche quello che e' sattato fuori dalla questione "GPL condom"...
(non so' quale sia il sito opinionista o opinabile preferibile ) https://techtudor.blogspot.com/2020/08/ ... idias.html

Di fatto è già realtà, visto che siamo al kernel 5.11, e a parte qualche problema per gli utenti Nvidia che utilizzano CUDA, non ho sentito di altri problemi. Anche il discorso CUDA oggi sembra risolto.
Quindi ho l'impressione che certi blog esagerino ... certo, ci sono stati alcuni problemi iniziali con il modulo CUDA, ma era disponibile fin da subito una patch. Dopodichè un utente Linux, dovrebbe essere consapevole dell'incompatibilità di licenza del binario Nvidia con Linux, non è una novità, per anni hanno lasciato correre questa "incompatibilità" , Nvidia era stata avvisata per tempo di questo cambiamento.

[noel80]

Con la 5.9 ci dovrebbe seere anche quello che e' sattato fuori dalla questione "GPL condom"...
(non so' quale sia il sito opinionista o opinabile preferibile ) https://techtudor.blogspot.com/2020/08/ ... idias.html

Di fatto è già realtà, visto che siamo al kernel 5.11, e a parte qualche problema per gli utenti Nvidia che utilizzano CUDA, non ho sentito di altri problemi. Anche il discorso CUDA oggi sembra risolto.
Quindi ho l'impressione che certi blog esagerino ... certo, ci sono stati alcuni problemi iniziali con il modulo CUDA, ma era disponibile fin da subito una patch. Dopodichè un utente Linux, dovrebbe essere consapevole dell'incompatibilità di licenza del binario Nvidia con Linux, non è una novità, per anni hanno lasciato correre questa "incompatibilità" , Nvidia era stata avvisata per tempo di questo cambiamento.

Scusa uno potrebbe anche sbattesi di che licenza sia, magari non li vuole "semplicemente", cose di Nvidia, suggerite al tempo da un developer di Facebook, nel kernel.
(Mi sembra un conto diverso quando si vuole installarsi i driver proprietari)
Btw: https://jxself.org/linux-libre/
https://www.fsfla.org/ikiwiki/selibre/linux-libre/

[woddy68]

Il discorso lo dovresti conoscere...se comperi hardware che utilizza driver proprietari, spetta al tuo fornitore, fornire i driver, non certo a Linux che si preoccupa solo del kernel e dei driver che in essi vengono mantenuti.
Con la 5.9 ci dovrebbe seere anche quello che e' sattato fuori dalla questione "GPL condom"...
(non so' quale sia il sito opinionista o opinabile preferibile ) https://techtudor.blogspot.com/2020/08/ ... idias.html

Di fatto è già realtà, visto che siamo al kernel 5.11, e a parte qualche problema per gli utenti Nvidia che utilizzano CUDA, non ho sentito di altri problemi. Anche il discorso CUDA oggi sembra risolto.
Quindi ho l'impressione che certi blog esagerino ... certo, ci sono stati alcuni problemi iniziali con il modulo CUDA, ma era disponibile fin da subito una patch. Dopodichè un utente Linux, dovrebbe essere consapevole dell'incompatibilità di licenza del binario Nvidia con Linux, non è una novità, per anni hanno lasciato correre questa "incompatibilità" , Nvidia era stata avvisata per tempo di questo cambiamento.

Scusa uno potrebbe anche sbattesi di che licenza sia, magari non li vuole "semplicemente", cose di Nvidia, suggeIl discorso lo dovresti conoscere...se comperi hardware che utilizza driver proprietari, spetta al tuo fornitore, fornire i driver, non certo a Linux che si preoccupa solo del kernel e dei driver che in essi vengono mantenuti.rite al tempo da un developer di Facebook, nel kernel.
(Mi sembra un conto diverso quando si vuole installarsi i driver proprietari)

Certo, quindi dovrebbero chiedere conto al loro fornitore hardware-driver.
Se io compero una stampante HP, spetta a HP distribuire i driver, che nel caso siano con licenza open, possono essere inclusi nel kernel, in caso contrario andranno installati post.
A me non cambia niente ? Non proprio, perché se i driver sono open sono nel kernel e già pronti out-the-box, in caso contrario dovrò installarli manualmente.
Nessun utente Nvidia si accorgerà di questo, se non gli utenti delle distribuzioni rolling, dove comunque è sconsigliato l'uso di driver proprietari o comunque devono prendere precauzioni, perché la compatibilità tra il kernel e il binario Nvidia non è immediata e scontata per cui è possibile trovarsi con un driver rotto.

[iononsbalgiomai]

Google spinge verso Rust:

• Google vuole un po’ di Mozilla in Linux per migliorare la sicurezza degli smartphone
• Rust in the Linux kernel

[woddy68]

Google spinge verso Rust:

• Google vuole un po’ di Mozilla in Linux per migliorare la sicurezza degli smartphone
• Rust in the Linux kernel

Sono un po' confuso, Google non ha in mente di passare al loro kernel Fuchsia ? Perlomeno così si vocifera https://www.wired.it/mobile/app/2021/05 ... efresh_ce=
Certo Android resterà su kernel Linux, ma da quello che ho capito, il futuro è lì, occorre però capire quanto il futuro sia vicino o lontano.
E' vero anche che ChromeOS rimarrà molto probabilmente su Linux.

[iononsbalgiomai]

Google ha mille idee in testa e ogni tanto ne scarta una. Credo che ancora non abbiano capito cosa farci con Fucsia. Se mai arriverà su smartphone, se ne parlerà fra anni.

[woddy68]

Google ha mille idee in testa e ogni tanto ne scarta una. Credo che ancora non abbiano capito cosa farci con Fucsia. Se mai arriverà su smartphone, se ne parlerà fra anni.

Beh! Fortunatamente è un progetto comunque open source e si sa...nell'open source non si butta via niente.

[FaraoneGold]

Secondo me sono le solite storielle per far credere che grazie a google "Linux" è più sicuro.... perchè alla fine 2 sviluppatori contro miliardi di persone ... la vedo un po' drastica.