GrapheneOS révèle une corruption mémoire Bluetooth grâce à ARM MTE
(grapheneos.social)- La prise en charge du tagging mémoire matériel sur les Pixel 8 et Pixel 8 Pro a mis en évidence un nouveau bug de corruption mémoire dans Bluetooth LE introduit avec Android 14 QPR2
- La cause a été identifiée comme un bug upstream de use-after-free dans Bluetooth LE, et GrapheneOS a préparé un correctif qui sera inclus dans une nouvelle release
- Un utilisateur qui reproduisait le problème avec les Samsung Galaxy Buds2 Pro en mode Bluetooth LE a confirmé que le correctif fonctionne, et le Pixel OS d’origine est également affecté
- GrapheneOS estime qu’il serait inapproprié, même à court terme, de contourner le problème en désactivant le tagging mémoire pour ce processus, Bluetooth constituant une grande surface d’attaque
- Une partie du code Bluetooth d’Android a été portée en Rust, mais il reste du travail sur le portage du code restant ainsi que sur les tests sur appareils réels avec des builds HWASan et MTE
Bug Bluetooth LE d’Android 14 QPR2 et correctif
- GrapheneOS a découvert un bug de corruption mémoire dans Bluetooth LE d’Android 14 QPR2 grâce à la prise en charge du tagging mémoire matériel sur les Pixel 8 et Pixel 8 Pro
- Le problème ne se produit pas avec tous les appareils Bluetooth, et n’est reproductible qu’avec certains appareils Bluetooth LE
- GrapheneOS étudie des moyens de corriger ou de désactiver temporairement la fonctionnalité nouvellement introduite
- La cause a été identifiée comme un bug upstream de use-after-free dans Bluetooth LE, et GrapheneOS a développé un patch
- La priorité est de déployer rapidement une release de GrapheneOS intégrant ce correctif
- Le bug sera signalé comme bug de sécurité Android
- Ce correctif semble aussi résoudre une régression de l’audio BLE
- Un utilisateur qui reproduisait le problème en utilisant les Samsung Galaxy Buds2 Pro en mode Bluetooth LE a confirmé que le correctif fonctionne
- Le même problème affecte aussi le Pixel OS d’origine
- GrapheneOS l’a détecté grâce à la prise en charge du tagging mémoire dans hardened_malloc, et a ajouté une notification de crash MTE contenant un rapport copiable
Mise en œuvre de MTE et défis du code Bluetooth d’Android
- GrapheneOS considère qu’un contournement consistant à désactiver le tagging mémoire pour ce processus n’est pas approprié, même à court terme
- Bluetooth représente une grande surface d’attaque, indépendamment de la faisabilité réelle de l’exploitation de ce bug
- Android a porté une part importante de son code Bluetooth en Rust, mais davantage de ressources sont nécessaires pour porter le code restant
- En conditions réelles, davantage de tests de builds HWASan et MTE sont nécessaires sur une variété d’appareils Bluetooth
- Les appareils Pixel intègrent MTE, une fonctionnalité majeure de sécurité matérielle, mais l’OS par défaut ne l’active pas afin d’économiser 3,125 % d’utilisation mémoire et cache
- Le calcul est basé sur un tag de 4 bits pour chaque bloc de 16 octets de mémoire taguée
- Le heap MTE a un surcoût de performance proche de 0 % en mode asynchrone (async mode), et en mode asymétrique il coûte moins que des mitigations existantes comme SSP
- GrapheneOS active MTE par défaut pour les applications installées par l’utilisateur dont la compatibilité avec l’OS par défaut est connue
- Il peut être activé en opt-in pour toutes les applications installées par l’utilisateur dans Settings > Security
- Le système fournit une notification permettant de copier les rapports de crash ainsi qu’un toggle par application
- L’implémentation MTE de hardened_malloc par GrapheneOS utilise des tags aléatoires standard et un tag dédié pour
free, tout en excluant dynamiquement le tag précédent ainsi que les tags adjacents actuel ou précédent - L’intégration Chromium a été corrigée, et PartitionAlloc sera également amélioré
1 commentaires
Avis Hacker News
C’est étrange que les Pixels intègrent une grosse fonctionnalité de sécurité matérielle appelée MTE, mais que l’OS ne l’active pas pour économiser 3,125 % d’utilisation mémoire/cache.
J’aimerais vraiment voir comment l’équipe Pixel justifie cette décision, et comprendre le raisonnement qui consiste à désactiver une fonctionnalité de sécurité aussi importante pour un gain de performance minime.
Cela dit, GrapheneOS est un très beau projet, mais il ne prend en charge qu’environ 11 appareils, tandis qu’un changement AOSP doit tenir compte d’un écosystème OEM beaucoup plus vaste.
On cherche toujours des façons d’améliorer Android, mais critiquer le déploiement d’une fonctionnalité donnée en ignorant l’écosystème OEM plus large me semble assez réducteur.
Il est très peu probable que cette fonctionnalité n’ait pas été activée à cause de 3 % de mémoire/cache, et j’imagine qu’il y avait d’autres considérations.
Au moment de décider s’il faut activer ou non la fonctionnalité, c’est probablement un facteur plus important.
Puisqu’il est dit que les autres OS ne sont pas non plus livrés aujourd’hui avec MTE activé, la décision de l’activer ou non est probablement plus nuancée.
Des gens chez Google ont poussé dès le départ le MTE matériel, et cela venait d’équipes impliquées dans ASAN, syzkaller, etc.
Ce n’était pas l’équipe Android, mais il y avait de l’aide et du soutien côté Android, et bien sûr une collaboration avec ARM et d’autres.
Comme je dirigeais ces équipes à l’époque, je connais bien les compromis : il n’y a pas que des questions de mémoire ou de cache.
Il est vrai que MTE peut être activé et désactivé dynamiquement, et qu’il a été conçu pour avoir un coût en performances proche de zéro, mais à l’époque son usage principal était la recherche de bugs par échantillonnage.
Si l’on peut l’activer seulement 1 % du temps sur tout un parc d’appareils suffisamment vaste, on peut trouver des bugs très rapidement, et l’utiliser aussi pour les tests internes.
Autrement dit, l’objectif était de pouvoir activer et désactiver à la demande une fonctionnalité comparable à ASAN.
L’utiliser comme mesure d’atténuation de sécurité activée en permanence était une possibilité secondaire, et il y a des problèmes au-delà de l’overhead mémoire.
Par exemple, on peut soudainement créer beaucoup de crashs visibles par l’utilisateur ; un téléphone avec MTE peut crasher là où un téléphone sans MTE ne crashe pas, ce qui manque aussi de cohérence.
Du point de vue des développeurs, ce ne serait pas forcément bien accueilli non plus s’il fallait forcer tout le monde à tester sur le quasi unique téléphone avec MTE activé.
Cela peut empêcher des exploits de sécurité et transformer une exploitation en crash.
Cela peut aussi détecter des bugs inoffensifs.
Mais comme indiqué plus haut, je ne supposerais pas que ce n’est pas utilisé ; il me semble plus juste de dire que ce n’est pas activé en permanence en production.
Quelqu’un ayant déjà introduit ce type de fonctionnalité matérielle dirait sans doute que le simple fait que le système démarre, fonctionne, puis ne crashe sous MTE que dans certains comportements précis est au contraire un bon signe qu’elle est déjà utilisée.
Si elle ne l’était pas, il y aurait probablement eu un million de crashs.
J’ajouterais qu’il n’est pas évident non plus que ce soit la meilleure option comme mesure d’atténuation à l’exécution.
Le Pixel standard n’est peut-être pas livré avec cette fonctionnalité activée par défaut pour l’utilisateur final, mais n’importe qui peut activer Memory Tagging Extensions dans les options développeur s’il le souhaite.
On peut la laisser active jusqu’à désactivation, ou l’activer seulement pour une session afin de tester une application spécifique.
Dans l’OS Pixel par défaut, activer la prise en charge du marquage mémoire via les options développeur ne fait que la rendre disponible ; elle n’est pas réellement utilisée.
Il faut aussi activer le marquage de la mémoire heap avec
setpropdepuis un shell Android Debug Bridge (ADB).Si les allocations ne sont pas taguées, le simple fait que ce soit activé n’a aucune valeur.
Il est possible d’activer complètement le MTE du heap en espace utilisateur sur l’OS par défaut via Scudo, l’allocateur par défaut, mais ce n’est actuellement pas une implémentation spécialement renforcée.
KASan avec backend MTE peut aussi être utilisé via
setprop, mais il n’est pas conçu aujourd’hui comme mécanisme de durcissement, et il n’est pas clair qu’il le devienne.Le noyau aura probablement besoin d’une implémentation MTE distincte, qui ne fasse pas partie de KASan ; GrapheneOS ne l’a pas encore fait non plus, donc le durcissement MTE actuel est une fonctionnalité de l’espace utilisateur.
GrapheneOS utilise sa propre implémentation de marquage mémoire matériel pour hardened_malloc, avec des propriétés de sécurité plus fortes.
Pour l’activer par défaut dans l’OS de base, il a fallu corriger ou contourner plusieurs problèmes, dont celui-ci.
Au lieu d’utiliser le MTE asynchrone sur les cœurs principaux, il utilise le mode asymétrique sur tous les cœurs.
Le mode asymétrique est asynchrone pour les écritures et synchrone pour les lectures, ce qui bloque correctement l’exploit sans laisser de fenêtre d’opportunité pour qu’il réussisse.
Les appels système sont vérifiés, et io_uring, qui pourrait constituer une autre voie de contournement, est limité par SELinux sur Android à seulement deux processus système essentiels.
fastbootd n’est utilisé que pendant l’installation, et snapuserd est utilisé par l’OS principal après l’application d’une mise à jour.
GrapheneOS utilise toujours le MTE du heap pour l’OS de base et les applications dont la compatibilité est confirmée.
Pour les applications installées par l’utilisateur qui ne figurent pas dans la base de compatibilité et ne se déclarent pas elles-mêmes compatibles, il fournit un interrupteur MTE par application.
L’utilisateur peut aussi choisir de forcer MTE par défaut pour les applications installées par l’utilisateur, et n’exclure que les applications incompatibles.
Pour rendre cela réellement utilisable, il a fallu un système de rapports de crash visibles par l’utilisateur, avec la possibilité de copier facilement des rapports utiles aux développeurs pour les leur envoyer.
Quand je cherche Memory Tagging Extensions dans les paramètres, il indique que l’option existe, mais je me suis demandé si elle était cachée quelque part ; en fait, c’était réservé aux téléphones Pixel 8 : https://news.ycombinator.com/item?id=38125379
GrapheneOS est tellement en avance sur les autres en matière de sécurité qu’on en vient à se demander pourquoi choisir autre chose que du matériel Pixel
Mais je veux vraiment une batterie remplaçable
Je ne comprends pas pourquoi tout est si médiocre de nos jours
Les autres appareils Android n’en sont même pas proches
La prise en charge du marquage mémoire matériel est l’un des nombreux grands avantages des Pixel en matière de sécurité
La liste officielle des exigences matérielles est ici : https://grapheneos.org/faq#future-devices
Ces exigences sont pleinement satisfaites par les Pixel de 8e génération
Il ne manque aux Pixel de 6e/7e génération que MTE, BTI et PAC, mais MTE est la fonctionnalité la plus précieuse de la liste des exigences matérielles
Des correctifs de sécurité corrects sont plus importants, et ils ne sont pas fournis de la même manière en dehors des Pixel
Android a des versions mensuelles, trimestrielles et annuelles
Les autres OEM Android ne fournissent, parmi les rétroportages de sécurité mensuels, que l’ensemble des correctifs de sévérité Critical/High, et n’incluent généralement pas la plupart des correctifs de sévérité Moderate/Low, dont la plupart des correctifs de protection de la vie privée
Utiliser un OS alternatif pour fournir ces correctifs atténue en partie le problème, mais les OS alternatifs pour ces appareils reviennent souvent en arrière sur la sécurité de plusieurs façons
Le firmware et une grande partie du code de prise en charge des appareils viennent en réalité de l’OEM
Il est possible d’exécuter Android 14 QPR2 au-dessus d’un noyau/de pilotes Android 12, mais on passe alors à côté d’améliorations de sécurité sur de grandes parties de l’OS
Les batteries des Pixel ne sont pas simples à remplacer sans endommager l’appareil, mais c’est officiellement pris en charge et des pièces officielles existent : https://www.ifixit.com/Device/Google_Pixel
Nous ne pouvons pas prendre en charge des appareils non sécurisés qui ne disposent même pas des bases
Notre liste d’exigences matérielles combine des éléments très basiques que la plupart des OEM Android ne fournissent pas, et des fonctionnalités avancées comme MTE, que nous considérons désormais comme une exigence de base pour une sécurité correcte
Nous aimerions prendre en charge d’autres appareils, mais il faut qu’ils satisfassent ces exigences
Le marquage mémoire est une fonctionnalité de base prise en charge par les cœurs Cortex ARMv9 standard
Il est regrettable que Qualcomm ne l’implémente pas et que les OEM utilisant des SoC qui le prennent en charge ne le configurent pas non plus
C’est triste d’avoir une fonctionnalité dans l’architecture CPU mais de ne pas pouvoir l’utiliser à cause du SoC ou de l’OEM
Heureusement, le Pixel 8 devrait être pris en charge pendant 7 ans
Apple et Samsung sont difficiles à croire, et Google est devenu le moins mauvais choix
Ce serait bien que quelqu’un qui utilise GrapheneOS réponde
Cela dit, quand je suis allé récemment avec ma femme à Orlando, en Floride, à Disney World et Universal Studios, même si les applis fonctionnaient globalement avec les Google Play Services sandboxés, il y a eu des problèmes agaçants
L’appli My Disney Experience avait pas mal d’erreurs liées à la localisation, et affichait par intermittence qu’il fallait être aux États-Unis ou au Canada pour effectuer certaines actions importantes, ce qui nous a obligés à utiliser le téléphone de ma femme comme solution de contournement
Dans l’appli Universal, je ne pouvais pas me connecter à mon compte, alors que cela marchait bien sur le Samsung Galaxy standard de ma femme, donc ça semblait être un problème lié à GrapheneOS
Par ailleurs, si vous payez par carte bancaire avec Google Wallet, ce n’est pas pris en charge parce que Google ne certifie pas GrapheneOS
Les autres fonctions de Wallet marchent
Uber fonctionne sans problème
À part ça, je n’utilise pas d’apps propriétaires
Si vous comptez surtout utiliser des applis libres/open source, vous ne devriez pas avoir de problème
La plupart des applis propriétaires fonctionnent avec les Google Play Services sandboxés, mais si l’une d’elles est vraiment critique pour votre travail, vous pourriez rencontrer des problèmes agaçants comme ceux que j’ai eus avec Universal Studio et My Disney Experience
J’ai utilisé un câble USB ordinaire et adb en ligne de commande sous Linux, mais la méthode recommandée passe par WebUSB dans Chromium et devrait être plus simple pour les non-techniciens
Cela dit, dans mon cas, ça n’a pas bien marché
Il y a les Google Play Services sandboxés, ce qui combine bien le meilleur des deux mondes : on peut installer toutes sortes d’applis propriétaires qui rendent la vie moderne supportable, sans que Google Play ait un accès illimité à tout le téléphone
Si vous voulez davantage d’isolation, vous pouvez créer un utilisateur séparé et exécuter les composants liés à Google Play dans ce compte
J’ai essayé brièvement, mais personnellement j’ai trouvé pénible de changer d’utilisateur à chaque fois
Mon téléphone n’a jamais planté, et les applis bancaires fonctionnent
L’appareil est un Pixel 6a
On peut aussi acheter un appareil déjà installé, mais presque tout le monde peut utiliser l’installateur web
C’est particulièrement simple sur Android, ChromeOS et macOS ; Windows est un peu plus délicat parce qu’il faut installer des pilotes
Sur Linux de bureau, il faut installer des règles udev, et certaines distributions aux versions logicielles figées ont des services bogués qui gênent
Même une personne non technique peut le faire, il suffit d’un navigateur prenant en charge WebUSB
Aucun logiciel spécial n’est nécessaire
Au quotidien, avec Google Play sandboxé, c’est presque identique à l’OS Pixel de base, et la compatibilité des applis est quasiment similaire
Vous n’allez probablement pas subir significativement plus de plantages
Il existe des rapports de plantage destinés à l’utilisateur, absents de l’OS de base, donc vous pouvez remarquer des plantages dont vous n’auriez auparavant pas eu connaissance
Les applis boguées avec de la corruption mémoire peuvent planter jusqu’à ce que vous activiez le mode de compatibilité par appli, surtout si vous choisissez de forcer MTE pour toutes les applis installées par l’utilisateur
Les applis bancaires fonctionnent si la banque autorise les OS non certifiés par Google, ce qui est encore le cas de la plupart
Cela dit, les banques bloquent de plus en plus les OS non certifiés par Google, et c’est fondamentalement un problème de régulation anticoncurrentielle qui devrait être traité comme tel
En attendant, nous essayons de convaincre les banques d’utiliser https://grapheneos.org/articles/attestation-compatibility-guide
Les fonctionnalités de sécurité supplémentaires, les réglages de sandboxing et le hardened memory allocator entraînent une légère lenteur, et c’est plus contraignant que d’utiliser Android stock en appuyant sur OK à toutes les demandes d’accès aux données
La configuration initiale et le fait de comprendre ce qui distingue GrapheneOS, ainsi que la manière d’utiliser ses fonctions de sécurité, demandent aussi un peu de temps
En 4 ans d’utilisation, je n’ai pas eu de plantage
En tout cas aucun plantage de tout le système, et les plantages nécessitant des jours de débogage n’arrivent pas d’après mon expérience, car le matériel Pixel et le logiciel sont bien adaptés l’un à l’autre
Les applis bancaires, ça dépend de l’appli
Certaines fonctionnent sans Play Services, la plupart fonctionnent avec les Play Services sandboxés, et une toute petite minorité ne fonctionne pas du tout
Si vous indiquez quelle banque vous utilisez, d’autres utilisateurs pourront vérifier si ça fonctionne
Même la méthode d’installation difficile consiste simplement à connecter le téléphone en USB, à appuyer un peu sur les boutons marche/volume, puis à copier-coller deux ou trois commandes dans un terminal
La méthode facile consiste seulement à brancher le téléphone à l’ordinateur et à cliquer sur un bouton d’installation en un clic qui fonctionne dans le navigateur Chrome
Je l’utilise comme OS quotidien presque sans interruption depuis peu après la sortie du Google Pixel 6, et je n’ai jamais eu un seul plantage
Je n’ai jamais eu de bug, ni besoin de déboguer, corriger ou maintenir quoi que ce soit
Toutes les applis que j’ai essayées ont simplement fonctionné comme sur Android stock, et honnêtement je perçois à peine la différence
Il m’arrive même d’oublier que ce n’est pas l’OS qui était installé d’origine sur le téléphone
Personnellement, l’appli bancaire Discover fonctionne, mais je ne sais pas avec certitude pour les autres
Cela dit, comme il y a les Google Play services et que le bootloader est verrouillé après l’installation, je suppose que la plupart devraient fonctionner
En 2024, il nous faut des systèmes d’exploitation formellement vérifiés, des applications et des outils qui reprennent l’esprit de seL4, mais avec un niveau d’exigence encore plus strict
À notre époque, assembler des bases de code surconçues et à peine testées avec des langages fragiles et dangereux, c’est créer une situation où des acteurs étrangers peuvent pirater des systèmes et des utilisateurs peuvent mourir, ainsi qu’une vaste surface d’attaque faite de bugs agaçants, de malwares et de piratages
Il faut en plus offrir par-dessus une expérience utilisateur propre et intégrée, ainsi que des fonctionnalités utilisables ; sinon, tout l’effort d’ingénierie ne sert à rien
Il suffit de regarder Qubes OS
Existe-t-il de bons ordinateurs monocartes qui implémentent Arm MTE ? Quelque chose comme les Raspberry Pi récents
Le RasPi 5 est un quad A76 et utilise les extensions v8.2, alors que MTE est en v8.5
Que vaut MTE par rapport à CHERI ?
MTE sert à trouver des bugs de sécurité potentiels, ce n’est pas une vraie protection
Le tag ne fait que 4 bits et l’application peut le falsifier ; donc si un attaquant doit trouver le bon tag, il a 1 chance sur 16 d’y arriver en le choisissant au hasard
L’idée avec MTE est de pouvoir détecter des accès incorrects qui se produisent parfois même sans attaquant, et qui ne provoquent pas forcément de mauvaises conséquences en pratique
Pensez à un dépassement de tampon classique : les mots juste après la fin du buffer peuvent ne pas être utilisés à autre chose, donc le programme peut en fait continuer à fonctionner
MTE détecte ce genre d’accès, ce qui permet de l’investiguer et de le corriger avant qu’il ne devienne un exploit exploitable
Il peut toutefois fournir de fortes propriétés de sécurité déterministes grâce aux tags réservés
Ce qui n’est pas tagué a le tag 0, et ce qui est tagué a par défaut un tag non nul à cause de l’exclusion par défaut
D’autres tags peuvent aussi être exclus statiquement ou dynamiquement par instruction, mais si l’on utilise le tag 0 pour des usages internes comme la mémoire libérée, on peut exploiter le fait qu’aucun pointeur tagué ne peut y accéder
Dans hardened_malloc, pour les slots d’allocation, les tags adjacents et les tags précédemment utilisés sont exclus dynamiquement
Cela fournit une protection déterministe contre les dépassements linéaires et les petits dépassements
Pour les use-after-free, un pointeur vers une allocation libérée ne peut pas y accéder pendant qu’elle est libérée ni juste après sa réallocation ; il doit attendre qu’elle soit attribuée de nouveau, et à ce moment-là la probabilité d’avoir le bon tag est de 1/15
Cela se combine bien avec les autres propriétés de sécurité de hardened_malloc
Des zones de quarantaine FIFO/aléatoires pour l’allocation slab et la mémoire virtuelle retardent encore davantage la réutilisation et la rendent non déterministe
Jusqu’au-delà de 128k, les emplacements mémoire ne sont jamais réutilisés entre différentes classes de tailles d’allocation ; chaque classe se trouve dans une zone différente, et les métadonnées sont toutes dans une autre zone réservée
Dans le cas général, MTE n’a actuellement que 4 bits, donc la probabilité de contournement est d’environ 1/15
Il serait facile de l’étendre pour prendre en charge 8 bits, et il existe d’autres bits disponibles si l’on n’utilise pas PAC
En théorie, dans un espace d’adressage général de 39 bits, il serait possible de prendre en charge jusqu’à 16 bits de MTE pour des espaces d’adressage de 48 bits ou plus
C’est actuellement fixé à 4 bits ; j’ai entendu dire que ce choix avait été fait plutôt que 8 bits afin de pouvoir stocker des bits supplémentaires dans la mémoire de parité ECC
Mais il ne les détecte pas aussi fiablement que CHERI
Il n’y a pas de protection des tags, et l’espace de tags est réduit (2^4)
J’ai hâte que le matériel grand public rattrape Solaris SPARC de 2015, voire les architectures de marquage mémoire antérieures, et qu’on finisse par maîtriser les problèmes de corruption mémoire
Bien sûr, on a tendance à balayer ces problèmes en disant qu’ils ne sont causés que par des développeurs incompétents
Ce n’est pas un problème de “développeurs incompétents”, c’est le problème de tout le monde
La corruption mémoire est pratiquement une fonctionnalité du langage en C/C++
Il vaut mieux ne pas propager l’idée que c’est la faute des idiots
Presque personne ne se considère comme idiot, et j’ai vu des codeurs vraiment brillants produire des bugs mémoire absurdes
Cela fait simplement partie du domaine de ces langages, et ce n’est pas une question de “si”, mais de “quand”
J’aime bien la phrase glissée au passage selon laquelle Android a déplacé une grande partie du code Bluetooth vers Rust, et que cela montre pourquoi il faut consacrer davantage de ressources à porter le reste du code vers Rust
J’ai utilisé C et C++ pendant des années, mais je n’ai pas d’expérience en Rust, donc je me demande quel niveau de refactoring est nécessaire lorsqu’on porte du C vers Rust
Pour découper la question : 1. Dans quelle mesure C se traduit-il directement en Rust ? Rust impose-t-il une réorganisation de la structure ou du refactoring ?
2. Comment Google aborde-t-il cela ? Cherchent-ils à “traduire” le plus fidèlement possible, ou y voient-ils une occasion de réécriture/refactoring à grande échelle ?
Je me demande aussi si la pile Bluetooth d’Android pourra un jour être utilisée sur un système desktop de distribution Linux standard
Il y avait beaucoup de références circulaires : les modules communiquaient entre eux via un “bus de signaux” avec callbacks, et j’ai eu l’impression de devoir lutter contre Rust plutôt que d’être aidé par lui
Même là où les données pouvaient être stockées inline en C++, il fallait beaucoup de Box, c’est-à-dire des pointeurs vers le tas
En conclusion, pour un simple outil en ligne de commande ou une architecture requête-réponse, un portage vers Rust est probablement facile
Plus généralement, si la structure du code se prête bien à l’allocation par arène, la transposer en ajoutant des annotations de durée de vie aux références ne pose pas de gros problème
Mais si vous avez écrit du code à la manière d’un programmeur C, avec des références circulaires — du code certes assez laid — Rust donne l’impression d’une montée raide, et ce n’est pas un bon point de départ
Il faudrait d’abord modifier la structure du code C++ pour déplacer la propriété vers un parent commun
Je pense que cela irait mieux ainsi
Je vais continuer à apprendre Rust par itérations, mais rester sur le C++ tant que le code ne correspondra pas mieux à Rust
Il faudra réarchitecturer une bonne partie de ce que vous écrivez
C’est inévitable à cause de la manière dont Rust garantit la sécurité mémoire