Bonjour, Habr! Je vous présente la traduction de l'article "Qu'est-ce qui est dangereux pour Rust?" auteur Nora Codes.

J'ai vu beaucoup de malentendus quant à ce que le mot-clé dangereux signifie pour l'utilité et l'exactitude du langage Rust et sa promotion en tant que «langage de programmation de système sûr». La vérité est beaucoup plus compliquée que ce qui peut être décrit dans un court tweet, malheureusement. Voilà comment je la vois.

En général, le mot clé unsafe ne désactive pas le système de type qui maintient le code Rust correct . Il ne permet d'utiliser que certains «superpuissances», comme les pointeurs de déréférencement. unsafe est utilisé pour implémenter des abstractions sûres basées sur un monde fondamentalement dangereux afin que la plupart du code Rust puisse utiliser ces abstractions et éviter l'accès à la mémoire non sécurisé.

Garantie de sécurité

La rouille garantit la sécurité comme l'un de ses principes fondamentaux. On peut dire que c'est le sens de l'existence du langage. Cependant, il n'assure pas la sécurité au sens traditionnel, pendant l'exécution du programme et l'utilisation du garbage collector. Au lieu de cela, Rust utilise un système de type très avancé pour garder une trace du moment et des valeurs accessibles. Le compilateur analyse ensuite statiquement chaque programme Rust pour s'assurer qu'il est toujours dans le bon état.

Sécurité Python

Prenons l'exemple de Python. Le code Python pur ne peut pas corrompre la mémoire. L'accès aux éléments de la liste a des contrôles pour dépasser les frontières; les liens renvoyés par les fonctions sont comptés pour éviter l'apparition de liens pendants; Il n'y a aucun moyen de faire de l'arithmétique arbitraire avec des pointeurs.

Cela a deux conséquences. Premièrement, de nombreux types doivent être «spéciaux». Par exemple, il n'est pas possible d'implémenter une liste ou un dictionnaire efficace en Python pur. Au lieu de cela, l'interpréteur CPython a leur implémentation interne. Deuxièmement, l'accès aux fonctions externes (fonctions non implémentées en Python), appelées l'interface d'une fonction externe, nécessite l'utilisation d'un module ctypes spécial et viole les garanties de sécurité du langage.

Dans un sens, cela signifie que tout ce qui est écrit en Python ne garantit pas un accès sécurisé à la mémoire.

Sécurité à Rust

Rust fournit également la sécurité, mais au lieu d'implémenter des structures dangereuses en C, il fournit une astuce: le mot clé unsafe. Cela signifie que les structures de données fondamentales de Rust, telles que Vec, VecDeque, BTreeMap et String, sont implémentées dans Rust.

Vous pouvez demander: "Mais, si Rust fournit une astuce contre ses garanties de sécurité de code, et que la bibliothèque standard est implémentée en utilisant cette astuce, tout dans Rust ne sera-t-il pas considéré comme dangereux?"

En un mot, cher lecteur, oui , exactement comme c'était en Python. Examinons-le plus en détail.

Qu'est-ce qui est interdit dans la rouille sûre?

La sécurité à Rust est bien définie: nous y pensons beaucoup. En bref, les programmes Rust sûrs ne peuvent pas:

• Déréférencer un pointeur qui pointe vers un type différent de celui que le compilateur connaît . Cela signifie qu'il n'y a pas de pointeurs vers null (car ils ne pointent nulle part), pas d'erreurs de dépassement de limites et / ou de segmentation (défauts de segmentation), pas de débordements de buffer. Mais cela signifie également qu'il n'y a aucune utilisation après avoir libéré la mémoire ou re-libéré la mémoire (car la libération de la mémoire est considérée comme un déréférencement du pointeur) et aucun jeu de mots destiné à taper .
• Avoir plusieurs références mutables à un objet ou des références simultanément mutables et immuables à un objet . Autrement dit, si vous avez une référence mutable à un objet, vous ne pouvez que l'avoir, et si vous avez une référence immuable à l'objet, elle ne changera pas tant que vous ne la conserverez pas. Cela signifie que vous ne pouvez pas forcer une course aux données dans Safe Rust, ce qui est une garantie que la plupart des autres langues sécurisées ne peuvent pas fournir.

Rust code ces informations dans un système de types ou à l'aide de types de données algébriques , comme Option pour indiquer l'existence / absence d'une valeur et Résultat <T, E> pour indiquer l'erreur / le succès, ou les références et leur durée de vie , par exemple, & T vs & mut T pour indiquer un lien commun (immuable) et un lien exclusif (mutable) et & 'a T vs &' b T pour distinguer les liens qui sont corrects dans différents contextes (ceci est généralement omis car le compilateur est assez intelligent pour le comprendre vous-même) .

Des exemples

Par exemple, le code suivant ne sera pas compilé car il contient un lien pendant. Plus précisément, my_struct ne vit pas assez . En d'autres termes, la fonction renverra un lien vers quelque chose qui n'existe plus, et donc le compilateur ne peut pas (et, en fait, ne sait même pas comment) le compiler.

fn dangling_reference(v: &u64) -> &MyStruct { //     MyStruct   ,  v,   . let my_struct = MyStruct { value: v }; //      my_struct. return &my_struct; //  - my_struct  (  ). } 

Ce code fait de même, mais il essaie de contourner ce problème en plaçant la valeur sur le tas (Box est le nom du pointeur intelligent de base dans Rust).

 fn dangling_heap_reference(v: &u64) -> &Box<MyStruct> { let my_struct = MyStruct { value: v }; //    Box         . let my_box = Box::new(my_struct); //      my_box. return &my_box; // my_box   .   "" my_struct       - , //    - MyStruct  . } 

Le code correct est renvoyé par Box lui-même au lieu d'une référence à celui-ci. Cela encode le transfert de propriété - la responsabilité de libérer de la mémoire - dans la signature de la fonction. En regardant la signature, il devient clair que le code appelant est responsable de ce qui se passe avec Box et, en effet, le compilateur le traite automatiquement.

 fn no_dangling_reference(v: &u64) -> Box<MyStruct> { let my_struct = MyStruct { value: v }; let my_box = Box::new(my_struct); //    my_box  . return my_box; //    .         , //    ;       //  Box<MyStruct>       ,      . } 

Certaines mauvaises choses ne sont pas interdites dans la rouille sûre. Par exemple, il est autorisé du point de vue du compilateur:

• provoquer un blocage dans le programme
• fuite d'une quantité de mémoire arbitrairement grande
• ne pas fermer les poignées de fichier, les connexions à la base de données ou les couvercles d'arbre de missile

La force de l'écosystème Rust est que de nombreux projets choisissent d'utiliser un système de type pour s'assurer que le code est aussi précis que possible, mais le compilateur ne nécessite pas une telle contrainte, sauf dans les cas où un accès sécurisé à la mémoire est fourni.

Qu'est-ce qui est autorisé dans la rouille dangereuse?

Le code Rust non sécurisé est un code Rust avec le mot clé unsafe. dangereux peut être appliqué à une fonction ou à un bloc de code. Lorsqu'elle est appliquée à une fonction, cela signifie "cette fonction nécessite que le code appelé fournisse manuellement l'invariant qui est généralement fourni par le compilateur". Lorsqu'il est appliqué à un bloc de code, cela signifie "ce bloc de code fournit manuellement l'invariant nécessaire pour empêcher l'accès non sécurisé à la mémoire, et par conséquent il est autorisé à faire des choses dangereuses".

En d'autres termes, dangereux pour la fonction signifie "vous devez tout vérifier", et sur le bloc de code - "J'ai déjà tout vérifié".

Comme indiqué dans The Rust Programming Language , le code dans un bloc marqué avec le mot clé unsafe peut:

• Déréférencer un pointeur. Il s'agit d'une "superpuissance" clé qui vous permet d'implémenter des listes doublement liées, une table de hachage et d'autres structures de données fondamentales.
• Appelez une fonction ou une méthode non sécurisée. Plus d'informations à ce sujet ci-dessous.
• Accédez ou modifiez une variable statique mutable. Les variables statiques dont la portée n'est pas contrôlée ne peuvent pas être vérifiées statiquement, donc leur utilisation n'est pas sûre.
• Mettre en œuvre un trait dangereux. Des traits non sécurisés sont utilisés pour signaler si des types particuliers garantissent certains invariants. Par exemple, Send et Sync déterminent si un type peut être envoyé entre les limites de threads ou peut être utilisé par plusieurs threads en même temps.

Rappelez-vous ces pointeurs suspendus ci-dessus? Ajoutez le mot dangereux, et le compilateur jurera deux fois plus car il n'aime pas utiliser dangereux là où il n'est pas nécessaire.

Au lieu de cela, le mot clé unsafe est utilisé pour implémenter des abstractions sûres basées sur des opérations de pointeur arbitraires. Par exemple, le type Vec est implémenté en utilisant dangereux, mais il est sûr de l'utiliser, car il vérifie les tentatives d'accès aux éléments et n'autorise pas les débordements. Bien qu'il fournisse des opérations telles que set_len, qui peuvent entraîner un accès non sécurisé à la mémoire, elles sont marquées comme non sécurisées.

Par exemple, nous pourrions faire la même chose que dans l'exemple no_dangling_reference, mais avec une utilisation déraisonnable de dangereux:

 fn manual_heap_reference(v: u64) -> *mut MyStruct { let my_struct = MyStruct { value: v }; let my_box = Box::new(my_struct); //  Box    . let struct_pointer = Box::into_raw(my_box); return struct_pointer; //   ;     . // MyStruct     . } 

Remarquez l'absence du mot dangereux. La création de pointeurs est absolument sûre. Comme cela a été écrit, il existe un risque de fuite de mémoire, mais rien de plus, et les fuites de mémoire sont sûres. L'appel de cette fonction est également sûr. dangereux n'est requis que lorsque quelque chose tente de déréférencer un pointeur. En prime, le déréférencement libérera automatiquement la mémoire allouée.

 fn main() { let my_pointer = manual_heap_reference(1337); let my_boxed_struct = unsafe { Box::from_raw(my_pointer) }; //  "Value: 1337" println!("Value: {}", my_boxed_struct.value); // my_boxed_struct    .       ,  //    - MyStruct } 

Après optimisation, ce code équivaut à renvoyer simplement une Box. Box est une abstraction sécurisée basée sur un pointeur car elle empêche la distribution de pointeurs partout. Par exemple, la prochaine version de main entraînera une double mémoire libre (double libre).

 fn main() { let my_pointer = manual_heap_reference(1337); let my_boxed_struct_1 = unsafe { Box::from_raw(my_pointer) }; // DOUBLE FREE BUG! let my_boxed_struct_2 = unsafe { Box::from_raw(my_pointer) }; //  "Value: 1337" . println!("Value: {}", my_boxed_struct_1.value); println!("Value: {}", my_boxed_struct_2.value); // my_boxed_struct_2    .     ,  //    - MyStruct. //  my_boxed_struct_1    .      , //      - MyStruct.  double-free bug. } 

Alors, quelle est l'abstraction sûre?

L'abstraction sûre est une abstraction qui utilise un système de type pour fournir une API qui ne peut pas être utilisée pour violer les garanties de sécurité mentionnées ci-dessus. Box est plus sûr * mut T, car il ne peut pas conduire à une double désallocation de mémoire, comme illustré ci-dessus.

Un autre exemple est le type Rc dans Rust. Il s'agit d'un pointeur de comptage de référence - une référence non modifiable aux données du tas. Puisqu'il permet plusieurs accès simultanés à une zone de mémoire, il doit empêcher le changement afin d'être considéré comme sûr.

De plus, il n'est pas sûr pour les threads. Si vous avez besoin de la sécurité des threads, vous devrez utiliser le type d'arc (comptage de référence atomique), qui présente une pénalité de performance en raison de l'utilisation de valeurs atomiques pour le comptage de liens et empêchant d'éventuelles courses de données dans des environnements multithreads.

Le compilateur ne vous permettra pas d'utiliser Rc là où vous devriez utiliser Arc, car les créateurs comme Rc ne l'ont pas marqué comme thread-safe. S'ils le faisaient, ce serait déraisonnable: une fausse promesse de sécurité.

Quand faut-il utiliser la rouille dangereuse?

La rouille dangereuse est toujours nécessaire lorsqu'il est nécessaire d'effectuer une opération qui viole l'une de ces deux règles décrites ci-dessus. Par exemple, dans une liste doublement liée, l'absence de liens mutables vers les mêmes données (pour l'élément suivant et l'élément précédent) la prive complètement de bénéfice. Avec unsafe, un implémenteur de liste doublement lié peut écrire du code à l'aide des pointeurs * mut Node, puis l'encapsuler dans une abstraction sûre.

Un autre exemple est de travailler avec des systèmes embarqués. Les microcontrôleurs utilisent souvent un ensemble de registres dont les valeurs sont déterminées par l'état physique de l'appareil. Le monde ne peut pas s'arrêter pendant que vous prenez & mut u8 à partir d'un tel registre, donc dangereux n'est pas nécessaire pour travailler avec des caisses de support d'appareil. En règle générale, ces caisses encapsulent l'état dans des emballages transparents et sécurisés qui copient les données chaque fois que possible, ou utilisent d'autres techniques qui fournissent des garanties de compilation.

Parfois, il est nécessaire d'effectuer une opération qui peut conduire à une lecture et à une écriture simultanées, ou à un accès non sécurisé à la mémoire, et c'est là que la sécurité est nécessaire. Mais tant qu'il y a une possibilité de s'assurer que les invariants sûrs sont maintenus avant qu'un utilisateur touche quelque chose (c'est-à-dire dangereux dangereux), tout va bien.

Sur qui repose cette responsabilité?

Nous arrivons à une déclaration faite plus tôt - oui , l'utilité du code Rust est basée sur un code dangereux. Malgré le fait que cela soit fait d'une manière légèrement différente de l'implémentation non sécurisée des structures de données de base en Python, l'implémentation de Vec, Hashmap, etc., devrait utiliser des manipulations de pointeurs dans une certaine mesure.

Nous disons que Rust est sûr, avec l'hypothèse fondamentale que le code dangereux que nous utilisons via nos dépendances sur la bibliothèque standard ou le code d'autres bibliothèques est correctement écrit et encapsulé. L'avantage fondamental de Rust est que le code non sécurisé est entraîné dans des blocs non sécurisés qui doivent être soigneusement vérifiés par leurs auteurs.

En Python, la charge de vérifier la sécurité des manipulations de mémoire incombe uniquement aux développeurs des interprètes et aux utilisateurs des interfaces des fonctions externes. En C, ce fardeau incombe à chaque programmeur.

Dans Rust, il appartient aux utilisateurs du mot-clé dangereux. Cela est évident, car les invariants doivent être maintenus manuellement à l'intérieur de ce code, et il est donc nécessaire de rechercher la plus petite quantité de ce code dans la bibliothèque ou le code d'application. L'insécurité est détectée, mise en évidence et indiquée. Par conséquent, si des erreurs de segmentation se produisent dans votre code Rust, vous trouvez une erreur dans le compilateur ou une erreur dans plusieurs lignes de votre code non sécurisé.

Ce n'est pas un système parfait, mais si vous avez besoin de vitesse, de sécurité et de multithreading en même temps, c'est la seule option.