IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ », d'après Bjarne Stroustrup
Contre une sortie de la NSA qui exclut le C++ des langages sécurisés

Le , par Patrick Ruiz

60PARTAGES

25  0 
Mark Russinovich de Microsoft a déclaré au troisième trimestre de l’année précédente que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA trouve désormais contradicteur et pas des moindres. Sans détour, le créateur du langage C++ déclare : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »

En effet, Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.

« Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.


L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

Code Rust : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
#include <type_traits> 
#include <utility> 
#include <assert.h> 
#include <stddef.h> 
enum NoRefs {}; 
enum HasMutRef {}; 
enum HasRefs {}; 
template <class T, typename Mode> 
class Own; 
template <class T> 
class MutRef; 
template <class T> 
class Ref; 
template <class T, typename... Args> 
inline Own<T, NoRefs> make(Args... args) { 
  return Own<T, NoRefs>(std::forward<Args>(args)...); 
} 
template <class T> 
inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) { 
  return Own<T, NoRefs>(std::move(own)); 
} 
template <class T> 
inline Own<T, NoRefs> consume(Own<T, HasRefs> own) { 
  return Own<T, NoRefs>(std::move(own)); 
} 
template <class T> 
std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) { 
  T* t = own.t_; 
  own.t_ = nullptr; 
  return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t)); 
} 
template <class T> 
std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) { 
  T* t = own.t_; 
  own.t_ = nullptr; 
  return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t)); 
} 
// No refs exist. 
template <class T> 
class [[clang::trivial_abi]] Own<T, NoRefs> { 
 public: 
  template <typename... Args> 
  Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {} 
  ~Own() { delete t_; } 
  Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; } 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
 private: 
  friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref); 
  friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own); 
  friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  Own(Own<T, HasMutRef>&& own) : t_(own.t_) {} 
  Own(Own<T, HasRefs>&& own) : t_(own.t_) {} 
  T* t_; 
}; 
// A mut ref exists. 
template <class T> 
class [[clang::trivial_abi]] Own<T, HasMutRef> { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
 private: 
  friend class Own<T, NoRefs>; 
  Own(T* t) : t_(t) {} 
  ~Own() {} 
  T* t_; 
}; 
// Non-mut refs exist. 
template <class T> 
class [[clang::trivial_abi]] Own<T, HasRefs> { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  Ref<T> ref() { return Ref<T>(t_, &count_); } 
 private: 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  explicit Own(T* t) : t_(t) {} 
  ~Own() { assert(count_ == 0u); } 
  T* t_; 
  uint32_t count_; 
}; 
template <class T> 
class MutRef { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  ~MutRef() = default; 
  MutRef(MutRef&& other) : t_(other.t_) {} 
 private: 
  friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
  MutRef(T* t) : t_(t) {} 
  T* t_; 
}; 
template <class T> 
class Ref { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  ~Ref() { --(*count_); } 
  Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); } 
  Ref(Ref&& other) : t_(other.t_), count_(other.count_) {} 
 private: 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); } 
  T* t_; 
  uint32_t* count_; 
}; 
MutRef<int> Borrows(MutRef<int> i) { 
  (*i)++; 
  return i; 
} 
TEST(Borrow, HelloWorld) { 
  // Can't do this. The HasMutRefs type is not destructible outside of 
  // consume()in order to have compiler check it is re-owned, but it won't 
  // compile. To pass the HasMutRefs to consume() it has to be destroyed both 
  // inside and outside of consume(). This is true even if trivial_abi is 
  // used and only one destructor would actually run. 
  Own<int, NoRefs> i = make<int>(5); 
  auto& hasmut = mut(std::move(i)); 
  MutRef<int> ref = Borrows(std::move(hasmut.second)); 
  Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref)); 
}

La sortie de Bjarne Stroustrup intervient dans un contexte où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

Après 31 ans, un deuxième langage fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place de langages comme le C ou le C++.

Sources : Bjarne, Google

Et vous ?

Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?

Voir aussi :

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 23/01/2023 à 20:46
Citation Envoyé par Padget Voir le message
je dirais que le c++ est tout autant sécurisé que rust. pour ce qui est de la mémoire il y a les smart pointers dans les deux langages : unique_ptr et Box. Le cpp offre autant que le rust la gestion du cycle de vie des objets.
Pour la gestion de la mémoire, le C++ offre la possibilité d'utiliser le RAII qui évite les double free et permet aux éventuelles fuites de mémoire de ne pas être plus fréquentes que dans un langage avec ramasse-miettes.

Il y a des développeurs C++ qui sous-utilisent le RAII et introduisent plein de fuites de mémoire, ce qui est un problème culturel autour de l'apprentissage du C++.

Cependant, le C++ n'empêche pas à la compilation les dandling references/pointers/iterators. Par exemple, si on garde une référence vers un élément d'un vecteur, puis que l'on fait un push_back, que ce dernier oblige de déplacer ailleurs en mémoire les éléments du vecteur, puis que l'on essaie d'accéder à ce vers quoi pointe la dandling reference, cela ne provoque pas d'erreur de compilation, contrairement à Rust. Le C++ n'a pas autant de contrôles à la compilation qu'en Rust.

Idem pour le multithreading : le C++ ne fait pas de contrôle à la compilation contre les accès concurrents.

Le C++ n'a pas le borrow checker de Rust. Pour les contrôles à la compilation, ces deux langages ne sont clairement pas au même niveau.
8  0 
Avatar de thamn
Membre averti https://www.developpez.com
Le 23/01/2023 à 22:23
Hebe, il va pas bien Bjarne ou quoi? Il a oublie que C++ a besoin des sanitizers pour ne meme pas arriver au niveau du borrow checker de rust?
Bon, il defend son bout de pain apres, il perd pas le nord, mais bon de la a dire des trucs pareil je sais pas trop..
8  1 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 24/01/2023 à 12:22
Bjarne Stroustrup est sans conteste un immense contributeur au monde du développement informatique, mais il défend son bébé qui... conserve ses défauts.

J'ai commencé l'informatique avec C++, touché à bien des langages, et je reconnais les qualités de Rust malgré ses défauts comme le temps de compilation et le manque de lib. Pour moi Rust est un pas en avant, il est ce que C++ a essayé d'être si C++ n'avait pas essayé de rester rétro-compatible avec C dans un premier temps, puis avec lui-même. Je vois les efforts de Herb Sutter, il essaye d'améliorer C++ avec "CppFront" mais même avec ça on n'arrive pas au niveau des exigences de Rust en terme de null-safe, memory-safe, thread-safe
5  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/01/2023 à 12:32
C'est a rapprocher du récent document de Bjarne Stroustrup en tant que membre du groupe de direction de l'ISO C++ : https://www.open-std.org/jtc1/sc22/w...23/p2759r0.pdf

On voit bien qu'il est pris de court par le tournant actuel de l'industrie vers une sécurisation par défaut, qu'il n'a pas du tout anticipé, et dont il a encore du mal à admettre l'importance. On voit qu'il a tendance à réduire le problème au fait que le C++ devrait mieux communiquer sur ses fonctionnalité de sécurité. Il peine à cerner ce qu'est exactement Rust et ce qu'il apporte(approximations, exemples mal choisis, ...). Après avoir passé une grande partie du document a minimiser le problème, il ébauche quand même un chemin vers une vraie sécurisation du C++, mais on voit bien qu'ils sont encore loin ne serait-ce que d'un embryon de solution consensuelle.
4  1 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 25/01/2023 à 9:11
Bah pour lui j'imagine qu'il peut vraiment coder aussi bien en C++ qu'un expert en Rust.

Mais quid du développeur... "moyen" ? (un vrai développeur quand même)
2  1 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 26/01/2023 à 13:33
Citation Envoyé par Uther Voir le message

L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.
.
Ca me fait penser au passage de Python 2 à Python 3 ou en tout cas un exemple de ce qui peut arriver sur une évolution de langage "brutale".
1  0 
Avatar de Padget
Membre régulier https://www.developpez.com
Le 24/01/2023 à 22:16
Certes mais ça reste mon scalpel préféré pour faire du code &#128522;
0  0 
Avatar de foxzoolm
Membre régulier https://www.developpez.com
Le 25/01/2023 à 13:07
Ok le borrow-checker c'est top...
mais quid du paradigme TRAIT ?
je trouve ca plus souple que la poo.
0  0 
Avatar de Astraya
Membre chevronné https://www.developpez.com
Le 25/01/2023 à 20:15
Sans attendre l'ISO et Stroustrup. La communauté C++ à la chance d'être une des plus compétentes avec des décennies d'expériences.

Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.

L'équipe de Clang commence déjà a proposer des solutions.
https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377
0  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 26/01/2023 à 9:17
Citation Envoyé par foxzoolm Voir le message
Ok le borrow-checker c'est top...
mais quid du paradigme TRAIT ?
je trouve ca plus souple que la poo.
C'est vrai que les traits sont une fonctionnalité indiscutablement au cœur de Rust tout aussi importante sinon plus que le borrow checker. Je dirais aussi que les enum sont au moins aussi importante. Mais le sujet c'est la sécurité, et pour le coup, ça n'est ni les trait ni les enums qui font la sécurisation du Rust.
Ce qui fait sa sécurisation mémoire comparé au C++, c'est principalement le borrow checker et des choix par défaut sécurisés (initialisation obligatoire des variables, contrôles de dépassement, ...)

Citation Envoyé par Astraya Voir le message
Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.
C'est pas les initiatives qui manquent pour améliorer la sécurité du C++, mais la difficulté c'est de faire quelque chose qui, à la fois :
  • soit vraiment efficace
  • s’intègre bien a la syntaxe du langage
  • marche bien avec la base de code existante
  • est acceptable pour des utilisateurs qui n'ont jamais eu de contraintes fortes jusqu’à présent

La plupart des initiatives que j'ai vu pèchent lourdement sur un ou plusieurs de ces points.
L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.

Citation Envoyé par Astraya Voir le message
L'équipe de Clang commence déjà a proposer des solutions.
https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377
C'est intéressant ça. Pour le coup ça a l'air complétement calqué sur le système des lifetimes de Rust. Reste a voir ce que ça pourra donner en pratique.
0  0