Google développe des parties d'Android dans Rust pour améliorer la sécurité

Google écrit et réécrit des parties d'Android dans Rust pour améliorer la sécurité du système d'exploitation dans son ensemble, par rapport au C et au C++. Lisez la suite pour en savoir plus !

Android en tant que solution complète de système d'exploitation implique de nombreuses pièces mobiles. De manière très générale, ces éléments sont l’écosystème des applications, puis le système d’exploitation lui-même. En tant que développeur, le langage de programmation que vous préférez varie en fonction de la partie d'Android sur laquelle vous travaillez. Pour les développeurs d'applications, Java et Kotlin sont des options populaires. Pour les développeurs travaillant sur le système d’exploitation et ses niveaux inférieurs, C et C++ ont jusqu’à présent été des choix populaires. Aujourd'hui, Google ajoute une troisième option pour les développeurs de systèmes d'exploitation, car le projet Android Open Source prend désormais en charge le langage de programmation Rust pour développer le système d'exploitation lui-même.

Limites du C et du C++

Les niveaux inférieurs du système d'exploitation Android nécessitent des langages de programmation système tels que C et C++. Ces langages offrent aux développeurs contrôle et prévisibilité, ce qui est important lors de l'accès aux ressources système et au matériel de bas niveau.

Malheureusement, C et C++ ne parviennent pas à fournir des garanties de sécurité de la mémoire, ce qui les rend sujets aux bugs et aux failles de sécurité. Le développeur est responsable de la gestion de la durée de vie de la mémoire sur ces langages, mais dans les bases de code complexes et multithread, cela est plus facile à dire qu'à faire.

C et C++ constituent ensemble des dizaines de millions de lignes de code sur la plateforme Android. Ces bogues de sécurité de la mémoire deviennent la source d'inexactitude de code la plus difficile à résoudre, représentant environ 70 % des vulnérabilités de sécurité de haute gravité d'Android. La simple correction de ces bugs ne suffit plus pour résoudre le problème, et une meilleure approche serait de les éviter en premier lieu.

Le manque de garanties de sécurité de la mémoire oblige les développeurs à exécuter les processus Android dans des bacs à sable étroitement contraints et sans privilèges. Mais les sandbox sont coûteux en ressources, consommant des frais supplémentaires et introduisant de la latence. Le sandboxing n'élimine pas non plus entièrement les vulnérabilités du code et son efficacité est réduite en raison de la forte densité de bogues, permettant ainsi aux attaquants d'enchaîner plusieurs vulnérabilités.

Une autre limitation, bien qu'elle ne soit pas propre au C et au C++ mais s'applique à tous les problèmes de sécurité de la mémoire, est que l'état erroné doit en réalité être déclenché dans le code instrumenté pour être détecté. Ainsi, même si votre code est soumis à d’excellents tests, le bug réel peut rester indétectable. Et lorsque des bogues sont détectés, les corriger est une autre tâche, impliquant un processus long et coûteux qui ne conduit pas toujours à une solution correcte. Ainsi, la détection des bogues devient peu fiable et la prévention des bogues est la meilleure approche à la lumière de ces limitations.

C’est là qu’intervient le passage à un langage sécurisé en mémoire comme Rust.

La rouille et ses bienfaits

Rust fournit des garanties de sécurité de la mémoire en utilisant une combinaison de contrôles au moment de la compilation pour garantir la durée de vie/propriété des objets, et des contrôles à l'exécution pour garantir que les accès à la mémoire sont valides. Cette sécurité est obtenue tout en offrant des performances équivalentes au C et au C++. Rust réduit également le besoin de sandboxing, permettant aux développeurs de disposer de plus de marge de manœuvre pour introduire de nouvelles fonctionnalités plus sûres et plus légères en ressources.

Bien que Rust présente effectivement ses avantages, il n'est pas possible de basculer l'intégralité du système d'exploitation Android vers Rust du jour au lendemain. Et cela n'est peut-être même pas nécessaire, car la plupart des bogues de mémoire d'Android se produisent dans du code nouveau ou récemment modifié, environ 50 % datant de moins d'un an. Google estime que ses efforts en matière de langage sécurisé en mémoire sont mieux concentrés sur les nouveaux développements plutôt que sur la réécriture de code C et C++ mature.

Rust se concentre également sur la prévention des bogues plutôt que de s'appuyer fortement sur la détection des bogues, ce qui améliore l'exactitude du code. Il possède plusieurs fonctionnalités clés, telles que la sécurité de la mémoire, la concurrence des données, des systèmes de type plus expressifs, l'immuabilité. références et variables par défaut, une gestion des entiers plus sûre, une meilleure gestion des erreurs dans les bibliothèques standard, et bien plus encore. plus.

Que signifie le passage à Rust pour Android?

Google affirme avoir ajouté la prise en charge de Rust au projet Android Open Source au cours des 18 derniers mois. Mais ajouter une nouvelle langue à la plateforme Android est une entreprise énorme. Certaines chaînes d'outils et dépendances doivent être maintenues, l'infrastructure et les outils de test doivent être mis à jour et les développeurs doivent être formés.

Google a quelques projets d'adoption précoce qu'ils partageront dans les mois à venir. Mais même ainsi, il est clair que l’extension de la prise en charge de Rust à un plus grand nombre de systèmes d’exploitation est un projet pluriannuel.

D'après ce que nous pouvons voir, Google utilise déjà Rust à plusieurs endroits. La nouvelle pile Bluetooth d'Android réécrit le nom de code "Gabeldorsche" est écrit en Rust. Les travaux ont commencé sur Gabeldorsche à l’époque d’Android 11 mais ne sont toujours pas utilisés. Android Magasin de clés 2.0 Le module est écrit en Rust, tout comme la partie espace utilisateur de binder, le pilote IPC d'Android. Bien que cela ne soit pas lié à Android, Fuchsiac'est nouveau pile nette est également écrit en Rust.

Pour les développeurs d’applications, le changement ne change rien à la façon dont vous, en tant que développeur d’applications, écrivez des applications ou au fonctionnement des API du framework. Ce commutateur affecte uniquement la façon dont le système d’exploitation est écrit. Selon un membre de l'équipe Android Developer Relations, Google ne prévoit pas non plus de publier un Rust NDK pour le moment. Les langages pris en charge pour le développement d'applications continueront d'être Kotlin, Java, C et C++.