Libseccomp: RFE : ajouter la prise en charge de RISC-V

Créé le 20 févr. 2018  ·  28Commentaires  ·  Source: seccomp/libseccomp

De @rwmjones :

RISC-V est un ISA open source et gratuit développé à UCB depuis 2010 (https://riscv.org/).

Nous avons un ancien PR de @rwmjones dans #50 qui a ajouté la prise en charge de libseccomp avant que la prise en charge du noyau ne soit en place (automne 2016).

Nous avons un PR plus récent de @Icenowy en #108 qui ajoute la prise en charge de libseccomp, bien que la prise en charge du noyau soit encore inconnue (février 2018).

Ce numéro est conçu pour suivre les notes et les progrès à travers les PR.

enhancement prioritlow

Commentaire le plus utile

J'attendrai que "[GIT PULL] mises à jour seccomp pour v5.5-rc1" soit également fusionné. Il y a un petit patch RISC-V là-bas.

Tous les 28 commentaires

La prise en charge du noyau @pcmoore est en amont dans 4.15.0. (Plus de pilotes sont nécessaires pour démarrer, ils sont attendus dans 4.17, mais 4.15 a l'uapi complet)

@sorear Je pense qu'il est normal de commenter une seule fois dans l'autre PR pour des choses comme ci-dessus.

... et pour mon futur moi, il ne semble pas que la v4.16-rc2+ ait le support HAVE_ARCH_SECCOMP_FILTER nécessaire pour RISC-V.

Mise à jour rapide, le support du noyau est toujours manquant dans l'arborescence de Linus :

# grep "HAVE_ARCH_SECCOMP_FILTER" $(find arch/*/  -type f)
arch/arm/Kconfig:       select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
arch/arm/kernel/ptrace.c:#ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
arch/arm64/Kconfig:     select HAVE_ARCH_SECCOMP_FILTER
arch/mips/Kconfig:      select HAVE_ARCH_SECCOMP_FILTER
arch/parisc/Kconfig:    select HAVE_ARCH_SECCOMP_FILTER
arch/powerpc/Kconfig:   select HAVE_ARCH_SECCOMP_FILTER
arch/s390/Kconfig:      select HAVE_ARCH_SECCOMP_FILTER
arch/um/Kconfig.common: select HAVE_ARCH_SECCOMP_FILTER
arch/x86/Kconfig:       select HAVE_ARCH_SECCOMP_FILTER

J'ai poussé un prototype de commit dans notre branche de développement risc-v ici : https://github.com/riscv/riscv-linux/commit/0712587b63964272397ed34864130912d2a87020

Je ne sais pas vraiment comment le tester, cependant.

Salut @terpstra

Si vous n'avez pas encore été en contact avec @kees, vous voudrez peut-être lui parler car il gère le code seccomp dans le noyau. En ce qui concerne les tests, libseccomp a quelques tests "en direct" (cd tests; ./regression -T live) qui testent le code seccomp dans le noyau ; il y a aussi des samples/seccomp dans les sources du noyau, mais je n'ai aucune expérience directe avec ceux-ci.

Je pense qu'il y a un 3ème patch dans openSUSE : https://build.opensuse.org/package/view_file/openSUSE : Factory:RISCV/libseccomp/riscv.patch?expand=1

mais il manque __NR_riscv_flush_icache .

Le dernier PR de libseccomp : https://github.com/seccomp/libseccomp/pull/134

Salut @terpstra , le correctif https://github.com/riscv/riscv-linux/commit/0712587b63964272397ed34864130912d2a87020 a-t-il fusionné dans le noyau principal ? Une idée sur un calendrier pour cela? Peut-être que @palmer-dabbelt peut vous aider à ce sujet.

J'ai déchargé tous les trucs de pilotes Linux que j'ai écrits pour le U540 à Paul
et Palmer. Je ne suis plus au courant de l'amont.

Le mer. 5 juin 2019 à 12:53 Carlos Eduardo [email protected]
a écrit:

Salut @terpstra https://github.com/terpstra , ayez le patch
riscv/ riscv-linux@0712587
https://github.com/riscv/riscv-linux/commit/0712587b63964272397ed34864130912d2a87020
fusionné dans le noyau principal ? Une idée sur un calendrier pour cela? Peut-être
@palmer-dabbelt https://github.com/palmer-dabbelt peut vous aider à ce sujet.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/seccomp/libseccomp/issues/110?email_source=notifications&email_token=AAIM7CU2KQFCLUTSCO2VYILPZAKUXA5CNFSM4ERS6NOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJLODXTDN5WW2GO92Z306
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAIM7CXIDCVBETFXJLBRY73PZAKUXANCNFSM4ERS6NOA
.

J'ai envoyé des correctifs seccomp v1 il y a quelques mois (je pense), qui réussissaient la suite de tests libseccomp et les autotests du noyau. J'ai besoin de trouver le temps de retester sur le dernier noyau pour envoyer la v2. Le correctif libseccomp est ici : https://github.com/seccomp/libseccomp/pull/134

@carlosedp à quelle vitesse en avez-vous besoin ?

Je ne m'en inquiéterais pas tant que le correctif du noyau n'a pas atterri dans l'arborescence de Linus, mais le PR #134 semble avoir besoin d'un port de transfert vers la branche principale libseccomp actuelle.

Je n'ai pas regardé RISC-V depuis un certain temps, existe-t-il du matériel RISC-V à un prix raisonnable et raisonnablement performant pour le développement/les tests qui exécutera une distribution standard ?

@davidlt J'ai tiré et appliqué le patch PR134 et il teste parfaitement même sans patchs Kernel. Ce serait formidable de donner à libseccomp pour ouvrir la construction d'autres dépendances. J'exécute déjà Docker localement construit avec cela.

@pcmoore Côté matériel, seule la carte SiFive Unleashed est chère. Il y a une VM Qemu que j'ai emballée avec Debian (mais il y a aussi un rootfs de Fedora que je pourrais emballer). Il peut être utilisé pour le développement.

Je suis les dépendances sur https://github.com/carlosedp/riscv-bringup

En fait, je viens de retester avec le Tip avec PR134. J'ai eu 6 tests ratés.

Les résultats peuvent être consultés sur https://gist.github.com/carlosedp/7e1e222e5ccb4b45faa357dd6b30ac9a

Hum, c'est étrange. D'après la sortie du test, il semble que le test 46 échoue avec ENOMEM, ce qui est un peu inhabituel (voir tools/scmp_bpf_sim.c). Je suis plutôt occupé en ce moment et je n'ai pas de machine virtuelle RISC-V à portée de main pour tester cela, mais si vous avez besoin de conseils sur la façon de déboguer cela, n'hésitez pas à demander.

J'ai à la fois une VM Qemu et une carte Risc-V. Mon noyau actuel n'a pas de correctifs seccomp appliqués. Si vous avez des conseils sur la façon dont je peux aider, je suis heureux de le faire!
Sinon si vous voulez une VM RiscV Qemu, j'ai concocté un pack sur https://github.com/carlosedp/riscv-bringup#virtual -machine-and-pre-built-docker.

@davidlt une mise à jour sur la prise en charge du noyau RISC-V ?

https://lkml.org/lkml/2019/10/14/811

Il semble avoir été entièrement revu, mais le patch final perdu entre deux développeurs.

Le patch a été envoyé à Linus pour le noyau 5.4, mais il ne voulait pas le tirer si loin dans les RC. Le patch atterrira dans la fenêtre de fusion 5.5.

Notez que le correctif est déjà dans linux-next, si cela compte.

C'est une bonne nouvelle, merci à tous ! Puisqu'il semble que nous soyons à quelques semaines de voir cela dans l'arbre de Linus, je vais aller de l'avant et le marquer pour le jalon libseccomp v2.5.

Quelqu'un souhaite-t-il se porter volontaire pour actualiser/tester/soumettre le PR une fois la fenêtre de fusion fermée ?

J'enverrai une nouvelle version de PR une fois que libseccomp atterrira dans l'arborescence de Linus.

Super, merci @davidlt.

J'attendrai que "[GIT PULL] mises à jour seccomp pour v5.5-rc1" soit également fusionné. Il y a un petit patch RISC-V là-bas.

Merci a tous. Nous avons encore un certain nombre de choses sur la liste TODO pour la version 2.5 donc je pense que nous avons un peu de temps.

Mise à jour rapide. J'ai commencé à mettre à jour Fedora/RISCV vers 5.5-rc2 et il y a un certain nombre de problèmes. J'ai peut-être trouvé un problème créé par SECCOMP dans le noyau et j'ai d'abord travaillé pour le résoudre. Ce problème n'a pas été montré par la suite de tests libseccomp ou les autotests du noyau seccomp.

Merci pour la mise à jour. FWIW, les tests libseccomp ne testent pas agressivement le noyau, ils se concentrent davantage sur le côté bibliothèque (exécution de code via un simulateur BPF).

Cela devrait être résolu via #197, fermeture.

Cette page vous a été utile?
0 / 5 - 0 notes