Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

fspy does not record file accesses of static programs on kernels without process_vm_readv

Ouverte
  • Quelque chose ne va pas ?
#858 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
linux, rust
Domaine
operating-systems

Piste de recherche

Start by reading crates/fspy_seccomp_unotify/src/supervisor/handler/arg.rs:47 and the error handling in crates/fspy_seccomp_unotify/src/supervisor/mod.rs:121. Reproduce with cargo test -p fspy --test static_executable on a kernel where process_vm_readv returns ENOSYS, then add or verify fallback behavior for /proc/<pid>/mem and incomplete tracking. Done means static-program file accesses are recorded on affected kernels and the cache does not retain incomplete results.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem

Some Linux kernels do not have the process_vm_readv system call. On these kernels, fspy does not record the file accesses of static programs. The task shows no error.

If you change a file that a static program read, the cache does not detect the change. Then the vp run command uses the old cached output.

On musl builds, fspy uses seccomp for all programs, so this problem affects every tracked program (not tested).

Affected kernels

The CONFIG_CROSS_MEMORY_ATTACH kernel option adds the process_vm_readv system call. The following kernels do not set this option:

  • Kata Containers guest kernels. Kata builds these kernels from a configuration that has all options off. Then Kata adds only the options that it needs.
  • The default kernel of Apple container. This kernel is the Kata 3.32.0 kernel vmlinux-6.18.35-197. The /proc/config.gz file of this kernel shows # CONFIG_CROSS_MEMORY_ATTACH is not set.

The default value of this option is y. Most distribution kernels set it.

Cause

For static programs, fspy intercepts system calls with seccomp. The supervisor process then reads each path argument from the memory of the program.

  1. The supervisor reads the memory only with the process_vm_readv system call (crates/fspy_seccomp_unotify/src/supervisor/handler/arg.rs:47).
  2. On the affected kernels, the process_vm_readv system call fails with the ENOSYS error.
  3. The supervisor ignores the error and lets the intercepted system call continue (crates/fspy_seccomp_unotify/src/supervisor/mod.rs:121).
  4. fspy does not record the access.

Steps to reproduce

  1. Start a Fedora virtual machine (VM) with Apple container and its default kernel.
  2. In the VM, check out commit b182c9be.
  3. Run cargo test -p fspy --test static_executable.

Result: 9 of 10 tests fail. Only the readdir test passes, because that test does not read the memory of the program. In each failed test, fspy records only the execution of the test program:

Expected accesses to /hello to match, as (actual, expected): [].
All accesses: [Read(".../fspy-test-bin"), Read(".../fspy-test-bin")]

I also tested a child process in the same VM:

  • The process_vm_readv system call fails with the ENOSYS error.
  • A read of the /proc/<pid>/mem file at the same address returns the correct data.

Possible fixes

  1. If the process_vm_readv system call fails with the ENOSYS error, read the /proc/<pid>/mem file with the pread system call. This file does not need the kernel option. Reads of this file use the same permission check as the process_vm_readv system call. I have not tested this fix in fspy.
  2. If the supervisor cannot read an access, do not cache the task. vite-task already does this with the TrackingIncomplete reason when the access channel is full. This fix also covers other read errors, such as permission errors.
Langage dominant
Rust
Étoiles
478
Forks
48
Merge moyen
1 j 3 h
PR mergées (30 j)
72

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de voidzero-dev/vite-task

Toutes les issues de voidzero-dev/vite-task

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.