Che cos'è un linguaggio di programmazione sicuro?

I linguaggi di programmazione sicura (PL) stanno guadagnando popolarità. Mi chiedo quale sia la definizione formale di PL sicuro. Ad esempio, C non è sicuro, ma Java è sicuro. Ho il sospetto che la proprietà "sicura" dovrebbe essere applicata a un'implementazione PL piuttosto che al PL stesso. In tal caso, discutiamo una definizione di implementazione di PL sicura. I miei tentativi di formalizzare questa nozione hanno portato a uno strano risultato, quindi vorrei sentire altre opinioni. Per favore, non dire che ogni PL ha comandi non sicuri. Possiamo sempre prendere un sottoinsieme sicuro.

Quando in qualche modo chiamiamo una lingua "sicura" , ciò significa formalmente che c'è una prova che nessun programma ben strutturato nella lingua può fare qualcosa che consideriamo pericoloso. Anche la parola "sicuro" è usata in modo meno formale, ma è quello che le persone qui comprendono la tua domanda. Esistono molte diverse definizioni di proprietà che vogliamo avere un linguaggio “sicuro”.

Alcuni importanti sono:

• La definizione di "solidità del tipo" di Andrew Wright e Matthias Felleisen , che è citata in molti luoghi (tra cui Wikipedia) come una definizione accettata di "sicurezza del tipo" e la loro prova del 1994 che un sottogruppo di ML la soddisfa.

• Michael Hicks elenca qui diverse definizioni di "sicurezza della memoria" . Alcuni sono elenchi di tipi di errori che non possono verificarsi e altri si basano sul trattamento dei puntatori come funzionalità. Java garantisce che nessuno di questi errori è possibile (a meno che non si usi esplicitamente una funzione contrassegnata unsafe) facendo in modo che un garbage collector gestisca tutte le allocazioni e le deallocazioni. Rust offre la stessa garanzia (di nuovo, a meno che tu non contrassegni esplicitamente il codice come unsafe), attraverso il suo sistema di tipo affine, che richiede che una variabile sia posseduta o presa in prestito prima di essere utilizzata al massimo una volta.

• Allo stesso modo, il codice thread-safe è di solito definito come codice che non può mostrare determinati tipi di bug che coinvolgono thread e memoria condivisa, tra cui corse di dati e deadlock. Queste proprietà sono spesso applicate a livello di linguaggio: Rust garantisce che non si possano verificare corse di dati nel suo sistema di tipi, C ++ garantisce che i suoi std::shared_ptrpuntatori intelligenti sugli stessi oggetti in più thread non elimineranno prematuramente un oggetto o non lo elimineranno quando l'ultimo riferimento quando viene distrutto, C e C ++ hanno anche atomicvariabili integrate nel linguaggio, con operazioni atomiche garantite per far rispettare determinati tipi di coerenza della memoria se usate correttamente. MPI limita la comunicazione tra processi a messaggi espliciti e OpenMP ha una sintassi per garantire che l'accesso a variabili da thread diversi sia sicuro.

• La proprietà che la memoria non perderà mai è spesso chiamata safe-for-space. La garbage collection automatica è una caratteristica della lingua per garantire ciò.

• Molte lingue hanno la garanzia che le sue operazioni avranno risultati ben definiti e che i suoi programmi saranno ben educati. Come il supercat ha fornito un esempio di quanto sopra, C fa questo per l'aritmetica senza segno (garantito per essere avvolto in modo sicuro) ma non per l'aritmetica firmata (dove l'overflow è autorizzato a causare bug arbitrari, poiché C aveva bisogno di supportare CPU che fanno cose completamente diverse quando firmano l'aritmetica trabocca), ma a volte la lingua converte silenziosamente quantità non firmate in quantità firmate.

• I linguaggi funzionali hanno un gran numero di invarianti che qualsiasi programma ben formato garantisce, ad esempio, che le funzioni pure non possano causare effetti collaterali. Questi possono o meno essere descritti come "sicuri".

• Alcune lingue, come SPARK o OCaml, sono progettate per facilitare la dimostrazione della correttezza del programma. Ciò può essere o meno descritto come "sicuro" da bug.

• Prove che un sistema non può violare un modello di sicurezza formale (da cui la battuta "Qualsiasi sistema che sia dimostrabilmente sicuro probabilmente non lo è.")

Non esiste una definizione formale di "linguaggio di programmazione sicuro"; è una nozione informale. Piuttosto, le lingue che affermano di fornire sicurezza di solito forniscono una dichiarazione formale precisa del tipo di sicurezza che viene richiesto / garantito / fornito. Ad esempio, la lingua potrebbe fornire sicurezza dei tipi, sicurezza della memoria o altre garanzie simili.

Se riesci a mettere le mani su una copia dei tipi e dei linguaggi di programmazione di Benjamin Pierce , nell'introduzione, ha una buona panoramica di varie prospettive sul termine "linguaggio sicuro".

Una proposta di interpretazione del termine che potresti trovare interessante è:

"Una lingua sicura è completamente definita dal suo manuale del programmatore". Lascia che la definizione di una lingua sia l'insieme di cose che il programmatore deve comprendere per prevedere il comportamento di ogni programma nella lingua. Quindi il manuale per un linguaggio come C non costituisce una definizione, dal momento che il comportamento di alcuni programmi (ad esempio quelli che coinvolgono accessi di array non controllati o aritmetica del puntatore) non può essere previsto senza conoscere i dettagli di come un particolare compilatore C espone strutture in memoria , ecc., e lo stesso programma può avere comportamenti abbastanza diversi quando eseguito da compilatori diversi.

Quindi, esiterei a usare il termine "non sicuro" per fare riferimento a un'implementazione del linguaggio di programmazione. Se un termine indefinito in una lingua produce un comportamento diverso in diverse implementazioni, una delle implementazioni potrebbe comportare comportamenti che potrebbero essere più attesi, ma non lo definirei "sicuro".

Sicuro non è binario, è un continuum .

Informalmente parlando, la sicurezza si intende dall'opposizione ai bug, i 2 più spesso citati sono:

• Sicurezza della memoria: il linguaggio e la sua implementazione impediscono una varietà di errori relativi alla memoria come l'uso dopo l'uso, doppio libero, fuori limite, ...
• Sicurezza del tipo: il linguaggio e la sua implementazione impediscono una varietà di errori relativi al tipo come caselle non controllate, ...

Quelle non sono le uniche classi di bug che le lingue impediscono, la libertà della corsa dei dati o la libertà dello stallo è piuttosto desiderabile, le prove della correttezza sono piuttosto dolci, ecc ...

Raramente i programmi semplicemente errati sono considerati "non sicuri" (solo buggy) e il termine sicurezza è generalmente riservato alle garanzie che incidono sulla nostra capacità di ragionare su un programma. Pertanto, C, C ++ o Go, con comportamento indefinito, non sono sicuri.

E, naturalmente, ci sono lingue con sottoinsiemi non sicuri (Java, Rust, ...) che delineano intenzionalmente le aree in cui lo sviluppatore è responsabile del mantenimento delle garanzie linguistiche e il compilatore è in modalità "hands-off". Le lingue sono ancora generalmente soprannominate sicure , nonostante questo trampolino di fuga, una definizione pragmatica.

Anche se non sono in disaccordo con la risposta di DW, penso che lasci una parte di "sicura" senza indirizzo.

Come notato, ci sono più tipi di sicurezza promossi. Credo che sia bene capire perché ci sono più nozioni. Ogni nozione è associata all'idea che i programmi soffrano soprattutto di una certa classe di bug e che i programmatori non sarebbero in grado di fare questo specifico tipo di bug se la lingua impedisse al programmatore di farlo.

Va notato che queste diverse nozioni hanno quindi diverse classi di bug e queste classi non si escludono a vicenda né coprono tutte le forme di bug. Solo per prendere i 2 esempi di DW, la domanda se una determinata posizione di memoria contiene un determinato oggetto è sia una questione di sicurezza del tipo che di memoria.

Un'ulteriore critica ai "linguaggi sicuri" deriva dall'osservazione che vietare determinati costrutti ritenuti pericolosi lascia al programmatore la necessità di trovare alternative. Empiricamente, la sicurezza è raggiunta meglio da buone biblioteche. l'utilizzo di codice già testato sul campo ti evita di creare nuovi bug.

Una differenza fondamentale tra C e Java è che se si evitano alcune caratteristiche facilmente identificabili di Java (ad esempio quelle nello Unsafespazio dei nomi), ogni possibile azione che si possa tentare - comprese quelle "errate" - avrà una gamma limitata di possibili esiti . Mentre questo limita ciò che si può fare in Java - almeno senza usare lo Unsafespazio dei nomi, rende anche possibile limitare il danno che può essere causato da un programma errato, o - soprattutto - da un programma che dovrebbe elaborare correttamente file validi ma non particolarmente protetti da file errati.

Tradizionalmente, i compilatori C elaborano molte azioni in modo definito dallo standard in casi "normali", mentre elaborano molti casi angolari "in un modo caratteristico dell'ambiente". Se si stesse usando una CPU che si sarebbe messa in corto circuito e avrebbe preso fuoco se si fosse verificato un overflow numerico e si fosse voluto evitare che la CPU prendesse fuoco, sarebbe necessario scrivere un codice per evitare un overflow numerico. Se, tuttavia, si stesse utilizzando una CPU che avrebbe troncato perfettamente i valori secondo il complemento a due, non si sarebbe dovuto evitare traboccamenti nei casi in cui tale troncamento avrebbe comportato comportamenti accettabili.

La moderna C fa un passo avanti: anche se si sta prendendo di mira una piattaforma che definirebbe naturalmente un comportamento per qualcosa come un overflow numerico in cui lo Standard non impone requisiti, l'overflow in una parte di un programma può influire sul comportamento di altre parti del programma in modo arbitrario non vincolato dalle leggi del tempo e della causalità. Ad esempio, considera qualcosa come:

 uint32_t test(uint16_t x)
 {
   if (x < 50000) foo(x);
   return x*x; // Note x will promote to "int" if that type is >16 bits.
 }

Un compilatore C "moderno", dato qualcosa di simile a quanto sopra, potrebbe concludere che, poiché il calcolo di x * x trabocca se x è maggiore di 46340, può eseguire la chiamata a "pippo" incondizionatamente. Si noti che anche se sarebbe accettabile terminare in modo anomalo un programma se x è fuori portata o se la funzione restituisce qualsiasi valore in questi casi, chiamare foo () con una fuori portata x potrebbe causare danni ben oltre una di queste possibilità. Il C tradizionale non fornirebbe alcun equipaggiamento di sicurezza oltre a quello fornito dal programmatore e dalla piattaforma sottostante, ma consentirebbe agli equipaggiamenti di sicurezza di limitare il danno da situazioni impreviste. La moderna C aggirerà qualsiasi attrezzatura di sicurezza che non sia efficace al 100% nel mantenere tutto sotto controllo.

Esistono diversi livelli di correttezza in una lingua. In ordine di crescente astrazione:

• Pochi programmi sono privi di errori (solo quelli per i quali può essere dimostrata la correttezza). Altri hanno già affermato che il contenimento degli errori è quindi l'aspetto di sicurezza più concreto. I linguaggi che girano in una macchina virtuale come Java e .net sono generalmente più sicuri a questo proposito: gli errori del programma vengono normalmente intercettati e gestiti in modo definito. ¹

• Al livello successivo, gli errori rilevati in fase di compilazione anziché in fase di esecuzione rendono una lingua più sicura. Un programma sintatticamente corretto dovrebbe anche essere semanticamente corretto il più possibile. Ovviamente il compilatore non può conoscere il quadro generale, quindi questo riguarda il livello di dettaglio. I tipi di dati forti ed espressivi sono un aspetto della sicurezza a questo livello. Si potrebbe dire che la lingua dovrebbe rendere difficile fare alcuni tipi di errori(errori di tipo, accesso non associato, variabili non inizializzate ecc.). Le informazioni sul tipo di runtime come gli array che contengono informazioni sulla lunghezza evitano errori. Ho programmato Ada 83 al college e ho scoperto che un programma Ada compilante conteneva in genere forse un ordine di grandezza meno errori rispetto al corrispondente programma C. Prendi semplicemente la capacità di Ada di definire i tipi interi che non sono assegnabili senza conversione esplicita: intere navi spaziali si sono schiantate perché piedi e metri erano confusi, cosa che si potrebbe banalmente evitare con Ada.

• Al livello successivo, la lingua dovrebbe fornire i mezzi per evitare il codice della caldaia. Se devi scrivere i tuoi contenitori, o il loro smistamento, o la loro concatenazione, o se devi scrivere i tuoi string::trim(), commetterai degli errori. Poiché il livello di astrazione aumenta, questo criterio coinvolge sia la lingua corretta sia la libreria standard della lingua.

• In questi giorni la lingua dovrebbe fornire mezzi per la programmazione concorrente a livello linguistico. La concorrenza è difficile da ottenere e forse impossibile da eseguire correttamente senza il supporto linguistico.

• Il linguaggio dovrebbe fornire mezzi per la modularizzazione e la collaborazione. I tipi forti, elaborati e definiti dall'utente dall'alto aiutano a creare API espressive.

In qualche modo ortogonalmente la definizione della lingua dovrebbe essere comprensibile; la lingua e le biblioteche dovrebbero essere ben documentate. La documentazione difettosa o mancante porta a programmi cattivi e sbagliati.

Per favore, non dire che ogni PL ha comandi non sicuri. Possiamo sempre prendere un sottoinsieme sicuro.

Ogni lingua che conosco ha modi di scrivere programmi illegali che possono essere (compilati ed) eseguiti. E ogni lingua che conosco ha un sottoinsieme sicuro. Allora, qual è la tua domanda?

La sicurezza è multidimensionale e soggettiva.

Alcune lingue hanno molte operazioni "non sicure". Altri hanno meno operazioni di questo tipo. In alcune lingue, il modo predefinito di fare qualcosa è intrinsecamente pericoloso. In altri, il modo predefinito è sicuro. In alcune lingue, esiste un sottoinsieme esplicito "non sicuro". In altre lingue, questo sottoinsieme non esiste affatto.

In alcune lingue, "sicurezza" si riferisce esclusivamente alla sicurezza della memoria, un servizio offerto dalla libreria standard e / o dal runtime in cui le violazioni dell'accesso alla memoria sono rese difficili o impossibili. In altre lingue, "sicurezza" include esplicitamente la sicurezza del thread. In altre lingue, "sicurezza" si riferisce alla garanzia che un programma non si arresti in modo anomalo (un requisito che include il non consentire eccezioni non rilevate di alcun tipo). Infine, in molte lingue "sicurezza" si riferisce alla sicurezza dei tipi - se il sistema dei tipi è coerente in certi modi, si dice che sia "solido" (per inciso, Java e C # non hanno sistemi di tipo completamente sani).

E in alcune lingue, tutti i diversi significati di "sicurezza" sono considerati sottoinsiemi di sicurezza del tipo (ad es. Rust e Pony raggiungono la sicurezza del filo attraverso le proprietà del sistema di tipi).

Questa risposta è un po 'più ampia. Negli ultimi decenni le parole sicurezza e sicurezza sono state mutilate da alcune parti della società di lingua inglese orientate politicamente, in modo tale che il loro uso comune non ha quasi alcuna definizione. Tuttavia, per i soggetti tecnici torno ancora a definire "sicurezza" e "sicuro" come: un dispositivo che impedisce l'uso involontario di qualcosa o che rende sostanzialmente più difficile l'uso accidentale e lo stato di essere sotto la protezione di tale dispositivo .
Quindi un linguaggio sicuro ha qualche dispositivo per limitare una particolare classe di bug. Naturalmente i limiti derivano da inconvenienti o addirittura incapacità in alcuni casi, e ciò non significa che le lingue "non sicure" provochino bug. ad esempio, non ho tappi di sicurezza sulle forcelle e per decenni sono riuscito, senza troppi sforzi, a evitare di accoltellare l'occhio mentre mangiavo. Certamente meno sforzo di quanto sarebbe stato speso usando i tappi. Quindi la sicurezza ha un costo in base al quale deve essere valutata. (la forcella di sughero è un riferimento a un personaggio di Steve Martin)