Surely default-deny should fail the syscall with ENOSYS?

It's appropriate that a container runtime that wants to be a security boundary has a default-deny policy, but if it doesn't recognise a syscall, it should do the same thing the kernel does: make the syscall fail with ENOSYS, indistinguishable (except possibly by timing) from the effect of running on an older kernel that has no support for that syscall. That way, for ordinary syscalls (that are less odd than this one), well-behaved user-space can fall back to a less optimal implementation, for example emulating splice with read and write.

I thought Docker had addressed this already, last time newer container payloads were broken by Docker default-denying a newly-added syscall with EPERM and glibc not expecting that result?