L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Le pilote d’affichage Linux 615.78.08 de Nvidia, publié le 7 octobre, stocke désormais le contenu de la mémoire du GPU dans un fichier privé du noyau que SELinux n’inspecte jamais, en utilisant shmem_kernel_file_setup(), l’appel du noyau qu’un ingénieur de Nvidia a déclaré aux responsables de Fedora en août et auquel les réviseurs s’étaient opposés. Le commutateur est visible dans l’arborescence des sources publiques de Nvidia, qui appelle shmem_file_setup à la balise 615.71.09 et la nouvelle fonction à 615.78.08, toutes deux lues à 21h08 UTC le 8 octobre.
Le fichier existe pour conserver la mémoire vidéo pendant qu’une machine est en veille, lorsque la préservation de la mémoire vidéo est activée. Les pilotes plus anciens ouvraient un vrai fichier sous /tmp, déplaçable avec le paramètre NVreg_TemporaryFilePath, et 615.71.09 avait déjà déplacé la valeur par défaut vers un fichier shmem anonyme. La différence réside désormais dans l’inode : le nouvel appel le marque S_PRIVATE, donc les modules de sécurité l’ignorent entièrement plutôt que de l’étiqueter comme n’importe quel autre fichier tmpfs.
Pour un propriétaire, la conséquence est de se suspendre. Le dossier de Nvidia décrit une machine qui ne parvient pas à se mettre en veille une fois que le pilote exécute ce code dans le contexte de veille très restrictif de systemd, où l’accès à l’ancien système de fichiers est bloqué.
Le responsable de Fedora a proposé l’appel que Nvidia avait réservé
Nvidia a ouvert le rapport sous-jacent sur le paquet selinux-policy de Fedora le 6 août, avertissant qu’un prochain pilote déplacerait ce travail dans la réponse du noyau à une écriture dans /sys/power/state. Le 15 août, un responsable de Fedora SELinux a répondu dans Red Hat Bugzilla 2512142 que si le fichier ne quittait jamais l’espace du noyau, « le pilote devrait plutôt l’ouvrir via shmem_kernel_file_setup(), qui marquera l’inode avec S_PRIVATE, ce qui lui permettra de contourner les vérifications du module de sécurité (comme c’est la norme pour les fichiers purement privés du noyau) ».
Deux jours plus tard, un ingénieur de Nvidia a confirmé que le fichier concernait uniquement le noyau, puis a exclu cette suggestion. « J’ai examiné shmem_kernel_file_setup() lorsque je travaillais sur la version initiale du changement, mais les réviseurs se sont opposés à son utilisation pour contourner les vérifications LSM car la documentation mentionne spécifiquement que le contournement de LSM n’est pas son utilisation prévue », lit-on dans la réponse, citant le propre avertissement du noyau selon lequel il n’y a pas de vérification des autorisations LSM par rapport à l’inode sous-jacent.
Le 3 septembre, le même compte a écrit « J’ai réussi à contourner ce problème dans le pilote, donc je pense que cela peut être fermé », et le rapport a été clôturé avec une résolution UPSTREAM. La demande d’extraction de Nvidia contre la politique selinux, « Autoriser fs_write_tmpfs_files pour systemd_sleep_t », ouverte depuis le 3 mars, a été fermée sans être fusionnée à 23h38 UTC ce soir-là, moins de deux minutes avant l’arrivée de ce commentaire. Les deux ont été lus à 21h08 UTC le 8 octobre.
Le code du conducteur précise le métier
615.78.08 ajoute un commentaire à cette fonction que 615.71.09 ne comporte pas. Le fichier, indique-t-il, « peut contourner les contrôles LSM tels que SELinux, il est donc important que ce fichier ne soit jamais mappé, lié au système de fichiers ou assigné à un descripteur de fichier à moins que le contrôle d’accès ne soit vérifié par l’appelant ».
Toutes les machines n’empruntent pas la nouvelle voie. Le fichier de build nvidia.Kbuild obtient une sonde à la compilation pour le symbole en 615.78.08 et n’en porte aucune en 615.71.09, donc le pilote revient à l’ancien appel shmem_file_setup sur les noyaux qui n’exportent pas shmem_kernel_file_setup. Le chemin utilisé par un système donné dépend donc de son noyau et non de la version de son pilote.
La version active également NVreg_UseKernelSuspendNotifiers par défaut, qui est le commutateur qui envoie la suspension via ce code, de sorte que les machines sur lesquelles l’option de déclenchement n’a jamais été activée l’ont désormais activée. Le reste de ce que 615.78.08 modifie s’étend sur six éléments. L’appel réservé par Nvidia en août est celui que son pilote expédie depuis le 7 octobre.