Doesn't work with kernel.yama.ptrace_scope=3

[artemislena]

Description

Tried using gVisor with podman on NixOS, rather than the container starting, getting complaints that some "sync file" cannot be read, without further details.

Steps to reproduce

1. Install gVisor (on NixOS? might be specific to that since NixOS uses non-standard paths for some things)
2. podman run --rm --runtime=/path/to/runsc docker.io/hello-world

runsc version

runsc version VERSION_MISSING
spec: 1.1.0-rc.1

(installed with Nix on the nixos-unstable channel, should be 20240401.0)

docker version (if using docker)

podman version 5.0.3

uname

Linux 6.6.32-hardened1 #1-NixOS SMP PREEMPT_DYNAMIC Sat May 25 14:22:56 UTC 2024 x86_64 GNU/Linux

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

https://gist.github.com/artemislena/5671bde6dc72644a1e395e9ee223c22a (too long for issue)

[ayushr2]

The debug log shows the issue:

panic: unable to initialize systrap source: unable to attach: operation not permitted

goroutine 1 gp=0xc0000061c0 m=3 mp=0xc000065008 [running]:
panic({0x1082600?, 0xc000263640?})
	runtime/panic.go:779 +0x158 fp=0xc000586c70 sp=0xc000586bc0 pc=0x43cad8
gvisor.dev/gvisor/pkg/sentry/platform/systrap.New.func1()
	gvisor.dev/gvisor/pkg/sentry/platform/systrap/systrap.go:335 +0xb9 fp=0xc000586cb8 sp=0xc000586c70 pc=0xd45cd9
sync.(*Once).doSlow(0x20034d0?, 0xc000322040?)
	sync/once.go:74 +0xc2 fp=0xc000586d18 sp=0xc000586cb8 pc=0x484aa2
sync.(*Once).Do(...)
	sync/once.go:65
gvisor.dev/gvisor/pkg/sentry/platform/systrap.New()
	gvisor.dev/gvisor/pkg/sentry/platform/systrap/systrap.go:326 +0x65 fp=0xc000586d50 sp=0xc000586d18 pc=0xd45ba5
gvisor.dev/gvisor/pkg/sentry/platform/systrap.(*constructor).New(0xc0002ee5a0?, 0x1?)
	gvisor.dev/gvisor/pkg/sentry/platform/systrap/systrap.go:392 +0xf fp=0xc000586d60 sp=0xc000586d50 pc=0xd45e4f
gvisor.dev/gvisor/runsc/boot.createPlatform(0xc000252f08, 0x0)
	gvisor.dev/gvisor/runsc/boot/loader.go:677 +0xf2 fp=0xc000586df0 sp=0xc000586d60 pc=0xe9db32
gvisor.dev/gvisor/runsc/boot.New({{0x7008c3cc3341, 0x40}, 0xc00009c3f0, 0xc000252f08, 0xe, 0x0, {0xc0000d5d00, 0x6, 0x8}, 0xffffffffffffffff, ...})
	gvisor.dev/gvisor/runsc/boot/loader.go:405 +0x974 fp=0xc000587608 sp=0xc000586df0 pc=0xe9b654
gvisor.dev/gvisor/runsc/cmd.(*Boot).Execute(0xc000002180, {0xc00003e290?, 0x1082600?}, 0xc0001f1b20, {0xc00004bb40, 0x2, 0x20?})
	gvisor.dev/gvisor/runsc/cmd/boot.go:447 +0x1558 fp=0xc000587ce8 sp=0xc000587608 pc=0xfb8a38
github.com/google/subcommands.(*Commander).Execute(0xc0000cc000, {0x150a580, 0x2002a40}, {0xc00004bb40, 0x2, 0x2})
	github.com/google/[email protected]/subcommands.go:200 +0x37a fp=0xc000587d80 sp=0xc000587ce8 pc=0x51d3fa
github.com/google/subcommands.Execute(...)
	github.com/google/[email protected]/subcommands.go:481
gvisor.dev/gvisor/runsc/cli.Main()
	gvisor.dev/gvisor/runsc/cli/main.go:221 +0x1408 fp=0xc000587f40 sp=0xc000587d80 pc=0xfe7ee8
main.main()
	gvisor.dev/gvisor/runsc/main.go:31 +0xf fp=0xc000587f50 sp=0xc000587f40 pc=0xfe8d4f
runtime.main()
	runtime/proc.go:271 +0x29d fp=0xc000587fe0 sp=0xc000587f50 pc=0x4400fd
runtime.goexit({})
	runtime/asm_amd64.s:1695 +0x1 fp=0xc000587fe8 sp=0xc000587fe0 pc=0x478b81

cc @avagin

[artemislena]

Oh, that part is probably because I ran with --strace and kernel.yama.ptrace_scope was set to 3? I'll try again with a less restrictive setting for that. Although it still crashes without --strace.

[artemislena]

So, interestingly enough, regardless whether --strace is specified, runsc seems to work as long as ptrace_scope is set to 2 rather than 3 (which also makes me relatively confident this isn't a NixOS-specific issue at all). Does gVisor need ptrace to work?

[artemislena]

Ah, apparently it works for the KVM platform, only the systrap and presumably the ptrace platforms (didn't try the latter) need ptrace to be enabled. Guess that's expected behaviour then and I can close this issue?

[EtiennePerot]

So, interestingly enough, regardless whether --strace is specified, runsc seems to work as long as ptrace_scope is set to 2 rather than 3 (which also makes me relatively confident this isn't a NixOS-specific issue at all). Does gVisor need ptrace to work?

The gVisor Systrap platform needs the ability to execute ptrace-related syscalls to work. It uses them as part of the procedure to spawn new stub threads.