La NSA sconsiglia l’uso di C e C++ come linguaggio e Bjarne Stroustrup risponde per le rime!

6

Bjarne Stroustrup è un nome poco noto al grande pubblico, eppure è quasi sicuro che ogni giorno utilizziate un programma scritto nel linguaggio di cui è il papà.

Stroustrup, infatti, è l’ideatore di C++. Pensato come superset del linguaggio C per dotare quest’ultimo della programmazione orientata agli oggetti, dagli anni novanta è stato utilizzato per scrivere la vasta maggioranza dei programmi che usiamo oggi. Chrome, Firefox, Adobe e l’intero KDE-Plasma sono scritti in C++, giusto per citarne alcuni.

Oggetto dell’articolo di oggi è la risposta data da Stroustrup alla pubblicazione delle nuove linee guida di sviluppo per chi produce software per NSA, la National Security Agency. Nel rapporto, si dice:

Commonly used languages, such as C and C++, provide a lot of freedom and flexibilityin memory management while relying heavily on the programmer to perform the needed checks on memory references. Simple mistakes can lead to exploitable memory-based
vulnerabilities. Software analysis tools can detect many instances of memory management issues and operating environment options can also provide some protection, but inherent protections offered by memory safe software languages can prevent or mitigate most memory management issues. NSA recommends using a memory safe language when possible

Linguaggi comunemente utilizzati, come C e C++, forniscono molta libertà e flessibilità circa la gestione della memoria, ma dipendono pesantemente sul programmatore circa l’effettuare i controlli necessari sui puntatori nella memoria. Semplici errori possono condurre a vulnerabilità basate sulla memoria sfruttabili (a un attacco informatico, ndr).
Software di analisi possono individuare diverse situazioni problematiche nella gestione della memoria e alcune opzioni dell’ambiente operativo possono fornire una qualche protezione, ma protezioni integrate offerte da linguaggi memory safe possono prevenire o mitigare la maggior parte dei problemi legati alla gestione della memoria. La NSA raccomanda di usare un linguaggio memory safe quando è possibile.
Bjarne Stroustrup
Bjarne Stroustrup, il padre del C++

La reazione di Stroustrup non si è fatta attendere e in un articolo ha difeso la sua creatura e gli sforzi fatti negli anni per rendere il C++ un linguaggio più sicuro. Per chi si è fermato agli anni ’90, ricordo alcune innovazioni presenti nel linguaggio:

  1. gli smart-pointer per gestire la memoria: new e delete sono cose del passato;
  2. le librerie ufficiali per gestire i thread e i relativi lock;
  3. std::vector, std::map e std::string rimpiazzano le vecchie e insicure strutture dati e le stringhe ereditate dal C;
  4. un memory-model da C++14 (spiegazione nel link);
  5. il construtto foreach per iterare su tutti gli elementi di una struttura dati senza doversi preoccupare delle condizioni di uscita, come sarebbe con for e con while;
  6. la keyword auto che permette di dichiarare una variabile senza specificarne il tipo. Utile quando avete da gestire tanti template annidati:
// una dichiarazione lunghissima...
std::unique_ptr<std::map<std::string,std::shared_ptr<MyObject>> = std::make_unique(std::map<std::string,std::shared_ptr<MyObject>>); 

// ...diventa così!
auto mymap = std::make_unique(std::map<std::string,std::shared_ptr<MyObject>>);

// e per effettuare un ciclo su questa struttura dati, avremmo
foreach(auto m : mymap) {
    auto value = m.second;
   ...
}
// anziché lavorare direttamente con gli iteratori

Insomma, tanta roba, tant’è che Stroustrup lo dice in una risposta pubblicata online a difesa della sua creatura.

I have worked for decades to make it possible to write better, safer, and more efficient C++.

Ho lavorato per decenni per rendere possibile lo scrivere migliore, più sicuro e più efficiente (software, nrd) C++

Che il C++ sia cambiato tantissimo negli ultimi anni è un fatto: solo con i costrutti introdotti dallo standard nel 2011, abbiamo la possibilità di evitare completamente i temuti memory leaks e di avere una sintassi che è più vicina a noi. Quindi, perché NSA non ha ammesso il C++ tra i linguaggi adatti ai suoi scopi?

Per chi lavora con C++ ogni giorno il problema è probabilmente legato alla forma mentis di chi utilizza questo linguaggio: esistono discussioni se sia più veloce in esecuzione l’uso di un puntatore unique o shared, quando la differenza non si misura nemmeno in millisecondi, ma in frazioni di millisecondo. Lo stesso succede quando si trovano persone che preferiscono l’uso di atomic piuttosto che di un mutex per gestire la sezione critica, quando la differenza si potrebbe notare solo in ambiti hard real-time e mission critical del calibro di radar militari, centrali nucleari e sottomarini.

Per esperienza, se pensate di utilizzare il C++ per il vostro prossimo progetto, fate pure: il linguaggio è solido, ha milioni di librerie e con le features moderne è anche ragionevolmente memory safe. Ma non effettuate ottimizzazioni premature con costrutti che mettono a repentaglio la stabilità del programma. Le ottimizzazioni si fanno dopo aver misurato dove si trovano i colli di bottiglia.

Dopotutto, tutti i fan del C++ sanno usare Valgrind, vero? 🙂

Appassionato di GNU/Linux dal 2000, tento disperatamente di tenermi distante dalla programmazione web e di sviluppare in C/C++ e Python i software che mi vengono commissionati.

6 risposte a “La NSA sconsiglia l’uso di C e C++ come linguaggio e Bjarne Stroustrup risponde per le rime!”

  1. Avatar Mauro Miatello
    Mauro Miatello

    credo che in genere non sia tanto un problema di strumento ma di saperlo usare… sono 25 anni che sento sti discorsi, e poi scopri che, semplicemente, chi ha fatto il casino è perché non sapeva o non aveva tempo di farlo meglio.

  2. Avatar Alessandro Scarozza
    Alessandro Scarozza

    (credo che) il problema è che non esiste un flag di compilazione che escluda i costrutti non sicuri. a quel punto per un organizzazione basterebbe dire che quel flag sia obbligatorio. non so se mi sono spiegato

  3. Avatar Raoul Scarazzini

    E soprattutto che il 90% dei problemi di sicurezza son legati a cose tipo le password scritte sui post-it 🙂

  4. Avatar Raoul Scarazzini

    Penso che la problematica principale sia stabilire quali sono i costrutti non sicuri. La discriminante è sempre soggettiva.

  5. Avatar JaK
    JaK

    Se posso azzardarmi (su LinkedIn con questa proposta mi hanno mangiato vivo), suggerirei

    1. Puntatori raw
    2. structs
    3. funzioni di libreria ereditate dal C

    In un programma C++, si dovrebbero chiudere queste entità in un blocco “unsafe”, come accade anche per Rust e C#.

    Ma è solo un’idea.

  6. Avatar Alessandro Scarozza
    Alessandro Scarozza

    appunto mi piacerebbe avere una linea guida dal team dietro al compilatore, gia esiste qualcosa di simile Wall o Wextra. intendo qualcosa del genere, ma un po piu restrittivo.

    ovviamente opzionale

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *