Discussion :

[Patrick Ruiz]

Google accorde une subvention d’1 million de $ à la Fondation Rust pour soutenir les efforts d’interopérabilité avec C++
Et faciliter la transition à Rust jugé supérieur pour sécuriser les logiciels

Google accorde une subvention d’un million de dollars à la Fondation Rust pour soutenir les efforts d’interopérabilité avec le langage C++. En toile de fond, le géant technologique cherche à faciliter la transition à Rust que de plus en plus d’observateurs jugent supérieur à C et à C++ pour la sécurisation des logiciels. La tendance dans l’industrie technologique est telle que même Linus Torvalds reconnaît que Rust, qui a été adopté comme deuxième langage pour le développement du noyau Linux, est digne d’intérêt d’un point de vue technique.


« En 2021, nous avons annoncé que Google rejoignait la Rust Foundation. À l'époque, Rust était déjà largement utilisé dans Android et d'autres produits Google. Notre annonce soulignait notre engagement à améliorer les examens de sécurité du code Rust et son interopérabilité avec le code C++. Rust est l'un des outils les plus puissants dont nous disposons pour résoudre les problèmes de sécurité de la mémoire. Depuis cette annonce, les leaders de l'industrie et les agences gouvernementales se sont fait l'écho de notre sentiment.

Nous sommes ravis d'annoncer que Google a accordé une subvention d'un million de dollars à la Fondation Rust pour soutenir les efforts visant à améliorer la capacité du code Rust à interopérer avec les bases de code C++ existantes. Nous poursuivons également notre engagement envers la communauté open-source Rust en regroupant et en publiant des audits pour les crates Rust que nous utilisons dans les projets open-source de Google. Ces contributions, ainsi que nos précédentes contributions en matière d'interopérabilité, nous rendent enthousiastes quant à l'avenir de Rust », écrit Google.

« Nous sommes ravis de soutenir ce travail par le biais de l'initiative Interop de la Fondation Rust et en collaboration avec le projet Rust afin de s'assurer que tous les ajouts effectués sont appropriés et répondent aux défis de l'adoption de Rust auxquels les projets utilisant C++ sont confrontés. L'amélioration de la sécurité de la mémoire dans l'industrie du logiciel est l'un des principaux défis technologiques de notre époque, et nous invitons la communauté et l'industrie à se joindre à nous pour travailler ensemble à la sécurisation de l'écosystème open source pour tous », ajoute le géant technologique.

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. De façon graduelle, Microsoft migre vers ce dernier au détriment d’autres langages que l’entreprise juge moins outillés pour la mise sur pied d’applications dites système. Motif : Rust offre de meilleures garanties en matière de sécurisation des accès mémoire des logiciels.

« Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui. Nous devons utiliser de façon systématique des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants », déclare Neal Ziring, directeur technique de la cybersécurité de la NSA.

En effet, il y a une liste de griefs qui reviennent à l’encontre de langages de programmation comme le C et le C++ : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

C’est là qu’intervient le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C ou encore comme la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Chez Amazon par exemple, on est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. »

En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++. Ainsi, les adoptions du langage Rust visent à mettre à profit ces atouts du langage sur le C et le C++.

Le créateur du C++ est d’avis que « La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ »

Mark Russinovich de Microsoft a déclaré 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 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 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 - Visualiser dans une fenêtre à part

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)); 
}

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

[prisme60]

Dans mon entreprise, je me bas pour qu'on mette en place le Rust, que j'utilise sur mes projets persos.
Le seul frein, c'est qu'en général on part d'un existant (du bon vieux code legacy C++ comme on l'aime, miamm!), et que tout refaire prendrait trop de temps. Faire des mixes de langages, c'est assez déconseillé, la compilation, le debug, tout devient plus compliqué.

Dans le cadre du Web, on peut aussi utiliser un Framework Rust qui fait du WebAssembly. Je pense en ce moment à Leptos qui se démarque des autres Frameworks (Yew, Sycamore, Dioxus). Le problème, c'est que c'est en pleine évolution, et il est difficile de trouver un framework pérenne qui existera encore dans 10 ans. Les technologies du Web sont très versatiles. Il suffit de voir React, AngularJS, ... où les versions se suivent avec des ruptures de compatibilité ou tout simplement la technologie est devenue désuète / obsolète (Par exemple : JQuery).

[abriotde]

Le problème n'est-il pas plutôt celui de la qualité des développeurs ?

Ca c'est un mythe. Évidement, qu'un bon développeur expérimenté fera un code de meilleure qualité et donc moins de problème de sécurité. Néanmoins, dans la vrai vie, on a besoin de former des jeunes et donc d'avoir des développeurs de tout niveau. Évidemment, qu'il y aura de la relecture par des développeurs plus expérimenté, mais cela ne suffit pas. Dans la vrai vie, aussi parfait soit le développeurs et tous les outils que l'on peut mettre, l'humain est toujours faillible. Alors évidement, en mettant bretelles et ceintures, on arrive à un code de qualité, peut-être équivalent à Rust. Mais au final, s'il faut acheter des analyseurs statique et dynamiques de codes, se payer des développeurs de haut vols et beaucoup de relecture pour au final ne pas pouvoir faire un patch "à l'arrache" sans risques ce n'est pas viable.

En fait c'est détourner la question que de dire, oui mais C++ peut-être sécurisé. C'est oublié que l'on a un outils (Rust) qui fait déjà tout (ou presque) sans avoir besoin d'autant de précautions. Après, évidemment, comme pour COBOL, ce n'est pas demain que l'on aura tout recodé en Rust et quand le code est en C++, il n'est pas vraiment possible de rajouter un bout de code en Rust (C'est un peu l'objet de cette subvention de Google). La base de code en C/C++ est immense (Sans doute bien plus grande que celle de COBOL au moins aujourd'hui), les développeurs C/C++ ont donc du travail pour au moins 50 ans.
J'ai une mention spécial pour C. C est un peu à part. Il est un peu irremplaçable dans certains cas dans l'embarqué ou dans le très bas niveau. Rust ou C++ se prêtent assez mal à des manipulation très spécifiques et pas toujours sécurisé mais nécessaire. Quand on travail au plus bas niveau il faut parfois faire des choses qui n'ont pas trop de sens autrement, et C est un peu le seul à pouvoir le faire. C'est cependant un code très restreint en volume. Et même parfois ce n'est pas assez bas niveau, on doit passer en assembleur. A cette exception près, le C devrait être remplacer par le Rust. D'ailleurs, le choix du C au lieu du C++, à l'exception du très bas niveau, est fait pour des questions de performances, car en C++ on peut trop facilement utiliser des raccourcis qui ne sont pas optimisé en performances (Rapides mais pas très rapides), je pense entre autre aux smart-pointer... Ceux qui connaissent comprendront les 3 points de suspensions, pour les autres disons que simplement ce sont justement les super-pouvoirs de C++ qui sont vanté comme sécurisés.

[fdecode]

Ca c'est un mythe. Évidement, qu'un bon développeur expérimenté fera un code de meilleure qualité et donc moins de problème de sécurité. Néanmoins, dans la vrai vie, on a besoin de former des jeunes et donc d'avoir des développeurs de tout niveau. Évidemment, qu'il y aura de la relecture par des développeurs plus expérimenté, mais cela ne suffit pas. Dans la vrai vie, aussi parfait soit le développeurs et tous les outils que l'on peut mettre, l'humain est toujours faillible. Alors évidement, en mettant bretelles et ceintures, on arrive à un code de qualité, peut-être équivalent à Rust. Mais au final, s'il faut acheter des analyseurs statique et dynamiques de codes, se payer des développeurs de haut vols et beaucoup de relecture pour au final ne pas pouvoir faire un patch "à l'arrache" sans risques ce n'est pas viable.

Merci d'avoir verbalisé ce constat qui m'a fait abandonner le C++ il y a une grosse décennie.

J'ai une mention spécial pour C. C est un peu à part. Il est un peu irremplaçable dans certains cas dans l'embarqué ou dans le très bas niveau. Rust ou C++ se prêtent assez mal à des manipulation très spécifiques et pas toujours sécurisé mais nécessaire. Quand on travail au plus bas niveau il faut parfois faire des choses qui n'ont pas trop de sens autrement, et C est un peu le seul à pouvoir le faire.

Je ne sais pas si le C est irremplaçable.

Il y a des projets d'OS bien avancés écrits en Rust https://www.redox-os.org/.

Le unsafe est possible en Rust, mais il faut en avoir une véritable maîtrise: pour développeurs expérimentés en Rust.

Enfin, ce n'est pas parce qu'un code est sécurisé qu'il est nécessairement moins rapide ou moins bas niveau. L'exemple suivant [Playground] montre le code généré suite à une compilation Release. L'utilisation de références mutables plutôt que des pointeurs induit un code machine simplifié, qui est similaire à ce qu'on pourrait obtenir avec le mot clef `restrict` du C (les références mutables interdisent le chevauchement en mémoire):

[chrtophe]

Je ne suis pas développeur, mais l'exemple ne montre rien de concret, pas de code dans les fonctions.

Je suppose qu'un compilateur digne de ce nom ne ferait même pas ce code, qui ne contient qu'une signature de fonction.

Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise pour s'en sortir car o en reviendrait au même travers du C/C++, que Rust est censé pallier.

Et qu'en est il des fonctions de la libc ? il y a une bibliothèque équivalente ? on peut appeler ses fonctions (probablement en unsafe) ?

[fdecode]

Je ne suis pas développeur, mais l'exemple ne montre rien de concret, pas de code dans les fonctions.

Je ne vais pas vous faire un code complet... et surement pas sur le playground... Pour ce qui est de l'exemple, il est là pour illustrer ce que peut apporter la sémantique du mode safe en termes d'optimisation de code. Dans le cas présent, cela permet d'économiser des échanges avec la mémoire. Sans le mot-clé restrict en C ou certaines directives non standard en C++ et propres au compilateur, vous ne pouvez pas obtenir ce genre d'optimisation, qui est par ailleurs permis par le FORTRAN.

Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise

En effet, mais un développeur inexpérimenté doit-il faire du code critique dans des développements systèmes? Car c'est un peu ça l'intérêt du unsafe en Rust. En dehors de fractions de codes critiques devant être particulièrement optimisés, je ne vois pas l'intérêt d'un usage de unsafe.

Et qu'en est il des fonctions de la libc ? il y a une bibliothèque équivalente ? on peut appeler ses fonctions (probablement en unsafe) ?

Actuellement, la dépendance de Rust est liée au linkage. L'infrastructure de l'OS d'accueil est utilisé. Typiquement Microsoft C++ build tools pour windows. Des librairies compilées de la libc, sans doute, pour linux.
L'OS Redox fournit une relibc implémentée en Rust https://github.com/redox-os/relibc.
Cette dépendance venant au moment du linkage, elle est transparente au niveau du code en rust lors de l'utilisation de la libraire standard; au pire, on héritera de contraintes de l'OS.
Bien entendu, il est possible d'appeler des fonctions provenant d'une librairie C en utilisant du unsafe. Ce cas d'usage de unsafe est bien documenté et ne pose aucun problème. Le vrai problème vient d'un usage de unsafe qui serait UB (undefined behavior). Et c'est la connaissance des cas UB qui nécessite une certaine expertise. Car il y en a beaucoup plus qu'en C.

[fdecode]

qui ne contient qu'une signature de fonction.

???
La signature de la fonction, c'est ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 fn adds(a: &mut i32, b: &mut i32)

Ça, c'est le code de la fonction (j'ajoute b à a, puis j'ajoute b à a; comme ce sont des références mutables, rust interdit la situation où a et b partagent le même emplacement mémoire, ce qui rend inutile les échanges en mémoire par movl):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{ *a += *b; *a += *b; }

Je suppose qu'un compilateur digne de ce nom ne ferait même pas ce code, qui ne contient qu'une signature de fonction.

En pratique, le compilateur Rust vous génèrera un message d'alerte si votre projet contient du code non publique (donc non utilisable dans un autre projet), qui n'est jamais utilisé. Cette fonctionnalité vient par défaut, et peut être désactivée pour certaines parties du code. Visiblement, la directive no_mangle désactive ce message d'alerte. J'espère avoir répondu à votre question non formulée...

[chrtophe]

J'ai pas utilisé le bon terme, je voulais dire prologue.

Merci pour la réponse en tout cas.

[fdecode]

Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise pour s'en sortir car o en reviendrait au même travers du C/C++

Je n'avais pas noté cette petite subtilité psychologique dans votre question à la première lecture: le développeur inexpérimenté qui transgresse les règles pour faire le job vite fait mais salement fait.
Vous avez différents outils de diagnostic à disposition: miri pour détecter à l'exécution des undefined behaviour ; des add-on à cargo pour faire une statistique des codes unsafe, etc.
Mais le plus simple est d'interdire l'usage des unsafe en plaçant la directive #![forbid(unsafe_code)] à la racine du projet ou du sous-projet.

[Pyramidev]

Mais le plus simple est d'interdire l'usage des unsafe en plaçant la directive #![forbid(unsafe_code)] à la racine du projet ou du sous-projet.

Remarque : Depuis Rust 1.74.0, la manière idiomatique est de le faire dans le Cargo.toml :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[lints.rust]
unsafe_code = "forbid"

[Jade Emy]

La Fondation Rust publie un nouveau document pour améliorer l'interopérabilité entre Rust et C++, après le lancement de l'« Interop Initiative » en février 2024 avec une contribution de 1 million de $ de Google.

La Fondation Rust publie un énoncé de problème sur l'interopérabilité C++/Rust. Plutôt que de prescrire des solutions spécifiques, l'énoncé de problème sert de base à la contribution et à la participation de la communauté pour façonner à la fois la direction stratégique et la mise en œuvre tactique d'une interopérabilité améliorée entre C++ et Rust. L'« Initiative Interop » a été lancée en février 2024 avec la contribution de 1 million de dollars de Google.

En février 2024, Google avait accordé une subvention d’un million de dollars à la Fondation Rust pour soutenir les efforts d’interopérabilité avec le langage C++. En toile de fond, le géant technologique cherche à faciliter la transition à Rust que de plus en plus d’observateurs jugent supérieur à C et à C++ pour la sécurisation des logiciels. La tendance dans l’industrie technologique est telle que même Linus Torvalds reconnaît que Rust, qui a été adopté comme deuxième langage pour le développement du noyau Linux, est digne d’intérêt d’un point de vue technique.

La Fondation Rust, une organisation indépendante à but non lucratif dédiée à la gestion et à l'avancement du langage de programmation Rust, a récemment publié un énoncé de problème complet abordant les défis et les opportunités de l'interopérabilité entre C++ et Rust. Cette publication marque une étape importante pour rendre le développement inter-langages plus accessible et plus abordable pour la communauté de programmation dans son ensemble.

L'énoncé du problème présente trois approches stratégiques clés :

• Améliorer les outils existants et résoudre les problèmes tactiques au sein du projet Rust afin de réduire les frictions et les risques liés à l'interopérabilité à court terme.
• Construire un consensus autour d'objectifs à long terme nécessitant des changements dans le projet Rust lui-même et développer des approches tactiques pour commencer à les poursuivre.
• S'engager avec la communauté et le comité C++ pour améliorer la qualité de l'interopérabilité pour les deux langages afin d'atteindre les objectifs mutuels de sécurité et de performance.

Concernant l'« Initiative Interop », elle a été lancée en février 2024 avec la contribution de 1 million de dollars de Google. L'initiative reconnaît que C++ et Rust ont tous deux un rôle essentiel à jouer dans l'avenir de la programmation des systèmes. Bien que les deux langages excellent dans des domaines similaires, les utiliser ensemble de manière efficace est crucial pour les organisations qui cherchent à équilibrer la sécurité et la performance avec la maintenabilité. Le défi principal réside dans le développement d'une approche mature et standardisée de l'interopérabilité entre C++ et Rust, malgré l'accent historique mis par Rust sur la compatibilité avec le langage C.

L'initiative propose une approche collaborative de l'espace-problème impliquant les principales parties prenantes des deux communautés linguistiques. Plutôt que de prescrire des solutions spécifiques, l'énoncé de problème sert de base à la contribution et à la participation de la communauté pour façonner à la fois la direction stratégique et la mise en œuvre tactique d'une interopérabilité améliorée entre C++ et Rust.

Voici l'énoncé de problème d'interopérabilité entre Rust et C++ :

Résumé

Le C++ et le Rust joueront tous deux un rôle important dans la programmation des systèmes dans un avenir prévisible. Avec un tel degré de chevauchement dans l'applicabilité, l'utilisation conjointe des deux langages est essentielle à la recherche de la sécurité et de la performance qui sont maintenables et évolutives. L'objectif principal de l'initiative est de permettre aux technologues de choisir le langage le mieux adapté à leur situation et de minimiser les coûts et les risques liés à l'interopérabilité.

Bien que l'interopérabilité du C ait été au centre des préoccupations de Rust depuis sa création, plusieurs facteurs ont empêché la mise en place d'une solution mature, standard et automatique pour le développement de logiciels utilisant conjointement C++ et Rust. Pour surmonter ces obstacles, l'initiative poursuivra une approche descendante, axée sur l'espace-problème, afin de faciliter la coopération et le consensus entre les parties prenantes, notamment le projet Rust, les organisations membres de la Fondation Rust et la communauté des individus et des organisations utilisant C++ ou Rust. Les ressources matérielles apportées à l'initiative seront utilisées pour poursuivre trois stratégies simultanées :

1. Améliorer les outils existants et résoudre les problèmes tactiques au sein du projet Rust afin de réduire les frictions et les risques liés à l'interopérabilité à court terme.
2. Construire un consensus autour d'objectifs à long terme nécessitant des changements dans le projet Rust lui-même et développer des approches tactiques pour commencer à les poursuivre.
3. S'engager avec la communauté et le comité C++ pour améliorer la qualité de l'interopérabilité pour les deux langages afin d'atteindre les objectifs mutuels de sécurité et de performance.

L'approche axée sur les problèmes est essentielle pour surmonter les obstacles dans ce domaine. Beaucoup de travail a été fait sur les outils qui apportent une valeur considérable, mais il y a une limite à ce qui peut être réalisé avec des bibliothèques externes et des outils de génération de code ; motiver avec succès des changements plus profonds nécessite un consensus stratégique afin de définir un travail tactique concret. Par conséquent, le présent document ne définit pas de solutions ; il constitue un appel à la contribution et à la participation pour affiner ces stratégies et les tactiques qui en découlent. Le reste du document décrit plus en détail le problème lui-même et ces stratégies.

Le problème

L'interopérabilité C++/Rust est la capacité d'échanger des données et d'exécuter du code écrit dans les deux langages. Il existe un compromis inhérent entre la simplicité et l'efficacité et une dichotomie distincte entre la communication inter-processus et l'interopérabilité intra-processus. Cette dernière se produit au sein du même exécutable, soit par la compilation intégrée de plusieurs langages (inline embedding), soit par des interfaces de fonctions étrangères (FFI). L'initiative interop est exclusivement axée sur cette dernière forme, de sorte que toutes les mentions ultérieures de l'interopérabilité dans le présent document se réfèrent à l'interopérabilité intra-processus. De nombreuses questions ouvertes ne sont pas abordées ici, telles que les caractéristiques des langages Rust et C++ qui peuvent être efficacement prises en charge par les interfaces de fonctions étrangères et l'incidence de l'établissement de liens statiques ou dynamiques sur l'interopérabilité.

Qui est concerné ?

Bien que Rust et C++ soient tous deux utilisés en dehors de leur domaine principal en tant que langages de systèmes, ce type d'interopérabilité est particulièrement pertinent dans le domaine des systèmes où les ressources sont limitées. Le désir d'interopérabilité dépend du système en question, mais les cas d'utilisation les plus courants sont les suivants :

1. les systèmes C++ qui ajoutent ou remplacent des fonctionnalités par Rust
2. Systèmes Rust utilisant du code C++ existant
3. Systèmes polyglottes supportant Rust (comme pour les architectures de plugins)

En raison de cette dynamique et de la longue histoire du C++ avant Rust, le premier cas est de loin le plus courant.

Comme il n'existe actuellement aucune chaîne d'outils permettant de mélanger C++ et Rust dans le même fichier source, les approches existantes en matière d'interopérabilité se concentrent sur les solutions basées sur la FFI. L'interopérabilité FFI s'effectue aujourd'hui via les ABI de plate-forme C, parce qu'elles sont moins dépendantes de la plate-forme et plus stables que les ABI de plate-forme C++. Ainsi, plus on s'appuie sur des facilités spécifiques au C++, plus il est difficile de les traduire efficacement à travers une interface basée sur le C.

Quand et où cela est-il pertinent ?

À l'approche du dixième anniversaire de sa version stable 1.0, Rust passe de la phase des « early adopters » à celle de la « early majority » dans le cycle de vie de l'adoption des technologies. Cette transition correspond à l'importance croissante accordée par l'industrie et les gouvernements à l'adoption de langages à mémoire sécurisée, et Rust se distingue comme un choix de premier ordre. Rust combine de manière unique une prise en charge robuste de la concurrence et une garantie d'absence de comportement non défini, ce qui en fait une alternative convaincante au C++ dans les environnements où le ramasse-miettes n'est pas possible. Sa fiabilité éprouvée dans ces domaines fait de Rust un outil essentiel pour des systèmes plus sûrs et plus performants.

Alors que Rust a considérablement évolué au cours de cette période, l'histoire de l'interopérabilité avec le C++ reste limitée par les fondements de l'ABI C. Une grande partie du développement a été consacrée aux bibliothèques pour faciliter l'interopérabilité avec les deux langages. Une quantité importante de développement a été consacrée aux bibliothèques pour faciliter l'interopérabilité avec C et C++, mais au niveau du langage et du compilateur, la situation reste largement inchangée par rapport aux premiers jours de Rust.

Alors que le désir d'intégrer Rust dans un plus grand nombre de codes C++ augmente, l'intérêt de rendre l'interopérabilité C++/Rust plus sûre, plus facile et plus efficace s'accroît rapidement. Bien que chaque langage adopte une approche globale différente, tous deux considèrent la sécurité comme une préoccupation essentielle dans les systèmes modernes. Rust et C++ disposent tous deux de facilités au niveau du langage et de la bibliothèque standard pour améliorer la sécurité de manière apparemment compatible, mais des avantages significatifs sont perdus lors du passage de la frontière FFI en utilisant l'ABI C.

Quel est l'impact ?

En tant que langage système, Rust a toujours été conçu pour être interopérable avec C. Même pour les langages non systèmes, C est la lingua franca pour la FFI en général et l'accès aux ressources au niveau du système d'exploitation en particulier. En tant que telle, l'interopérabilité C ↔︎ Rust est relativement simple et la charge qui pèse sur le programmeur Rust se présente sous deux formes principales :

1. La communication est limitée aux interfaces exprimables dans le système de types C, ce qui exclut une grande partie des avantages de Rust en termes d'ergonomie et de sécurité.
2. La frontière de la FFI elle-même n'est généralement pas sûre, ce qui signifie que des garanties telles que l'absence de comportement non défini et de course aux données sont perdues.

Les défis d'interopérabilité auxquels sont confrontés les développeurs de Rust se retrouvent chez les développeurs C++, qui doivent également sacrifier des caractéristiques de sécurité et d'ergonomie qui ne sont pas propres au C. La relation superset entre le C++ et le C simplifie une partie de la traduction des types d'interface, mais tous les aspects bénéfiques propres au C++ sont perdus. Même une base de code qui utilise de manière experte les caractéristiques modernes du C++ pour améliorer la sécurité et les performances doit introduire une région de code plus subtile et plus dangereuse autour du point de FFI. Il en résulte à la fois un effort supplémentaire de la part du développeur et une réduction de la qualité de la base de code pour soutenir l'interopérabilité.

La conséquence de ce coût d'interopérabilité accru est que les bases de code C++ et Rust sont moins capables d'accéder à du code précieux qui existe déjà dans l'autre langage, et que la capacité de transition des composants du système d'un langage à l'autre est réduite en dehors des limites d'interface de type C existantes. En fin de compte, cette réduction de la liberté conduit à des résultats moins bons pour tous les utilisateurs, car les technologues sont moins libres de choisir les solutions les plus efficaces.

Pourquoi cela se produit-il ?

Le langage C existe depuis le début des années 70 et le langage C++ depuis le milieu des années 80. Alors pourquoi, quatre décennies plus tard, n'y a-t-il pas de meilleur moyen d'interopérer avec C++ ? Cela s'explique en partie par le fait que toute interopérabilité est un effort bilatéral, de sorte que la qualité de l'interface dépend des langages des deux côtés. L'interface doit être définie dans des termes que les deux langages peuvent exprimer. Le fait que ces termes soient natifs du langage (comme les interfaces C pour C++) peut rendre le processus plus ou moins commode, mais la richesse fondamentale de l'interface dépend de sa capacité à exprimer la sémantique des constructions de chaque langage. Tout ce qui n'est pas nativement représentable dans l'interface doit être communiqué par une transformation bien définie vers et depuis l'interface, mais il doit également y avoir des constructions compatibles de part et d'autre. Par définition, l'interopération a lieu entre des langues différentes, de sorte que, comme pour les problèmes de traduction dans les langues naturelles, il y aura toujours une certaine perte sémantique due à la traduction.


Pourquoi la situation n'est-elle pas déjà meilleure ? Le C++ était déjà très mature à l'époque où Rust a été créé, et Rust a vu le jour au sein de Mozilla, aux côtés d'une base de code C++ de plusieurs millions de lignes, vieille de plusieurs décennies, avec l'intention explicite d'être une alternative au C++. Hormis le C, aucun des principaux langages de systèmes développés avant le C++ n'a connu d'utilisation moderne significative. Parmi les langages développés après le C++, seuls quelques-uns ont fait l'objet d'une utilisation commerciale significative : Go, Rust et Swift. L'histoire de l'interopérabilité du C++ pour tous ces langages est instructive, mais l'utilisation prévue et la gouvernance de Go et de Swift sont très différentes de celles de Rust. L'élément social est peut-être le plus important : bien qu'initialement développé dans le cadre de la recherche Mozilla, le projet Rust a été dirigé par des bénévoles et l'innovation par le biais d'un processus RFC qui est plutôt ascendant, alors que les entreprises à l'origine de Go et de Swift ont continué à être plus actives dans la gestion de ces langages et ont poursuivi l'interopérabilité qui s'aligne sur les objectifs de leurs langages. Conformément à l'éthique collaborative et au modèle de gouvernance de la communauté Rust, l'approche typique de Rust a été de donner la priorité aux solutions dans les bibliothèques externes tout en minimisant les changements dans le langage et la bibliothèque standard. Cette approche est évidente dans l'histoire de l'interopérabilité C++ de Rust, où la plupart des travaux ont été réalisés dans des bibliothèques externes. Les responsables du projet Rust connaissent bien cette dynamique, et ce document est une tentative d'explorer l'espace du problème d'une manière collaborative et stratégique.

La réalité actuelle

La situation de l'interopérabilité entre C++ et Rust est aujourd'hui très différente de celle qui prévalait lors de la création de Rust. Bien qu'il existe de nombreux autres outils, les trois plus populaires ont été publiés à plusieurs années d'intervalle sur crates.io :

• bindgen (appeler C depuis Rust) : 2015
• cbindgen (appeler Rust depuis C) : 2017
• cxx (C++ ↔︎ Rust) : 2020

Bien que les trois soient toujours activement maintenus, les deux premiers sont plus complets en raison de leur histoire beaucoup plus longue et de leur portée plus réduite. En tant que crate la plus populaire ciblant l'interopérabilité du C++, cxx est résolument plus ambitieuse et également moins complète. L'objectif déclaré de cxx est de fournir un moyen sûr d'interopérer avec C++ avec un surcoût négligeable. Ceci est basé sur la reconnaissance du fait que C++ et Rust partagent beaucoup plus de concepts de haut niveau que l'un ou l'autre ne le fait avec C. Le but est de décrire cette frontière de langage en Rust et C++, ce qui fournit plus de fidélité que l'ABI C utilisé par bindgen et cbindgen. Il s'agit d'une direction prometteuse et le potentiel de cette approche mérite d'être exploré plus avant. En même temps, il y a beaucoup de limitations et de types Rust fondamentaux qui ne sont pas encore implémentés. Enfin, la bibliothèque est auto-décrite comme « restrictive et avec des opinions » et son but n'est pas de fournir une interopérabilité arbitraire, mais plutôt de fournir une abstraction plus sûre et de plus haut niveau pour combler le fossé conceptuel plus étroit entre ces deux langages.

À l'heure actuelle, l'interopérabilité entre C++ et Rust est meilleure qu'elle ne l'a jamais été, mais il existe encore des défis importants qui servent à limiter la faisabilité de l'introduction de Rust dans les bases de code C++ existantes ainsi qu'à restreindre son utilisation à des frontières bien définies plutôt qu'à une interopérabilité arbitraire. Enfin, il convient de mentionner que l'intégration avec les systèmes de construction constitue un défi particulier pour l'interopérabilité, mais qu'une stratégie pour l'aborder doit encore être développée. Il est probable que des approches bénéfiques émergeront au fur et à mesure que les stratégies au niveau de l'interface seront affinées en travaux tactiques.

Conséquences

Toute utilisation de la technologie implique des compromis et l'adoption de toute nouvelle technologie entraîne des frictions, d'abord pour que les technologues apprennent à l'utiliser et ensuite pour l'intégrer dans des systèmes où l'interopérabilité avec les technologies existantes est nécessaire. Il n'est ni possible ni souhaitable de remplacer tout le code C++ par du Rust. La détermination du moment où la réécriture ou l'augmentation des systèmes C++ avec du code Rust entraîne un bénéfice net nécessite des analyses par système. Indépendamment des choix de mise en œuvre spécifiques, l'objectif de la technologie est d'améliorer la vie des gens. À cette fin, la réduction des frictions inutiles et la maximisation de la liberté dans les choix des technologues sont conformes à l'initiative d'interopérabilité et à l'intérêt général.

Le(s) objectif(s)

Conformément à la vision énoncée au début, l'objectif est de rendre l'interopérabilité « accessible et abordable », mais ce à quoi cela ressemble diffère beaucoup en fonction du public. Une façon de conceptualiser le summum de l'accessibilité est de considérer l'idéal d'une interopérabilité sans friction : qu'il s'agisse de Rust ou de C++, l'utilisation du code dans l'autre langage n'est pas plus difficile que s'il était implémenté dans le même langage. Le fait que chaque langage ait des abstractions fondamentalement différentes signifie que cet objectif n'est pas plus réalisable qu'une traduction parfaite entre les langues naturelles, mais il s'agit néanmoins d'un idéal utile car il peut fournir une direction à suivre et ainsi identifier les objectifs en cours de route ainsi que les obstacles qui interviennent.

Voici quelques idéaux d'interopérabilité sans friction qui méritent d'être poursuivis :

• Un minimum de travail : la quantité de code supplémentaire à écrire par l'utilisateur n'est pas supérieure à celle de la langue maternelle.
• Pas de complexité supplémentaire : les détails de l'interface elle-même ne sont pas pertinents pour le code de part et d'autre de l'interface.
• Sécurité maximale : l'interopérabilité doit nécessiter un minimum de code non sécurisé.
• Correction maximale : l'utilisation incorrecte des facilités d'interopérabilité elles-mêmes devrait être une erreur au moment de la compilation18
• Performance maximale : l'interopérabilité doit aspirer au principe de l'absence de surcharge.

À ce stade, il est prématuré de distiller ces qualités en objectifs tactiquement réalisables, mais, considérée comme une grande stratégie, l'interopérabilité sans friction peut être poursuivie au moyen de trois stratégies parallèles :

1. à court terme : améliorer les outils existants, résoudre les problèmes qui ont été bloqués en raison d'un manque d'appropriation, d'un effort concerté ou d'une hésitation à stabiliser une mise en œuvre
2. à long terme : jeter les bases d'une forme plus riche d'interopérabilité au niveau du langage, du compilateur et de la bibliothèque standard.
3. Interopérabilité sociale : s'engager avec la communauté C++, y compris ses utilisateurs et ses processus de normalisation, pour construire le pont des deux côtés et améliorer simultanément les deux langages.

Dans le cadre de toutes les stratégies, l'initiative s'appuiera sur plusieurs axiomes de conception :

• Construire les fondations d'un avenir meilleur tout en améliorant activement le présent.
• Rechercher une interopérabilité de haute qualité des deux côtés
• Rechercher une interopérabilité générale (non liée à une chaîne d'outils ou à une interface utilisateur spécifique).
• Éviter les changements à Rust lui-même qui mineraient ses valeurs fondamentales
• Ne modifier le langage ou la bibliothèque standard que lorsque les solutions des bibliothèques externes sont insuffisantes.

Conclusions et prochaines étapes

En tant qu'énoncé du problème et vision stratégique, ce document décrit le travail futur de l'initiative C++/Rust Interop de la Fondation Rust. Il sert à assurer la transparence et à encourager la contribution et la collaboration avec le projet Rust ainsi qu'avec les communautés Rust et C++. Plus concrètement, il sert de structure pour allouer les ressources matérielles, financières et humaines de l'initiative. En fin de compte, l'orientation de l'interopérabilité C++/Rust sera déterminée par les actions de nombreuses personnes dans les deux communautés et un travail important sur les efforts à court et à long terme est en cours. À ce jour, peu de travaux ont été menés pour faciliter la coopération sociale entre les deux langages, et bien que de meilleures solutions pour les utilisateurs des deux langages soient plus susceptibles d'émerger de cette stratégie, les trois stratégies sont indépendantes et se renforcent mutuellement. Voici les prochaines étapes pour chaque stratégie :

Court terme

Le plus grand avantage qui peut être réalisé à court terme sera de s'appuyer sur les solutions qui ont déjà fait leurs preuves et qui sont utilisées dans la pratique aujourd'hui. La distillation de cette stratégie en tactiques viables impliquera 3 éléments :

1. Identifier les problèmes dans les bibliothèques, Rust lui-même ou les dépendances qui entravent les efforts actifs d'interopérabilité aujourd'hui.
2. Donner la priorité aux questions qui représentent une bonne proposition de valeur pour les ressources matérielles, techniques ou sociales à la disposition de l'initiative.
3. Appliquer les ressources en dotant la Fondation en personnel ou en soutenant matériellement des technologues externes.

A long terme

Pour améliorer considérablement l'interopérabilité, les améliorations progressives ne suffisent pas. La stratégie à long terme visera donc à se rapprocher concrètement de l'idéal d'une interopérabilité sans friction. Cela nécessite une interface fondamentalement plus riche entre les langages, axée sur l'espace conceptuel partagé entre C++ et Rust, avec un accent sur la sécurité et l'efficacité. Pour être utile, cela nécessite une large adhésion et une coopération entre les différentes équipes du projet. Les éléments de cette stratégie sont les suivants :

• Établir des relations et recueillir les contributions et le soutien des principales parties prenantes au projet et d'autres experts compétents.
• Déterminer une structure viable pour discuter et prendre des décisions de haut niveau sur les éléments fondamentaux nécessaires à la construction d'une expérience d'interopérabilité plus riche et sur les voies qui ne seront pas poursuivies.
• Une fois que les éléments fondamentaux exploitables sont déterminés, rechercher le soutien d'équipes individuelles (peut-être par le biais d'objectifs de projet) et allouer des ressources par le biais de subventions de la Fondation.

Le premier élément est en cours et sera maintenu. Le deuxième élément nécessite une approche descendante, axée sur l'espace-problème, ce qui n'est pas très conventionnel pour le projet Rust et la communauté, mais il semble que l'on soit favorable à l'amélioration de cette capacité. Il s'agit là d'un des principaux défis et avantages potentiels de l'initiative. Le troisième élément dépend quelque peu du succès de la première itération des objectifs du projet, mais il semble jusqu'à présent bien adapté au soutien de nouveaux travaux importants entre le projet et la fondation.

Interopérabilité sociale

La troisième stratégie est basée sur la reconnaissance du fait que si Rust a été inventé avec l'intention de fournir une alternative plus sûre à C++, les deux langages continueront d'exister dans un avenir prévisible et une interopérabilité de haute qualité tendra à améliorer les projets qui utilisent les deux langages. Une certaine compétitivité entre les langages qui visent des cas d'utilisation similaires est inévitable, mais il y a plus à gagner de la coopération car l'innovation technologique n'est pas un jeu à somme nulle. Les éléments de cette stratégie sont les suivants :

• Établir des relations et recueillir les commentaires et le soutien des principaux acteurs des organismes de normalisation du C++ et d'autres experts compétents.
• Faciliter les présentations et les discussions entre les membres des deux communautés afin d'identifier les valeurs communes et les stratégies mutuellement bénéfiques.
• Déterminer si une coopération formelle peut être établie et travailler pour la soutenir grâce aux ressources et aux membres de la Fondation.

Des trois stratégies, celle-ci est peut-être la plus ambitieuse et la moins sûre. C'est aussi celle dont la maturation sera probablement la plus longue. Le travail a donc déjà commencé, mais aucune des autres stratégies n'en dépend.

Prochaines étapes

Cet énoncé de problème et les stratégies associées constituent la première étape vers l'engagement des communautés Rust et C++ au sens large. Il reste encore beaucoup de choses à décider et les nouvelles idées ainsi que les contributions constructives seront extrêmement précieuses.

Source : Annonce de la Fondation Rust

Et vous ?

Pensez-vous que cet énoncé de problème est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

La transition de Google vers des langages à mémoire sécurisée comme Rust prendra plusieurs années : en attendant, Google applique également des principes de conception sécurisée à sa base de code C++ existante

La fondation Rust examine et améliore la sécurité de Rust : la fondation Rust étudie le développement d'un modèle d'infrastructure à clé publique (PKI) pour le langage Rust, selon son dernier rapport

La DARPA veut transposer automatiquement le code C en Rust à l'aide de l'IA. Le ministère américain de la Défense a lancé un projet d'IA qui peut automatiser la conversion de l'ancien code C en Rust

[RenarddeFeu]

Rust serait un game changer s'il était interopérable avec le C++ sans passer par les types C.