Dans Android 13, Google étend la couleur dynamique Material You au-delà des applications Google à toutes les icônes d'application, permettant aux utilisateurs d'opter pour des icônes qui héritent de la teinte de leur fond d'écran et d'autres préférences de thème. Android 13 apporte également de nouvelles fonctionnalités et de nouveaux outils pour la productivité des développeurs.
Il existe également un joyau caché avec une virtualisation complète possible sur du matériel tel que le smartphone Google Pixel 6. Cela signifie qu'il est désormais possible d'exécuter pratiquement n'importe quel système d'exploitation, y compris Windows 11, les distributions Linux telles qu'Ubuntu ou Arch Linux Arm sur le téléphone alimenté par Google Tensor, et ce, à une vitesse quasi native.
Le développeur Android et Web répondant au pseudonyme "kdrag0n" sur Twitter a testé plusieurs distributions Linux compilées pour Aarch64 sur Pixel 6 avec Ubuntu 21.10, Arch Linux Arm, Void Linux et Alpine Linux en utilisant "l'hyperviseur KVM sur Pixel 6 + Android 13 DP1". Il/elle explique en outre :
« Autant que je sache, nous pouvons à peu près obtenir EL2 complet sur les appareils de production maintenant. Le KVM protégé est facultatif et peut être activé sur une base par VM, mais pour les VM non protégées, il semble que la fonctionnalité KVM complète soit disponible ».
EL2 fait référence aux niveaux d'exception Arm, comme expliqué sur le site Web du développeur Arm. kdrag0n ne s'est pas arrêté là et a réussi à faire fonctionner Windows 11 sur le Pixel 6 également via la même virtualisation Android 13.
Super, le Windows Phone est de retour ! Plus sérieusement, nous devrons voir si tout fonctionne comme prévu, mais cela semble prometteur.
La virtualisation sur Android aujourd'hui est « le Far West de la fragmentation », selon Will Deacon de l'équipe Android Systems. Mais pourquoi Google a-t-il activé la virtualisation dans Android ? Il est peu probable qu'ils veuillent simplement laisser les utilisateurs installer Linux ou Windows sur le téléphone. Mishaal Rahman, Senior Technical Editor chez Esper a abordé ce problème il y a environ deux mois.
Il a noté que les hyperviseurs peuvent être présents ou non sur un appareil, et lorsqu'ils le sont, ils ne sont souvent même pas utilisés aux fins prévues, à savoir exécuter un système d'exploitation dans une machine virtuelle ! Au lieu de cela, ils sont utilisés pour des choses comme améliorer la sécurité du noyau (ou au moins, essayer de le faire) et exécuter divers codes (tels que du code tiers pour DRM, la cryptographie et d'autres binaires à source fermée) en dehors du système d'exploitation Android.
Pour comprendre pourquoi ce dernier est particulièrement problématique, considérons que dans le modèle d'exception Armv8/v9, l'hyperviseur s'exécute au niveau d'exception 2 (EL2). Dans la nomenclature Arm, plus le nombre est élevé, plus le niveau de privilège est élevé, ce qui signifie que le code exécuté à EL0 (par exemple, les applications de l'espace utilisateur) est le moins privilégié, le code exécuté à EL1 (par exemple, le système d'exploitation Android et le noyau Linux) est plus privilégié, etc. Ainsi, de nombreux blobs binaires tiers opaques s'exécutent avec des privilèges plus élevés même que le système d'exploitation et le noyau ! Ceci est préjudiciable à la sécurité, car cela augmente la surface d'attaque du code privilégié pouvant être exploité, car le code s'exécutant à un EL supérieur peut accéder à tous les registres des niveaux inférieurs.
Afin à la fois de priver ce code tiers et d'isoler ce code d'Android et d'autres programmes tiers, Google s'efforce d'apporter une solution d'hyperviseur commune au-dessus de laquelle une machine virtuelle s'exécutant au même niveau de privilège que le système d'exploitation et le noyau exécutera ce code. Il existe un mécanisme de virtualisation du noyau mature appelé KVM qui est déjà pris en charge par Linux, donc naturellement Google a choisi de le déployer en tant qu'hyperviseur commun. Et grâce aux efforts continus de Google pour réduire la fragmentation du noyau, KVM peut être activé sur un large éventail d'appareils Android équipés d'une version récente de la GKI.
Mishaal Rahman a souligné que Google étend en fait KVM avec des fonctionnalités de sécurité supplémentaires et l'appelle pKVM, ou "KVM protégé". pKVM est conçu pour permettre la confidentialité des données dans une machine virtuelle, même si le système d'exploitation est compromis. L'implémentation était alors disponible dans la ligne principale, branches android13-5.10 et android13-5.15 Android Common Kernel.
Pour gérer ces machines virtuelles, Google porte sur Android crosvm, le gestionnaire de machines virtuelles basé sur Rust (VMM) utilisé pour exécuter des applications Linux sur Chrome OS, et Mishaal Rahman notait qu'il serait livré aux appareils via un nouveau module Mainline appelé "Virtualisation" ( com.android.virt) : « Actuellement, aucun appareil Android sur le marché n'est livré avec le module de virtualisation - pas même le propre Pixel 6 de Google - mais cela devrait changer avec la prochaine version d'Android 13. En effet, Google teste actuellement ses nouveaux outils de virtualisation sur le Pixel 6 ; si vous construisez AOSP avec la cible aosp_oriole_pkvm, vous constaterez que com.android.virt sera automatiquement hérité. Je ne sais pas si Google activera pKVM sur la série Pixel 6 avec la mise à jour Android 13, mais il est prouvé que Google prévoit qu'Android 13 inclura la première version de l'hyperviseur pKVM et du framework de machine virtuelle ».
Si vous êtes intéressé par l'historique complet des efforts de Google pour apporter KVM aux appareils Android, regardez le discours de Will Deacon lors du forum KVM de l'année dernière :
La virtualisation est donc principalement apportée pour des besoins de sécurité et les binaires comme DRM.
Code source du module de virtualisation
guide expliquant comment démarrer avec les machines virtuelles protégées
Source : kdrag0n