C e C++ non gestiscono la memoria in modo sicuro: la Casa Bianca ne sconsiglia l'uso

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/softwa...so_124919.html

L'ONCD (Office of the National Cyber Director), l'agenzia Usa che si occupa della Cybersicurezza, ha pubblicato un documento in cui sconsiglia ufficialmente l'utilizzo dei linguaggi di programmazione C e C++ per il tipo di gestione della memoria.

Click sul link per visualizzare la notizia.

[barzokk]

Traduzione:
il vostro codice in C e C++ facciamo troppa fatica a bucarlo,
usate Rust Go e Java che ci rendete il lavoro più facile

[!fazz]

beh normale c e c++ non gestiscono la memoria punto.

è il programmatore che deve farlo a manina in modo sicuro

[matrix83]

Quanta ignoranza in un articolo. C uber alles.

[Pino90]

Né C né C++ gestiscono la memoria, sono gli sviluppatori a doverla gestire esplicitamente. Praticamente hanno detto che la maggior parte degli sviluppatori fa schifo a gestire la memoria e di conseguenza scrive programmi poco sicuri: non posso che essere d'accordo!

[lammoth]

Diciamo che con i sw che diventano sempre più complessi, anche un programmatore accorto può dimenticarsi una free dopo una malloc/calloc o una delete dopo una new e via dicendo (specie se si lavora in ambiti multithread).

Inoltre in ambito sicurezza se non si fanno i dovuti check si può essere vittima di un buffer overflow attack (https://www.imperva.com/learn/applic...ffer-overflow/).

Quello che dicono è che, a scapito di un pò di performance (perdita trascurabile se si lavora a microservizi che scalano), un linguaggio col garbage collector riduce o annulla problemi molti più gravi.

[io78bis]

Originariamente inviato da Pino90

Né C né C++ gestiscono la memoria, sono gli sviluppatori a doverla gestire esplicitamente. Praticamente hanno detto che la maggior parte degli sviluppatori fa schifo a gestire la memoria e di conseguenza scrive programmi poco sicuri: non posso che essere d'accordo!

Come dico da decenni forse ci sono milioni di persone che FANNO i programmatori ma solo qualche migliaia È un programmatore.

Certo multithreading e altre evoluzioni hanno sicuramente complicato la vita del programmatore e ad ogni modo i linguaggi devono evolversi e Rust ritengo sia un buon sostituto di C/C++. Java non credo GO forse

[bancodeipugni]

solo un americano poteva uscire con una cosa del genere...

non è il linguaggio di programmazione ad essere insicuro ma l'uso che se ne fa (male) ...

[bancodeipugni]

Originariamente inviato da io78bis

Come dico da decenni forse ci sono milioni di persone che FANNO i programmatori ma solo qualche migliaia È un programmatore.

Certo multithreading e altre evoluzioni hanno sicuramente complicato la vita del programmatore e ad ogni modo i linguaggi devono evolversi e Rust ritengo sia un buon sostituto di C/C++. Java non credo GO forse

...se uno vuole ci sono anche le funzioni thread-safe con _s alla fine, vogliono una variabile di appoggio in più ma almeno rischi meno

[Nui_Mg]

Originariamente inviato da bancodeipugni

non è il linguaggio di programmazione ad essere insicuro ma l'uso che se ne fa (male) ...

Sì ma c'è un motivo se sempre più parti di linux (kernel) stanno venendo riscritte in rust ehh.

[ZeroSievert]

Originariamente inviato da lammoth

Diciamo che con i sw che diventano sempre più complessi, anche un programmatore accorto può dimenticarsi una free dopo una malloc/calloc o una delete dopo una new e via dicendo (specie se si lavora in ambiti multithread).

Inoltre in ambito sicurezza se non si fanno i dovuti check si può essere vittima di un buffer overflow attack (https://www.imperva.com/learn/applic...ffer-overflow/).

Quello che dicono è che, a scapito di un pò di performance (perdita trascurabile se si lavora a microservizi che scalano), un linguaggio col garbage collector riduce o annulla problemi molti più gravi.

*

Mi chiedo che ripercussione abbia questa linea guida. Vuol dire che spingeranno i software usati a livello governativo o critici per la sicurezza nazionale ad usare linguaggi memory safe?

Comunque la code-base in C/C++ e' semplicemente colossale. Per rimpiazzarla, anche fosse possibile, serviranno decenni e nuove generazioni di programmatori esperti in linguaggi memory safe ad alte prestazioni.

[ripsk]

In effetti alla casa bianca al momento c'è uno dei massimi esperti mondiali di "memory leak"

[norfildur]

Il DHS (Department of Homeland Security), l'agenzia Usa che si occupa della sicurezza, ha pubblicato un documento in cui sconsiglia ufficialmente l'utilizzo dei coltelli da cucina per il tipo di gestione della lama.
Sembra infatti che, se questa è particolarmente affilata, possa cagionare ferite e addirittura la morte!
Inoltre, se arrugginita, può causare anche malattie potenzialmente letali come il tetano.
L'ufficio, dunque, ne raccomanda l'abbandono in favore di strumenti più sicuri e moderni, quali la spatola in silicone o il cucchiaio in legno.

[ZeroSievert]

Originariamente inviato da Nui_Mg

Sì ma c'è un motivo se sempre più parti di linux (kernel) stanno venendo riscritte in rust ehh.

Tra le altre cose, mentre Torvalds ha sempre messo il veto sull'uso di C++ nel kernel Linux ( che ricordiamo fino a qualche anno fa essere scritto, mi sembra, unicamente in C), ha accettato l'inclusione di Rust in relativamente poco tempo.

[Ratberg]

Si si, tutto bello... Rust, Go... voglio vedere chi converte miliardi di righe di codice in C/C++ usando poi i nuovi linguaggi. Voglio vedere soprattutto chi caccia i soldi per un lavoro del genere.

E comunque anche Rust ha i suoi problemini a detta di qualche autorevole critico (di parte si, ma autorevole):

Rust Safety Is Not Superior To C++, Bjarne Stroustrup Says

[Ratberg]

Originariamente inviato da ZeroSievert

Tra le altre cose, mentre Torvalds ha sempre messo il veto sull'uso di C++ nel kernel Linux ( che ricordiamo fino a qualche anno fa essere scritto, mi sembra, unicamente in C), ha accettato l'inclusione di Rust in relativamente poco tempo.

Anche su sta cosa la comunità dietro Linux sta discutendo:

https://www.phoronix.com/news/CPP-Li...l-2024-Discuss

[ZeroSievert]

Originariamente inviato da Ratberg

[...]
E comunque anche Rust ha i suoi problemini a detta di qualche autorevole critico (di parte si, ma autorevole):

Rust Safety Is Not Superior To C++, Bjarne Stroustrup Says

Ogni scarrafone è bell’ ‘a mamma soja

Originariamente inviato da Ratberg

Anche su sta cosa la comunità dietro Linux sta discutendo:

https://www.phoronix.com/news/CPP-Li...l-2024-Discuss

Grazie del link. C'e' da dire che, da quel che capisco, C++ diventerebbe 'sanificato' a partire dalla versione 20. Ora, non so se serve conoscere l'intero standard o basta un sottoinsieme. Resta il fatto che IMHO i programmatori che sono esperti in C++20 sono ancora un gruppo ristretto. Cosi' a naso e' un modo di programmare C++ molto diverso da quello 'classico'.

EDIT:

E come detto da Nui sotto, mentre Rust e' già nel kernel, su c++ siamo ancora al livello di proposta senza che il 'gran capo' abbia detto la sua.

EDIT 2:

A me sembra che una parte consistente dei recenti standard di C++, a partire da C++11, sia stata fatta per inseguire le novita' introdotte da altri linguaggi di programmazione. Basti vedere quanto sia diventato 'funzionale' C++ per rendersene conto. Prima le lambda e std::function, poi std::optional e std::variant, infine i concepts.. e questo solo per fare un piccolissimo numero di esempi. Sicuramente in molti casi adesso usare C++ e' piu' piacevole di un tempo.

E.g. sto usando nanobind per scrivere un binding per python di una libreria di lavoro, piena zeppa di codice legacy, e adoro le magie che si possono fare adesso con il typesystem di C++ gia' da C++17.

Resta il fatto che C++, anche se maturo e con un sacco di tool, rimane un linguaggio che per certi aspetti e' costretto a portarsi dietro un bagaglio tecnico pesante e sconta il fatto di avere feature importanti incluse solo in un secondo momento. Mentre in linguaggi piu' recenti tali features sono state pensate insieme al linguaggio e a volte il loro uso e' implicito. Ergo ho i miei dubbi che comunque venga incluso nel kernel linux a questo punto.

[F1r3st0rm]

ci sono ancora codici scritti in COBOL o FORTRAN che non riesconoa migrare perchè nessuno li consoce abbastnza bene figuraimoci migrare tutto lo scritto in C e C++ in altra roba...

[Nui_Mg]

Originariamente inviato da Ratberg

Anche su sta cosa la comunità dietro Linux sta discutendo:

https://www.phoronix.com/news/CPP-Li...l-2024-Discuss

Stanno discutendo su un subset che spazia da C++14 a C++20, mentre pezzi di rust sono già inseriti nei kernel attuali e questo per me ha il suo ben senso anche in ottica futura di mantenimento (e ci sono già degli OS scritti interamente in rust, anche quelli con microkernel), così come ha per esempio il suo senso Go (compilato e con micro-threads) per sostituire il backend dei siti web governato da linguaggi interpretati e spesso avidi di risorse.

[Ataru224]

Non sanno fare le cose e danno la colpa al linguaggio...

Che imparino a gestire la memoria invece di accampare scuse scaricando la colpa su C/C++