Link alla notizia: https://www.hwupgrade.it/news/software-business/c-e-c++-non-gestiscono-la-memoria-in-modo-sicuro-la-casa-bianca-ne-sconsiglia-l-uso_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.

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 :asd:

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

è il programmatore che deve farlo a manina in modo sicuro

Quanta ignoranza in un articolo. C uber alles.

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! :D

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/application-security/buffer-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.

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! :D

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

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

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

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 :fagiano: :sofico:

non è il linguaggio di programmazione ad essere insicuro ma l'uso che se ne fa (male) ... :stordita:
Sì ma c'è un motivo se sempre più parti di linux (kernel) stanno venendo riscritte in rust ehh.

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/application-security/buffer-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.

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

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.

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.

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 (http://tinyurl.com/yxx9j3j2)

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-Linux-Kernel-2024-Discuss

[...]
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 (http://tinyurl.com/yxx9j3j2)

Ogni scarrafone è bell’ ‘a mamma soja :asd:

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

https://www.phoronix.com/news/CPP-Linux-Kernel-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 (https://github.com/wjakob/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.

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...

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

https://www.phoronix.com/news/CPP-Linux-Kernel-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.

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

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

Microsoft ha abbandonato C++? Da quando? A me risulta che buona parte del loro software commerciale e non sia scritto in C++, ma potrebbero essere cambiate le cose... A parte ciò, mi sembra una semplificazione che ha poco se non addirittura nessun senso; senza garbage collector è possibile gestire la memoria anche "meglio" del garbage collector, tutto sta all'abilità del programmatore e anche a n altri fattori...boh mi sembra una semplificazione che lascia il tempo che trova.

Java.
Cioè, Java?

Java.
Cioè, Java?
Java? Lascialo nell'enterprise...

proprio qualche giorno fa su un canale youtube (credo BGE) dicevano che alla fine ci sono lobby del software che lavorano nei meandri governativi negli States, quindi niente di nuovo su queste uscite

Il concetto di memory safety non c'entra nulla con garbage collector, Rust infatti è memory safe pur non avendo un garbage collector. Inoltre l'esempio del problema del "memory leak" non lo trovo pertinente e non lo trovo nemmeno menzionato nel report originale.

Se si legge il documento reso pubblico, si vede che i linguaggi memory safe sono solo una delle indicazioni:
- Memory Safe Programming Languages
- Memory Safe Hardware
- Formal Methods
- Challenges with Software Measurability
- Applications of Cybersecurity Quality Metrics
- Shifting Market Forces to Improve Cybersecurity Quality

Anche Rust e Java non sono così "sicuri" come alcuni pensano, senza contare che già in passato il DoD (Ministero della Difesa) USA aveva cercato di spingere l'uso di un linguaggio "più sicuro" (l'Ada) senza riuscire più di tanto a far presa sul mercato.

Paradossalmente ora Ada 2022 ed i suoi sottoinsiemi SPARK e Ravenscar sarebbero l'opzione migliore per le esigenze di sicurezza ed affidabilità richieste, ma sono utilizzati solo da alcune aziende del settore militare, aerospaziale e ferroviario.

Per chi sostiene che "non é colpa del linguaggio ma di chi lo usa", state confermando proprio il punto che si sta sostenendo. Se l'affidabilitá e sicurezza di un linguaggio dipendono dall'uso che se ne fa, allora il linguaggio NON é sicuro.
Si faceva l'esempio sarcastico dei coltelli. E c'é infatti una ragione per cui non dai coltelli da cucina ai bambini, perché NON sono sicuri.

Il C/C++ l'ho sempre usato volentieri, é il mio primo linguaggio e quello in cui sviluppo il mio path tracer per divertimento, ma é impossibile non riconoscere che la libertá che offre nell'uso della memoria e negli accessi ha un prezzo.

John Carmack é considerato uno dei migliori programmatori in circolazione, il codice della vecchia ID Software era considerato generalmente molto pulito e scritto in maniera eccellente, eppure una delle prime versioni di Quake aveva un buco che permetteva accessi in root da remoto (o qualcosa del genere, vado a memoria).
E se Carmack non é riuscito ad evitarlo su un codice tutto sommato limitato come quello, figuriamoci programmatori normali su codici di milioni di righe.

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 :asd:

Pienamente daccordo. Con il c sono io che controllo tutto. Se scrivo bene il codice questo sarà solido.
In java ed affini ci si deve appoggiare a strati di sw di cui non si ha il minimo controllo...... e sicuramente ci saranno backdore e simili........
Se il programmatore sa fare il suo lavoro c e c++ sono i migliori secondo me.

Certo che se molti non si preoccupano di liberare la memoria e lavorano di fretta e male......... di certo questo non è colpa del linguaggio ma del programmatore.

Il problema non e' il linguaggio, ma il codice demmer@a scritto. Fra l'altro e' possibilissimo avere memory leak anche in Rust (tuttavia mai visti di persona perche' nessuno usa ancora Rust nel mio ambiente), e di sicuro ne ho visti parecchi anche in Java.

Io non faccio statistica, ma nella mia esperienza ho visto piu' problemi di memoria con java che non con il C++ nei progetti in cui ero coinvolto; credo per il fatto che quando ti insegnano i linguaggi all'universita', con il C++ ti fanno gia' il culo con gestione delle risorse etc, mentre quando studi Java ti dicono che puoi stare piu' rilassato, e quindi poi cominciando a lavorare, i programmatori C++ pongono molta piu' attenzione alla cosa.

Fare del codice memory safe in C++ fra l'altro e' diventato molto piu' semplice con i nuovi standard, a partire dagli smart pointer, alle tecniche che proprio evitano l'utilizzo dei puntatori, come ad esempio usare lo std::visit per il polimorfismo statico, evitando di avere classi derivate che vengono memorizzati in puntatori di classi base. Altre tecniche diventate molto popolari, come l'idioma RAII, ti permette di gestire facilmente e con minima probabilita' di errore la gestione della memoria e delle risorse in generale.

Poi, e' vero che C++ permette molte piu' liberta' sull'uso della memoria e dei puntatori, arrivando ad obbrobri come dynamic_cast che secondo me prima lo deprecano meglio e', oltre al fatto che in C e C++ e' molto piu' facile che uno diventi un three star programmer (https://wiki.c2.com/?ThreeStarProgrammer) a cui lo standard dovrebbe prevedere il taglio delle mani, ma con l'esperienza, utilizzando c++ moderno etc, e' molto piu' difficile fare programmi che crashano miseramente. Personalmente ho fatto un programma per un simulatore tutto in C++20 e fra i piu' di 80 processi che girano su quei pc e' l'unico che non crasha mai (mi hanno riferito un uptime di 140 giorni l'ultima volta), e fra gli altri spunta addirittura un processo fatto in ADA che crasha quasi giornalmente, il che dimostra che non e' il linguaggio che crea sicurezza, ma come scrivi e progetti il tuo programma. Il linguaggio ti puo' dare degli strumenti piu' potenti rispetto ad altri, ma se li usi male il risultato non cambia.

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.

Giustissimo ma, per dovere di cronaca, il veto non e' stato messo per un discorso di sicurezza del codice (altrimenti manco si parlerebbe di avere un kernel in C, che di sicuro non e' piu' robusto del C++). Il problema invece e' dovuto ai compilatori, ed alla gestione del mangling dei nomi delle classi e via dicendo.

In pratica, se tu fai una libreria in C con un compilatore, puoi linkare quella libreria pure con una versione diversa di quel compilatore, o con un compilatore del tutto diverso; fare la stessa cosa in C++ e' molto piu' difficile sia per come vengono compilate le librerie (prova ad aprire una .dll fatta in c++ con dependency walker e vedi che nomi ci sono), sia perche' l'ABI (Application Binary Interface) non e' garantita se il compilatore e' diverso, ad esempio per i metodi che hanno come argomento i template (std::string su tutti). Addirittura puoi avere lo stesso problema su versioni diverse dello stesso compilatore, ed e' stato infatti uno dei punti di svolta di Visual Studio a partire dalla versione 2015, dove da quella versione in poi hanno confermato la compabilita' ABI, e quindi puoi linkare adesso una libreria fatta con Visual Studio 2015 in un progetto fatto con Visual Studio 2022 senza dover ricompilare la libreria.

Personalmente ho sempre visto la cosa con sospetto, perche' magari limitavi le modifiche dei compilatori piu' moderni per mantenere la compatilibita', e se io voglio lavorare su un progetto con librerie di un compilatore precedente mi limito ad usare quel compilatore, ma evidentemente l'industria generale non la pensa cosi'.

E la compabilita' ABI e' il motivo principale per cui il C++ ha ancora in stl una libreria regex con prestazioni che fanno pena, e cavolate assurde come il jthread, che poteva tranquillamente essere un update al thread normale. A dire il vero mandai una volta una bella mail alla committee del C++ (https://www.open-std.org/JTC1/SC22/WG21/) (avevo un'oretta da perdere perche' dovevo ricompilare da zero un progetto fatto da gente che non conosce gli header precompilati) sul fatto che rompono troppo le balle sulla compabilita' ABI e che dovrebbero di tanto in tanto romperla per portare avanti per bene lo standard, ma "non" stranamente non ricevetti nessuna risposta...

Microsoft ha abbandonato C++? Da quando? A me risulta che buona parte del loro software commerciale e non sia scritto in C++, ma potrebbero essere cambiate le cose... A parte ciò, mi sembra una semplificazione che ha poco se non addirittura nessun senso; senza garbage collector è possibile gestire la memoria anche "meglio" del garbage collector, tutto sta all'abilità del programmatore e anche a n altri fattori...boh mi sembra una semplificazione che lascia il tempo che trova.

Microsoft utilizza C++ dappertutto e in maniera cosi' pesante che si sono fatti i loro tool per la gestione di progetti con molto C++, ad esempio in Office:

https://www.youtube.com/watch?v=0QtX-nMlz0Q

Da quando Google ha abbandonato C++? Tensorflow ad esempio lo usa eccome. Molte operazioni di basso livelli sono ancora fatte in C/C++, quindi magari stiamo usando framework Python, ma indirettamente, se si va a vedere tutta la catena, si richiamano cose C/C++.

Anche Pytorch (Meta) fa così, il backend è tutto o quasi C++.

Che il codice RUST possa avere qualche vantaggio di sicurezza è possibile. Java? ahahahahahh

...

Concordo con quanto hai scritto. Volevo semplicemente dire che finora, al contrario di Rust, la comunita' linux non ha reputato che i vantaggi di C++ fossero sufficienti a permettere l'inclusione dello stesso nel kernel. Il discorso non era limitato alla sola sicurezza visto che, come tu hai scritto, C e' a sua volta memory-unsafe.

Comunque non so se il problema sia solo il name-mangling. Leggendo i (datati) rant di Torvalds (http://harmful.cat-v.org/software/c++/linus) sembra che non gli piaccia proprio il linguaggio cosi' com'e'. Vediamo se e come rispondera' alle proposte di inserire C++ nel kernel linux 20 anni dopo.

E anche dall'articolo postato sopra da Ratberg

https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss

Sembra che il problema maggiore sia il linguaggio invece che l'ABI. Anche perche' per un progetto come il linux kernel, immagino possano fissare un'ABI stabile esattamente come nell'esempio di Visual Studio che tu hai fatto.

EDIT:

Tra le altre cose, il problema di avere un'ABI stabile per il kernel linux si pone, da quello che so, solo per l'interfaccia utente. E dubito che, indipendentemente dal linguaggio usato, linux abbandoni un'API/ABI utente simil-C. E, come sicuramente sai, con C++ e' possibile forzare l'ABI delle funzioni ad usare la C calling convention (https://learn.microsoft.com/en-us/cpp/cpp/extern-cpp?view=msvc-170). Discorso diverso e' l'interfaccia interna dove ne API ne ABI sono stabili (che poi e' il motivo per cui i driver distribuiti in forma binaria sono una pena da usare su linux). Ergo non vedo l'uso di C++ nel kernel linux come un problema insormontabile dal punto di vista tecnico. Il problema piu' grosso IMHO e' di design e di gestione del progetto.

...

Tutto possibilissimo. Non mi sono mai messo a cercare tutte le informazioni a riguardo, ma so che uno dei motivi per ostacolare l'adozione del C++ era il mangling, ma ovviamente non sara' l'unico motivo, ne' quello piu' importante.

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

https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss

Ok, lungi da me volere sembrare aggressivo, ma sono sterili polemiche basate su battute classiche. Il fatto è che non è detto che i detrattori di C++ abbiano ragione. E chi l'ha deciso? Io uso C++ dallo Zortech 1.0 sotto DOS. Ne ha fatta di strada il linguaggio nel frattempo. Se mi si dice che ha molti idiomi da imparare ed è difficile da dominare (lo stesso Stroustrup ha ammesso di non conoscerlo tutto) mi sta bene. Ma che sia intrinsecamente insicuro è una putt....a pazzesca. Un po' di disciplina quando si programma non guasterebbe.

[QUOTE=ZeroSievert;48456130][I]
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:

Prego.

Comunque più che il C++ ad essere "sanificato" sono gli idiomi migliori che si possono adoperare. C++23 è già una realtà e può già essere usato (anche se per quanto mi riguarda sono bloccato a C++17 per questioni di tool).

Detto questo, se si cominciano a fare check runtime "a tutta randa" poi non è più C++. La disciplina e il pensare prima a cosa si fa aiuta molto. La progettazione strutturale di un algoritmo, l'utilizzo di cose vecchie ma buone come SOLID (se uno va giù pesante di OOP è indispensabile) o non abusare di certe caratteristiche aiuta parecchio. Dalla mia esperienza ultratrentennale le cose peggiori sono causate dagli UB (undefined behaviour). Gli UB nello standard sono tutti (o quasi, almeno quelli che si conoscono) esplicitati. Si, è vero, lo standard è scritto in standardese, che è un casino porco, ma è pieno di guide e manuali che insegnano a non maltrattare il linguaggio.

Se uno vuole stare tranquello ci sono altri strumenti. Ma se poi il codice deve girare su robine tipo "arduino" dalle risorse nulle, c'è poco che va bene come C e C++.

E ancora IBM sui maniframe lo usa. Poi, per carità, bisogna stare attenti. Ma anche quando si maneggia una sega circolare o la dinamite bisogna stare attenti. Anche ad andare in giro per strada bisogna stare attenti.

Il C++ è una metafora della vita...

Detto ciò uso anche altro, ma mi sono un po' rotto gli zebedei di sentire, da parte di gente poco pratica, che C++ fa cag..e.

Non so voi...

facciamo tutto in python e sia :fagiano: :cool: