introduction

Un extrait de l'article de LWN.net Dedfending aginst page-cache attack de Jonathan Corbet et un résumé des informations connexes. Ajout de notes et d'informations connexes. L'article original porte principalement sur les discussions tenues dans Linux Kernel Mailing List, et le comportement des appels système effectués sous Linux 5.0 ou version ultérieure. C'est un commentaire sur les changements.

Les vulnérabilités sont désormais signalées dans le cache de pages du stockage virtuel, qui est à la base du mécanisme de gestion de la mémoire du système d'exploitation. Des vulnérabilités dues au timing du cache de page ont été signalées depuis un certain temps, mais des astuces intelligentes sont trouvées les unes après les autres. Le document qui a soulevé le problème exploite des vulnérabilités sous Linux et Windows, mais d'autres systèmes d'exploitation sont également vulnérables. En outre, le comportement des appels système a changé, ce qui est censé affecter les applications qui les utilisent. Il s'agit toujours d'un changement dans la version rc (version release candidate), donc cela n'affectera pas les utilisateurs utilisant des noyaux normaux, mais cela l'affectera à l'avenir. Voir Ressources pour les appels système et autres fonctionnalités / conditions.

Licence

D'après l'article original, il s'agit de by-sa-4.0.

Aperçu

Le comportement de l'appel système mincore () a changé en raison d'une vulnérabilité de cache de page. --mincore est une fonction permettant de connaître l'état du cache de page.
Les processus tiers non liés peuvent également connaître l'état du cache utilisé par d'autres processus --Changé pour ne renvoyer que la page qui a échoué en premier, mais relâché pour renvoyer l'état du cache de manière conditionnelle en tenant compte de l'impact sur les performances des autres programmes.
Soucieux de l'impact de l'espace utilisateur sur les programmes
On pense que d'autres appels système, certains systèmes de fichiers et pilotes d'E / S contiennent également des vulnérabilités de cache de page.

Defending against page-cache attacks La fonction de cache de page du noyau a contribué à améliorer les performances en réduisant les E / S disque (lors de l'accès aux fichiers) et en augmentant le partage de la mémoire physique.

Cependant, comme d'autres techniques d'amélioration des performances qui partagent des ressources au-delà des limites de sécurité, les caches de page peuvent être utilisés de manière abusive pour lire des informations confidentielles.

Les caches de pages peuvent être la cible de diverses attaques, comme le montre un récent [article] de Daniel Glass et de ses collègues (https://arxiv.org/pdf/1901.01161.pdf). Oui, 5.0 Merge Window indique que le comportement de l'appel système mincore () a soudainement changé. Mais des discussions ultérieures révèlent que mincore () n'est que la pointe de l'iceberg. On ne sait pas vraiment ce qu'il faut vraiment faire pour protéger le système contre les attaques de cache de page et combien de performances seront sacrifiées.

Le cache de page conserve une copie fragmentaire du fichier dans la mémoire principale. Lorsqu'un processus doit accéder aux données à partir d'un fichier, la présence des données dans le cache de page élimine le besoin de lire à partir du disque, ce qui accélère le traitement. Lorsque plusieurs processus accèdent au même fichier (par exemple la bibliothèque C), la même copie est partagée dans le cache de pages, ce qui réduit la quantité totale de mémoire requise par le traitement en cours. De nombreux systèmes d'exécution sont partagés de cette manière sur le système hébergeant le conteneur.

Bien que la mise en cache de page soit utile, il est connu que ce type de partage de cache peut parfois divulguer des informations entre les processus. Si un attaquant pouvait découvrir quels fichiers existent dans le cache de pages, il saurait ce que faisait le processus en cours d'exécution sur le système.

* arXiv: 1901.01161v1 [cs.CR] 4 Emprunté à janvier 2019 *

Si un attaquant peut observer qu'une page particulière est dans le cache, il ou elle peut déterminer quand un certain type d'accès a lieu. Par exemple, il est possible de déduire lorsqu'une fonction spécifique n'est pas appelée ou lorsqu'une page contenant une certaine fonction apparaît dans le cache. Glass et al. Ont pu exploiter de nombreuses vulnérabilités. Il comprenait des informations telles que les canaux secrets et la synchronisation des touches, et a été complété à l'aide d'informations mises en cache.

Le succès d'une attaque de cache de page comporte deux éléments. La première est qu'il est possible de savoir si une page se trouve dans le cache. Si possible, il est souhaitable de ne pas rayer l'état du cache de processus. L'autre est de pouvoir expulser certaines pages du cache, ce qui est essentiel pour voir quand la cible visite ces pages. Dans cet article, il était possible d'expulser facilement la page cible du cache avec une quantité suffisante d'autres pages. Cela a réussi, mais il existe peut-être un moyen plus simple.

correction de l'appel système mincore ()

La communauté des développeurs s'est concentrée sur la possibilité d'obtenir des informations sur l'emplacement du cache de page. Il est probablement impossible d'empêcher complètement un attaquant de modifier l'état du cache (bien que les groupes de contrôle de la mémoire puissent aider à cet égard). Mais si l'attaquant ne peut pas observer l'état du cache, la plupart des attaques seront assez difficiles. Certes, il sera difficile de savoir si la page cible a été expulsée avec succès. Malheureusement, il n'est pas facile de conserver ces informations en toute sécurité.

Dans l'article de Glass, mincore () était concerné par les appels système. Il est bien connu que l'appel système mincore () est destiné au traitement des rapports d'état du cache de page. À la suite de la fusion 5.0, mincore () a été changé pour signaler uniquement les pages qui ont mis en défaut [^ 1] à l'appel du processus [^ 7]. Les attaquants peuvent toujours utiliser mincore () pour savoir quand une page a été évacuée, mais ne peuvent plus être utilisés pour observer quand une page a été renvoyée par un autre processus. Pour ce faire, l'attaquant doit d'abord blâmer la page, détruisant les informations qu'il souhaite.

Changer le comportement de mincore () est un changement important. J'ai osé m'abstenir de le changer dans la mise à jour stable. En le considérant d'un point de vue réaliste, il pourrait détruire le comportement du programme d'espace utilisateur et conduire à un retour en arrière. Kevin Easton est un paquet Debian liste de ceux qui utilisent l'appel système mincore (), Mais on ne sait toujours pas combien de paquets seront corrompus. Le plus problématique de la liste est probablement vmtouch, mais un ensemble de travail connu [^ 2] pour accélérer le démarrage de la machine virtuelle. Il est utilisé dans certains paramètres par défaut.

Concernant cet effet fatal, Josh Snyder [^ 10] a déclaré: "Pour Netflix, il a fallu des jours pour maintenir le cluster de base de données [^ 9] en mois si l'appel système mincore perdait des informations précises. Il sera étiré "signalé. Le rapport a encouragé les principaux développeurs à repenser leurs options, notamment en ajoutant un mode système pour changer mincore () en exécution privilégiée [^ 8]. L'idée est probablement proche de proposée et adoptée par Dominique Martinet. Il a déclaré que les informations ne devraient être fournies que lorsque l'appelant (de mincore) est autorisé à écrire le fichier source de mappage. Cela résoudra le cas d'utilisation de Netflix tout en empêchant les pages d'exécutables système d'être surveillées. [Patch Implementation] par cette méthode (https://lwn.net/ml/linux-kernel/[email protected]/) a été publié par Jiri Kosina.

Problème encore plus grave

Si une solution viable est trouvée, certains essaieront de résoudre et de mettre fin au plus gros problème. Mais cette affaire n'est pas comme ça pour l'instant. David Chinner peut utiliser l'appel système preadv2 () avec l'indicateur RWF_NOWAIT pour des tests non destructifs du contenu du cache de page. Souligné [^ 15]. Une solution disponible consiste à initialiser la lecture anticipée lorsque la recherche de données dans le cache de page échoue lors de la lecture de RWF_NOWAIT pour modifier l'état du cache et en même temps améliorer les performances autant que possible pour les utilisateurs généraux. Le patch Kosina répertorié ci-dessus contient ces modifications.

Chinner voit ces patchs comme une gifle sur le mogura et toujours au milieu de beaucoup de mogura. «De nombreuses interfaces du noyau sont conçues pour demander la disponibilité immédiate des données», a-t-il dit (ce qui signifie généralement qu'elles se trouvent dans le cache de page). Ces informations sont utilisées dans de nombreuses applications car elles peuvent être obtenues de manière correcte et sont utiles. Un autre chemin vers les vulnérabilités est, dit-il, overlayfs, qui est utilisé comme moyen de mise en cache de page entre les conteneurs. Selon lui, changer mincore () n'est pas la bonne approche.

Ceci est juste un pansement adhésif rapide pour une méthode de lecture particulière et ne fait rien pour réduire l'étendue réelle des fuites d'informations. Lorsque nous ne regardons que les plâtres adhésifs, les autres canaux qui exposent également les informations et toute l'infrastructure que nous avons construite reposent sur le concept de base du «partage de pages côté noyau au-delà des limites de sécurité». Vous manquerez qu'il y en a.

Dans un débat ultérieur, il a dévoilé une autre voie de vulnérabilité. Sur au moins certains systèmes de fichiers, les lectures d'E / S directes sur une page expulseront la page du cache. Ainsi, la désactivation (page cache) est très simple pour un attaquant. Il y a eu des débats plus animés, mais il y avait aussi la question: "Est-il juste pour un système de fichiers comme XFS de faire cela?" (Linus Torvalds considère qu'il s'agit d'un bogue ). Cependant, un point clair de cette discussion est qu'il est peu probable que ce comportement change immédiatement.

Même si tous les trous sont fermés, des problèmes comme l'émoussement persistent. C'est un simple problème d'attaque de synchronisation. Si une page particulière se charge rapidement, cette page est presque certainement dans le cache. Si cela prend du temps, il s'agit probablement d'une lecture à partir d'un stockage persistant (tel qu'un disque dur, un SSD). Les attaques chronométrées sont généralement ennuyeuses et faciles à remarquer, mais elles sont toujours disponibles. Et il semble que de nouveaux trous apparaîtront à l'avenir. Dans une autre discussion, Chinner a présenté un [appareil virtio pmem] récemment publié (https://lwn.net/ml/linux-kernel/[email protected]/) [^ 5] [Commenté] sur ce qui pourrait être abusé de la même manière (https://lwn.net/ml/linux-kernel/20190110012617.GA4205@dastard/). Pour les fonctionnalités io_uring [^ 6], si elles étaient fusionnées dans leur forme actuelle, il serait plus facile pour les attaquants d'interroger le cache de page. ..

En d'autres termes, ce problème semble presque insoluble, du moins au sens absolu. La meilleure chose à faire est peut-être d'augmenter le seuil suffisamment haut pour empêcher la plupart des attaques. Il semble donc arrêter le mécanisme connu des requêtes non destructives à l'état du cache de page uniquement si le noyau est réglé en "mode sécurisé". Il est trop difficile (ou coûteux) de se défendre complètement contre les attaques chronométrées. Donc tel que publié par Linus, aspirant à une sécurité totale Ceux qui le seront seront déçus comme d'habitude.

Nous n'empêcherons jamais ** jamais ** toutes les attaques de canaux secondaires. Certaines parties de la mise en cache sont très fondamentales (en particulier en ce qui concerne les effets de synchronisation). Il est donc impossible de tracer une ligne absolue sur le terrain ** quoi qu'il arrive. Vous ne pouvez pas dire "vous êtes protégé" en noir et blanc. Il n'y a qu'une différence de commodité.

Le blocage de l'utilisation abusive des vecteurs connus pose toujours un problème dans la mesure où cela ne pose pas de problème pour les applications existantes de l'espace utilisateur. Comme Meltdown et Spectre, cela semble être un problème qui occupe les développeurs du noyau pour le moment.

Informations primaires et originales

Les références

Annonce d'une nouvelle attaque de canal latéral indépendante du matériel "Attaques de cache de page"
Le noyau Linux- 4. Gestion de la mémoire
Relation entre le cache de page du noyau Linux et buffer_head, address_space
J'ai vérifié et libéré le cache de page sous Linux
Les bases de Linux et de la mémoire qui ne peuvent plus être entendues et l'utilisation détaillée de vmstat
[Erreur de page --wikipedia](https://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%BC%E3%82%B8%E3%83%95%E3%82%A9 % E3% 83% BC% E3% 83% AB% E3% 83% 88)
[Working set-wikipedia](https://ja.wikipedia.org/wiki/%E3%83%AF%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%B0 % E3% 82% BB% E3% 83% 83% E3% 83% 88)
mincore - man
Vérifiez si le fichier est dans le cache de la page
happycache
Vérifiez si le fichier est dans le cache avec vmtouch
CAP_SYS_ADMIN
preadv2 - man
Évitez le cache de page par les E / S directes de XFS
Overlay Filesystem - Neil Brown
docker --Utilisation du stockage OverlayFS

En attendant, à ce moment-là OpenBSD ...

J'ai essayé de faire mentir mincore. La nature du partage de mémoire est que vous pouvez espionner ce que font les autres processus. Nous ne voulons pas de cela, donc nous retournons toujours "la mémoire est sur le noyau (cache)". https://twitter.com/OpenBSD_src/status/1089658147294273536

La fonctionnalité HyperThreading d'Intel est un nid vulnérable, OpenBSD avec fonctionnalité HyperThreading ** désactivé ** Cependant, je dois dire que c'est à un jet de pierre. J'aspire à cela.

[^ 1]: interruption matérielle (ou exception) qui se produit lorsqu'un programme accède à une page sur un espace d'adressage virtuel où la mémoire physique n'est pas mappée.

[^ 2]: une collection de pages de mémoire virtuelle en cours d'utilisation à un moment donné du processus.

[^ 7]: Ce patch a été écrit par Linus lui-même.

[^ 8]: Plus précisément, lorsque sysctl_mincore_privileged est activé, EPERM est renvoyé sans CAP_SYS_ADMIN.

[^ 9]: En utilisant mon propre outil appelé happycache, je vide / restaure le cache avant de redémarrer pendant la maintenance de la base de données.

[^ 5]: Pseudo-mémoire de persistance utilisée par kvm pour éviter le cache de la page invité

[^ 6]: Interface introduite dans le but de renouveler l'ancienne E / S asynchrone

[^ 10]: ingénieur cloud NetFlix

[^ 15]: Lorsque preadv2 est utilisé en même temps que le flag RWF_NOWAIT, si les données ne peuvent pas être lues immédiatement (c'est-à-dire qu'elles ne sont pas dans le cache), il ne retourne rien et peut être utilisé au lieu de vérifier par mincore. Disponible à partir de 4.14.

L'impact des contre-mesures d'attaque de cache de page Linux est important et devrait se prolonger [Français]