Re: [PATCH 2/4] tst-pkey.c: Handle no permission to alloc memory protection keys

[Mark Wielaard <mark@klomp.org>]

Hi Florian,

On Mon, Jun 27, 2022 at 01:39:55PM +0200, Florian Weimer wrote:
> * Mark Wielaard:
> > You are thinking of the fix to set errno to ENOSYS for syscalls that
> > are "unknown". That is a syscall number higher than any syscall number
> > mentioned in the seccomp filter. But the pkey calls are simply not
> > mentioned in the default seccomp filter. And newer syscalls are listed.
> > So this (EPERM) is the default errno returned in such cases till the
> > pkey calls are in the default seccomp profile.
> >
> > https://github.com/moby/moby/issues/43481
> > https://github.com/moby/moby/issues/42871
> 
> Ah, so Moby is still stuck with the somewhat broken heuristic (where
> unrelated syscall list updates break existing syscalls).

I think that is an issue for any environment that uses seccomp to
restrict certain syscall features, unless you explicitly list all
syscalls you are left with some default behaviour that might be
surprising in some situations.

> Could you switch to podman instead?

Sadly no. Although podman is fairly compatible with docker on the
command line it has various (minor) incompatibilities when used
through the Docker Engine API (which buildbot does).
https://sourceware.org/pipermail/overseers/2022q2/018406.html

> > In general I think if we detect pkey_alloc fails we should not try to
> > test and/or FAIL the pkey tests but simply mark it as UNSUPPORTED.
> > Whether we believe the errno value really should be ENOSYS, ENOSPC or
> > EINVAL. It isn't really that helpful to explicitly FAIL on EPERM. Sadly
> > this issue will be with us for a long time.
> 
> On the other hand, if we just ignore problems like issue 43481 (which is
> essentially requesting that PKU is supported in Moby containers by
> default), than they might never get fixed.
> 
> On the other hand, PKU is a bit of a fringe feature (and it's hard to
> change that for core libraries due to the inconstant signal handling
> behavior), so maybe we should defang the EPERM error after all.

Right, the EPERM is real, it really doesn't make sense to try to test,
or deliberately fail, the pkey testcase in that case.

Cheers,

Mark