Incorrect default errnoRet ?

[kallisti5]

It appears per concourse/concourse#7471 and @fweimer-rh that the wrong errnoRet is chosen in the golang runtime-spec?

The default is EPERM, and @fweimer-rh is indicating it should be ENOSYS instead?

On Fedora 34 systems, this is causing 32-bit code to fail to run within 64-bit x86_64 containers.

[cyphar]

The default is EPERM because that is the historical default and we need to maintain backwards compatibility with older configurations. However, in runc we have a somewhat complicated mechanism to make sure we return ENOSYS for syscalls that are above the highest-specified syscall number in the profile -- this means that assuming you are using a new enough version of runc (1.0.0-rc95 or later from memory) you shouldn't be hitting this issue.

(The reason why we have this complicated setup rather than just returning ENOSYS is because existing profiles assume that missing syscalls will return EPERM. Every other solution I could think of was either too brittle due to libseccomp missing the features we need -- even now runc does some monkey-patching of the libseccomp-generated BPF.)

[kallisti5]

eesh

The tldr of all of this is a runc container is unable to execute x86 32-bit binaries. ioctl's for statx fail with EPERM.

• Is there any workaround for Fedora 34 systems?
• Does this issue exist on other distributions?
• Will this issue exist on other distributions in the future?

Honestly, i'm just looking for what needs to happen to fix the issue and am in over my head at this point without learning all of the internals of runc.

[kallisti5]

Oh.. as for runc:

$ runc -v
runc version 1.0.1
commit: v1.0.1-0-g4144b63
spec: 1.0.2-dev
go: go1.15.14
libseccomp: 2.5.0

[giuseppe]

does it work if you force ENOSYS for statx ( or allow it) in your seccomp profile?

[safinaskar]

@giuseppe , @cyphar , so what? The specification still twice mentions EPERM as default error code here: https://github.com/opencontainers/runtime-spec/blob/46369fd11df9103237e0f862499e9e57fe1f4e6e/config-linux.md?plain=1 (Ctrl-F reveals two EPERM mentions in the text). Please do what richfelker suggested in #1087 (comment) : "Why can't the spec just be fixed to specify what runc is doing to fix the problem?"

[giuseppe]

we allow to override the default errno now. I think this is a solved problem