Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#858 0 comentários 1 reação 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
68/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
linux, rust
Domínio
operating-systems

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Rust
Estrelas
478
Forks
48
Merge médio
23h 10min
PRs com merge (30d)
71

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de voidzero-dev/vite-task

Todas as issues de voidzero-dev/vite-task

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.