Libseccomp: BUG : test 53/55 échecs/erreurs sur aarch64

@drakenclimber Je ne sais pas si vous avez accès à un système aarch64 (peut-être un Raspberry Pi exécutant une version 64 bits ?), mais je vais vous attribuer celui-ci pour des raisons évidentes. Si vous n'avez pas accès à un système aarch64, faites-le moi savoir et j'examinerai cela.

EDIT : désolé, c'est le code d'erreur 14 PAS l'erreur 16 (corrigé ci-dessous)

J'ai creusé un peu tout à l'heure et il semble que le test 53-sim-binary_tree ne génère aucune entrée et renvoie le code d'erreur 14/EFAULT lorsqu'il est exécuté de manière autonome.

J'ai ajouté une instrumentation rapide (ci-dessous):

diff --git a/tests/53-sim-binary_tree.c b/tests/53-sim-binary_tree.c
index 2c7890e..c154f67 100644
--- a/tests/53-sim-binary_tree.c
+++ b/tests/53-sim-binary_tree.c
@@ -81,6 +81,7 @@ int main(int argc, char *argv[])
                                              SCMP_A0(SCMP_CMP_EQ, i));
                else
                        rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(i), i, 0);
+               printf("PMD: i=%d, rc=%d\n", i, rc);
                if (rc < 0)
                        goto out;
        }

... ce qui a donné le résultat suivant :

# ./53-sim-binary_tree -p
PMD: i=0, rc=0
PMD: i=1, rc=0
PMD: i=2, rc=0
PMD: i=3, rc=0
...
PMD: i=161, rc=0
PMD: i=162, rc=0
PMD: i=163, rc=-14

Intéressant. Mon Raspberry Pi est mort il y a quelques mois, mais cela semble être une bonne excuse pour en commander un nouveau. La nouvelle version 2 Go a l'air vraiment tentante.

Jusqu'à ce qu'il arrive, je devrais pouvoir trouver une machine ARM dans Oracle. Je vais commencer à chercher...

Ça a l'air bien. Je serai curieux de savoir comment fonctionne le nouveau RPi 4, je n'ai qu'un 3B.

Quoi qu'il en soit, si vous ne trouvez pas de système, faites-le moi savoir.

La table d'appels système d'aarch64 est clairsemée à plusieurs endroits, et donc aarch64_syscall_resolve_num() renvoie NULL si le numéro d'appel système ne peut pas être trouvé dans le aarch64_syscall_table .

Voici la liste exacte des numéros d'appel système qui n'existent actuellement pas dans aarch64 :

                if (i == 163 || i == 164 || i == 244 || i == 245 ||
                    i == 246 || i == 247 || i == 248 || i == 249 ||
                    i == 250 || i == 251 || i == 252 || i == 253 ||
                    i == 254 || i == 255 || i == 256 || i == 257 ||
                    i == 258 || i == 259 || i >= 295)
                        /* aarch64 doesn't support these syscall numbers.
                         * remove them
                         */
                        continue;

Je ne suis pas vraiment sûr de la meilleure façon de procéder. Doit-on limiter les tests 53 et 55 uniquement à x86_64 ? Je veux vraiment m'assurer que nous testons de grands arbres binaires déséquilibrés. Il semble que dans un cas comme celui-ci, nous pouvons sauter ces tests. Ou peut-être devrions-nous faire un test plus petit et plus simple pour ces architectures.

Les pensées?

Dommage. Bien que fournir un faux numéro d'appel système et s'attendre à un résultat valide ne soit pas tout à fait juste ;)

Une possibilité serait de faire d'abord un appel à seccomp_syscall_resolve_num_arch(SCMP_ARCH_NATIVE, i) pour voir si ce numéro d'appel système existe ; si ce n'est pas le cas, vous ignorez simplement cet appel système inexistant.

Je pense qu'il convient également de noter qu'il s'agit purement d'un problème de test et non d'un problème général aarch64. Dans le monde réel, seuls les numéros d'appel système valides seraient introduits dans l'API dans l'attente de résultats appropriés.

Dommage. Bien que fournir un faux numéro d'appel système et s'attendre à un résultat valide ne soit pas tout à fait juste ;)

Je savais que je jouais avec le feu quand je l'ai fait :). Il s'agit d'une fonctionnalité délicate à tester car le comportement de fin de seccomp ne devrait pas changer lors de l'utilisation d'un arbre binaire. Seule la façon dont nous traversons le bpf (ou pfc) devrait changer.

Une possibilité serait de faire d'abord un appel à seccomp_syscall_resolve_num_arch(SCMP_ARCH_NATIVE, i) pour voir si ce numéro d'appel système existe ; si ce n'est pas le cas, vous ignorez simplement cet appel système inexistant.

J'y ai pensé, mais cela rend très difficile la comparaison avec un fichier *.pfc pré-rempli comme nous le faisons dans le test 55.

Je pense qu'il convient également de noter qu'il s'agit purement d'un problème de test et non d'un problème général aarch64. Dans le monde réel, seuls les numéros d'appel système valides seraient introduits dans l'API dans l'attente de résultats appropriés.

D'accord. J'ai besoin de prendre du recul et d'y réfléchir un peu. Il existe peut-être un moyen d'utiliser certains des outils bpf que vous avez créés pour vous aider dans les tests.

J'y ai pensé, mais cela rend très difficile la comparaison avec un fichier *.pfc pré-rempli comme nous le faisons dans le test 55.

La réponse est peut-être que pour le test 55, nous utilisons un sous-ensemble plus petit d'appels système (une douzaine, deux douzaines ?)

La réponse est peut-être que pour le test 55, nous utilisons un sous-ensemble plus petit d'appels système (une douzaine, deux douzaines ?)

Oui, je pense que c'est probablement la réponse la meilleure et la plus sûre. Donc, évidemment, la table syscall d'aarch64 n'a pas de trous jusqu'à 163. Savez-vous à quoi ressemblent les tables des autres architectures ?

Et sommes-nous convaincus qu'un arbre binaire d'environ 24 appels système teste complètement le code ? (Probablement plus une question pour moi que pour vous.) Mon intuition est oui, mais j'aimerais le parcourir et le passer également à travers des combinaisons.

Oui, je pense que c'est probablement la réponse la meilleure et la plus sûre. Donc, évidemment, la table syscall d'aarch64 n'a pas de trous jusqu'à 163. Savez-vous à quoi ressemblent les tables des autres architectures ?

Si seulement nous avions une table pré-construite d'architectures d'appels système ... oh attendez, nous le faisons ! ;)

Exemple utilisant aarch64, trié par numéro d'appel système :

# ./src/arch-syscall-dump -a aarch64 | sort -k2 -n

Et sommes-nous convaincus qu'un arbre binaire d'environ 24 appels système teste complètement le code ? (Probablement plus une question pour moi que pour vous.) Mon intuition est oui, mais j'aimerais le parcourir et le passer également à travers des combinaisons.

Un test qui n'est pas fiable, quel que soit son niveau d'exhaustivité, n'est pas utile. Je préférerais avoir un test "assez bon" qui soit toujours cohérent, partout où il est exécuté, à chaque fois qu'il est exécuté, sur lequel nous pourrons plus tard nous appuyer.

Si seulement nous avions une table pré-construite d'architectures d'appels système ... oh attendez, nous le faisons ! ;)

J'avais le sentiment qu'il y avait un outil pour ça. Merci ;)

Un test qui n'est pas fiable, quel que soit son niveau d'exhaustivité, n'est pas utile.

D'accord. Je suis devenu gourmand et j'ai pensé que je pouvais créer la série de tests. Eh bien, un test "assez bon" dans ce cas devrait être suffisant. Je vais m'y mettre aujourd'hui.

Je suis devenu gourmand et j'ai pensé que je pouvais créer la série de tests. Eh bien, un test "assez bon" dans ce cas devrait être suffisant. Je vais m'y mettre aujourd'hui.

Hé, pas de soucis, nous sommes tous tombés dans ce piège de temps en temps. C'est toujours une belle amélioration et nous avons au moins un test de base ; ça pourrait être bien pire :)

FWIW, il échoue également sur ppc64 :

nom du lot : 53-sim-binary_tree
mode d'essai : c
type de test : bpf-sim
Résultat du test 53-sim-binary_tree%%001-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%002-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%003-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%004-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%005-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%006-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%007-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%008-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%009-00001 : ERREUR 53-sim-binary_tree rc=14
Résultat du test 53-sim-binary_tree%%010-00001 : ERREUR 53-sim-binary_tree rc=14
...
mode d'essai : c
type de test : bpf-valgrind
Résultat du test 53-sim-binary_tree%%331-00001 : ÉCHEC 53-sim-binary_tree rc=14

Et 55-basic-pfc_binary_tree aussi :

nom du lot : 55-basic-pfc_binary_tree
mode d'essai : c
type de test : basique
Résultat du test 55-basic-pfc_binary_tree%%001-00001 : ÉCHEC 55-basic-pfc_binary_tree.sh rc=1

Salut @piso77 , merci pour le rapport. Une fois que @drakenclimber aura un correctif, seriez-vous prêt à le tester ?

Malheureusement, j'imagine qu'il peut y avoir quelques autres ABI qui ont des échecs similaires ; c'est simplement qu'aarch64 est la seule ABI non x86 à laquelle j'ai facilement accès à des fins de test. Le correctif dont nous avons discuté dans ce fil devrait résoudre tous ces échecs (je pense).

J'ai écrit un script python rapide pour trouver le premier trou dans chaque architecture.

Voici les résultats:

$ ./find-first-hole-in-each-arch.py 
aarch64's first syscall number hole is 163
arm's first syscall number hole is 7
mips64's first syscall number hole is 1
mips64n32's first syscall number hole is 1
mips's first syscall number hole is 1
parisc64's first syscall number hole is 102
ppc64's first syscall number hole is 192
ppc's first syscall number hole is 224
riscv64's first syscall number hole is 38
s390's first syscall number hole is 17
s390x's first syscall number hole is 13
x32's first syscall number hole is 1
x86_64's first syscall number hole is 335

Sur la base de ces résultats, je pense que nous devrions abaisser les tests 53 et 55 pour limiter le nombre d'appels système 12. Notez qu'il existe quelques architectures (mips, etc.) qui échoueront quel que soit le nombre faible que nous choisissons.

Salut @piso77 , merci pour le rapport. Une fois que @drakenclimber aura un correctif, seriez-vous prêt à le tester ?

Bien sûr, envoyez-moi un ping lorsqu'un correctif est disponible !

Notez qu'il existe quelques architectures (mips, etc.) qui échoueront quel que soit le nombre que nous choisissons.

Comment comptez-vous régler cela ?

Notez qu'il existe quelques architectures (mips, etc.) qui échoueront quel que soit le nombre que nous choisissons.

Comment comptez-vous régler cela ?

Je pensais que je vérifierais l'architecture native, et si elle correspondait à arm, mips* ou x32, alors nous sauterions les tests. Pas joli, mais je ne vois pas de moyen facile de tester l'arbre binaire sur ces systèmes.

Je pensais que je vérifierais l'architecture native, et si elle correspondait à arm, mips* ou x32, alors nous sauterions les tests. Pas joli, mais je ne vois pas de moyen facile de tester l'arbre binaire sur ces systèmes.

Si nous allons ignorer les ABI basées sur cela, nous pourrions aussi bien le limiter à x86_64. Ce qui est plutôt mauvais. Je ne sais pas si nous avons une priorité avec l'un des autres tests, mais je commence à penser que la bonne façon de résoudre ce problème est d'utiliser une liste de noms d'appels système et non de numéros. C'est un peu plus de travail dans le test, mais cela devrait probablement éviter cela complètement.

REMARQUE : les appels système n'ont pas besoin d'être valides pour cette ABI particulière tant qu'il s'agit de noms d'appel système valides dans notre table d'appel système interne.

Je ne sais pas si nous avons une priorité avec l'un des autres tests

Je crois que vous avez raison. Il s'agit d'une situation particulière.

Je commence à penser que la bonne façon de résoudre ce problème est d'utiliser une liste de noms d'appels système et non de numéros. C'est un peu plus de travail dans le test, mais cela devrait probablement éviter cela complètement.

Je suis bon avec ce choix. Je ne sais pas encore comment le faire fonctionner pour le boitier pfc (test 55), mais je vais tenter le coup !

Cela a été corrigé dans PR # 211 et un correctif de suivi que j'ai piraté ensemble (pas de PR) via dc2831e8fdcad71d565ba02abf732c8ffd260f66.