Libseccomp: BOGUE : impossible d'appeler seccomp_load() plus d'une fois avec la v2.5.0

Le code seccomp en question est plutôt séparé des autres parties du code xwallpaper, vous pouvez donc voir l'utilisation de libseccomp de xwallpaper ici : https://github.com/stoeckmann/xwallpaper/blob/master/seccomp.c

Salut @stoeckmann , merci pour le rapport de bug ! Oui, vous avez raison, nous permettons à seccomp_load() d'être appelé plusieurs fois.

Nous devrons réfléchir à la manière dont nous voulons résoudre ce problème.

@stoeckmann @drakenclimber , nous devons encore examiner comment le noyau gère plusieurs demandes de notification fd pour nous assurer que cela est correct, mais ma pensée initiale est que nous devrons peut-être conserver un indicateur global (beurk), qui suit si nous avons déjà demandé une notification fd et si nous en avons une, nous n'en demandons pas une autre.

Essentiellement, nous déplacerions notify_fd du contexte de filtre vers une valeur globale dans "src/system.c".

Sur la base de mon commentaire précédent, nous pourrions vouloir autoriser un appelant à demander une autre notification fd sur la chance étrange qu'il ait fait un fork() ou un clone() après avoir demandé une notification fd. Nous devons vraiment comprendre ce que fait le noyau dans ces cas en ce qui concerne la notification fd.

Si nous devons gérer cela, nous pouvons toujours conserver le notify_fd dans le contexte du filtre tout en conservant une valeur globale. Sur seccomp_init() le contexte hériterait du fd de la valeur globale, mais un seccomp_reset() le réinitialiserait toujours à -1 tout en laissant la valeur globale intacte. Cela nécessiterait qu'un appelant effectue une initialisation/réinitialisation pour chaque filtre après un fork où il souhaite demander une nouvelle notification fd, mais cela semble être un compromis raisonnable pour un tel cas d'utilisation de niche.

... ou peut-être permettons-nous à un appelant d'appeler seccomp_reset(NULL, ...) au lieu de renvoyer -EINVAL ? Dans ce cas particulier, le contexte NULL, nous réinitialiserions tout état global, par exemple la notification enregistrée fd.

Pour fermer la boucle sur la partie noyau de ceci, oui, il semble que si l'un des filtres chargés dans la tâche en cours a demandé un notificateur fd alors l'opération de chargement échoue avec -EBUSY , voir kernel/seccomp.c :init_listener() .

Pour fermer la boucle sur la partie noyau de ceci, oui, il semble que si l'un des filtres chargés dans la tâche en cours a demandé un notificateur fd alors l'opération de chargement échoue avec -EBUSY , voir kernel/seccomp.c :init_listener() .

Le notificateur seccomp a actuellement la restriction qu'un seul fd peut être demandé. Cela empêche les filtres fd de notifier seccomp de se substituer les uns aux autres.

@brauner ouais.

Prévoyez-vous que le comportement du noyau changera bientôt à cet égard ? Nous devons trouver un moyen de prendre en charge cela dans libseccomp et il serait utile de connaître tout travail futur ou en file d'attente afin de ne pas nous retrouver dans un coin en ce qui concerne l'API.

@brauner ouais.

Prévoyez-vous que le comportement du noyau changera bientôt à cet égard ? Nous devons trouver un moyen de prendre en charge cela dans libseccomp et il serait utile de connaître tout travail futur ou en file d'attente afin de ne pas nous retrouver dans un coin en ce qui concerne l'API.

Il a été soulevé récemment, mais personne n'a réellement expliqué pourquoi il était nécessaire. Alors non, je ne pense pas. Je pense qu'une fois que nous aurons activé cela, nous devrons peut-être revoir le comportement de "remplacement".

D'accord, laissez-moi y réfléchir un peu, ainsi que les réflexions de seccomp_reset(NULL, ...) .

@drakenclimber que pensez-vous de l'approche dans le commit ci-dessous ?

• https://github.com/pcmoore/misc-libseccomp/commit/0811440220aad949feb38428290f91f525742b1d

@stoeckmann, le commit ci-dessus devrait résoudre le problème que vous rencontrez, si vous pouviez lui faire un test et faire un rapport, ce serait apprécié.

Salut @pcmoore ,

vient de tester le commit. xwallpaper fonctionne à nouveau avec.

Merci d'avoir vérifié ce @stoeckmann ; si l'approche semble correcte pour @drakenclimber, je soumettrai un PR approprié.

Je viens de faire une poussée forcée pour résoudre un problème avec l'un des tests de régression (le test 11 s'attendait toujours à ce que seccomp_reset(NULL, ...) renvoie une erreur).

Merci d'avoir vérifié ce @stoeckmann ; si l'approche semble correcte pour @drakenclimber, je soumettrai un PR approprié.

J'ai brièvement parcouru le correctif proposé et cela semble être une solution raisonnable au problème. Merci pour la correction. Je vais y regarder de plus près une fois que vous aurez publié le PR.

Temps PR approprié, voir PR #280.

(Pour le contexte : systemd utilise fortement libseccomp, la plupart de ses démons sont livrés avec un filtre syscall appliqué à l'aide de libseccomp. Tous les filtres pertinents ont fini par être désactivés dans stable f32 en raison de ce bogue, car nous installons les filtres pour chaque arch séparément, ainsi que pour chacune de nos options de configuration sélectionnables par l'utilisateur séparément, ce qui signifie en effet sur x86-64, seul un petit sous-ensemble des filtres et uniquement pour l'arch syscall i386 a été installé, de sorte que tout est effectivement grand ouvert. à nous.)

@poettering si ce bogue est un "gros" pour vous sur F32 stable, vous pouvez envisager de vous en tenir au flux de publication v2.4.x jusqu'à la prochaine version v2.5.x. La version libseccomp v2.4.x est toujours prise en charge et je pense que @drakenclimber prévoit bientôt une nouvelle version v2.4.x.

@pcmoore Je n'ai pas l'intention d'annuler la mise à jour de libseccomp. Veuillez faire ce qu'il faut et corriger cela dans 2.5.x.

@Conan-Kudo s'il vous plaît lisez le PR et voyez que nous le sommes.

@pcmoore Oui , désolé, j'ai vu ça plus tard. Malheureusement, cette nouvelle interface utilisateur GitHub rend moins évident qu'il y a maintenant un PR lié à un problème...

@Conan-Kudo, pour être franc, j'étais plus préoccupé par l'attitude suscitée par ces commentaires que par le fait que vous aviez manqué le PR en cours. Il s'agissait d'une version importante de libseccomp (v2.4.x -> v2.5.0) et il y aura forcément des bogues qui ne seront pas trouvés avant que la version n'atteigne les principales distributions, si vous l'avez précipité de Rawhide dans une version stable de Fedora sans tests suffisants avec systemd, ne blâmez pas le projet en amont.

J'ai eu une assez mauvaise journée de harcèlement de la part de diverses personnes toute la journée à propos de cela et d'autres choses.

Quant à la "précipitation", je ne l'ai pas fait. Comme il était compatible ABI, j'ai considéré qu'il était sûr de le soumettre et je n'ai rien vu d'anormal lorsque je l'ai essayé localement. Je l'ai poussé dans Bodhi et l'ai laissé reposer pour le tester comme tout le reste. Il a reçu du karma par d'autres personnes et s'est stabilisé en conséquence la semaine dernière. Ce bug n'est apparu que le dernier jour environ.

J'ai eu une assez mauvaise journée de harcèlement de la part de diverses personnes toute la journée à propos de cela et d'autres choses.

Ensuite, vous devriez comprendre comment votre "Je n'ai pas l'intention d'annuler la mise à jour de libseccomp. Veuillez faire ce qu'il faut et corriger cela dans 2.5.x." commentaire sonne.

Ouais, ouais, je sais. 😩

Quoi qu'il en soit, j'ai sélectionné le PR dans Fedora : https://src.fedoraproject.org/rpms/libseccomp/c/b7df1ffe6c217ba2fb9251b5b9c67f12040a68b5

Pour élaborer un peu plus, c'est le « veuillez faire la bonne chose » qui est particulièrement grinçant. Cela implique que nous essayons intentionnellement de faire la mauvaise chose, ce qui est exaspérant quand on considère le temps et l'énergie nécessaires à une sortie.

Écoutez, tout le monde déteste quand ça casse, ça craint ; ça craint doublement quand vous êtes surmené, épuisé et que vous traversez probablement d'autres choses avec cette pandémie mondiale. Supposons simplement que nous sommes contrariés qu'il soit cassé aussi et que nous essayons de trouver une solution qui ne gâche pas les choses - d'accord ?

Ouais, ça me va. J'essaierai de m'en souvenir pour la prochaine fois...

Quoi qu'il en soit, j'ai sélectionné le PR dans Fedora : https://src.fedoraproject.org/rpms/libseccomp/c/b7df1ffe6c217ba2fb9251b5b9c67f12040a68b5

D'accord, juste acheteur-attention qui n'a pas encore été fusionné, bien qu'il n'y ait pas de changements d'ABI donc ça devrait être sûr... ? Quoi qu'il en soit, laissez-nous savoir comment cela se passe; des commentaires sur si cela résout le problème pour la foule de Fedora serait bien.

Oui, j'ai pensé que la gravité de la casse involontaire justifierait de la retirer tôt et de la faire évaluer pour résoudre le problème que nous avons rencontré.