io_uring est une interface d’appel système du noyau Linux pour les opérations d’E/S asynchrones des périphériques de stockage
Google a récemment dévoilé à travers un article de blog qu’il a pris la décision de désactiver par défaut sur ChromeOS, Android et les serveurs de fabrication, l’interface asynchrone io_uringceci en raison de la situation de sécurité déplorable dans io_uring.
Et c’est que lors de l’analyse des résultats du « Vulnerability Bounty Program » du kCTF, qui est en place depuis 2020, il a été démontré que 60% des candidatures reçues dans le cadre du programme exploitent des vulnérabilités émergentes et la situation n’évolue pas dans le temps, ce qui est assez inquiétant car il est devenu un point vulnérable.
Au total, environ 1 million de dollars de primes ont été versés. par des exploits lié à io_uringtandis que le montant total des primes payées pour les vulnérabilités du noyau Linux pendant l’existence de l’initiative était de 1,8 million de dollars pour 42 exploits fournis pour des vulnérabilités non encore corrigées (rémunération maximale – 133 000 dollars).
Étant donné que le noyau Linux est un composant clé non seulement pour Google, mais aussi pour Internet, nous avons commencé à investir massivement dans ce domaine. Nous avons étendu la portée VRP et la récompense maximale en 2021 (à 50 000 $), puis à nouveau en février 2022 (à 91 000 $) et enfin en août 2022 (à 133 000 $). En 2022, nous avons également résumé nos apprentissages à ce jour dans notre livre de recettes et présenté nos atténuations expérimentales pour les techniques d’exploitation minière les plus courantes.
L’année dernièrepour améliorer la sécurité du noyau de Linux utilisé dans l’environnement de référence dans lequel l’exploit réclamant le prix a été produit, Google a appliqué des ajustements et des correctifs supplémentaires pour bloquer les méthodes d’exploitation typiques. Par exemple, une protection contre la corruption a été ajoutée à la structure Freelist, l’écriture hors limites sur slab a été interdite et le blocage des attaques liées au partage de cache a été implémenté. Mais ces changements n’ont pas affecté la capacité à exploiter les vulnérabilités de io_uring, ce qui a conduit Google à cesser de prendre en charge io_uring dans ses produits.
Bien que io_uring offre des avantages en termes de performances et réagisse rapidement aux problèmes de sécurité avec des correctifs de sécurité complets (comme le rétroportage de 5.15 vers l’arborescence stable 5.10), il s’agit d’une partie relativement nouvelle du noyau. En tant que tel, io_uring continue d’être activement développé, mais est toujours affecté par de graves vulnérabilités et fournit également de puissantes primitives d’exploitation. Pour ces raisons, nous le considérons actuellement comme sûr pour les composants de confiance uniquement.
Sur ChromeOS, la prise en charge de io_uring est désactivée lors de la compilation du noyau (CONIFG_IO_URING dans la configuration du noyau). Android utilise temporairement un filtre basé sur seccomp-bpf pour bloquer l’accès à io_uring et prévoit d’utiliser SELinux pour restreindre sélectivement l’accès à io_uring aux composants système de confiance dans une future version.
Ainsi, Google ne voit pas d’un mauvais œil la Interface io_uring, fourni par le noyau Linux depuis la version 5.1, puisqu’il mentionne que parmi ses points positifs, se distingue par sa prise en charge de l’interrogation des E/S et la possibilité de travailler avec ou sans mise en mémoire tampon, mais en tant que tel, il reste suffisamment robuste pour continuer à prendre des risques et, surtout, continuer à investir dans la correction des bugs et des vulnérabilités qui surgissent constamment.
Avec l’API io_uring, les développeurs du noyau ont tenté de combler les lacunes de l’ancienne interface aio.
En termes de performances, io_uring est très proche de SPDK et surpasse significativement libaio lorsque l’interrogation est activée. Par exemple, l’utilisation de io_uring dans la bibliothèque libuv a entraîné une augmentation des performances par 8, et l’inclusion d’une mise en mémoire tampon d’écriture asynchrone basée sur io_uring dans le système de fichiers XFS a entraîné une baisse de 80 fois la latence et une augmentation de 2,7 fois du taux de transfert de données.
Il convient de mentionner qu’en outre, Google envisage la possibilité de désactiver io_uring par défaut dans GKE AutoPilot (Google Kubernetes Engine).
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.
