Container Sandbox: Unsupported syscall UNKNOWN[439/0x1b7](0xffffffffffffff9c,0x3e080c92c500,0x1,0x200,0x200,0x3e080c92c500).

[steren]

Description

In Cloud Run first generation execution environment, which uses gVisor, I get this debug log:

Container Sandbox: Unsupported syscall UNKNOWN[439/0x1b7](0xffffffffffffff9c,0x3e080c92c500,0x1,0x200,0x200,0x3e080c92c500).

I am running this code

Steps to reproduce

No response

runsc version

No response

docker version (if using docker)

No response

uname

No response

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

[kevinGC]

Per the x86_64 syscall table, this is a call to faccessat2. Because the syscall is relatively new, most likely the code is attempting to use it, then falling back to another syscall (probably faccessat). It probably doesn't affect the correctness of the code -- this is a common way for applications to test whether they can use the newest features that exist only in the newest kernels.

Is this affecting correctness (i.e. causing an error), or just producing a log line?

[steren]

It doesn't seem to affect production. I would suggest to silence if after an analysis we confirm we expect software to fallback to other syscalls (which you did)

[kevinGC]

gVisor probably won't want to silence this. Some things we do silence, e.g. https://github.com/google/gvisor/commit/007a91a911084e46efffc4e2531ff8dee5cf1917. That commit can safely be silenced because use of SO_RCVLOWAT doesn't affect correctness.

But it's possible for some app or library to be written without a fallback. In those cases, we don't want to silence the warning.

[amscanne]

It seems that faccessat2 is pretty easily implementable. Can we just knock that out? It is only faccess with the ability to specify whether symlinks should be followed and whether effective UID/GIDs should be used. See also: https://cs.opensource.google/gvisor/gvisor/+/master:pkg/sentry/syscalls/linux/sys_file.go;drc=5c95e1d39c19a9783a919783cbf65534d30437d6;l=575 https://cs.opensource.google/gvisor/gvisor/+/master:pkg/sentry/syscalls/linux/sys_file.go;drc=3b83c30622c043d57a393b26018ad6a41b924684;l=535

[nlacasse]

faccessat2 is already implemented in VFS2: https://github.com/google/gvisor/blob/master/pkg/sentry/syscalls/linux/vfs2/vfs2.go#L166

VFS2 is enabled by default in almost all environments, but is still rolling out to Cloud Run. Hopefully that rollout will finish soon.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 120 days.

[ayushr2]

faccessat2 is supported and VFS1 is now deleted.