From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id CFBF4386C5A2 for ; Mon, 27 Jun 2022 14:08:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CFBF4386C5A2 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0e.wildebeest.org [172.31.17.144]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A60CB30005B6; Mon, 27 Jun 2022 16:08:10 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 73A242E83458; Mon, 27 Jun 2022 16:08:10 +0200 (CEST) Date: Mon, 27 Jun 2022 16:08:10 +0200 From: Mark Wielaard To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 2/4] tst-pkey.c: Handle no permission to alloc memory protection keys Message-ID: References: <20220626205915.33201-1-mark@klomp.org> <20220626205915.33201-3-mark@klomp.org> <87letjnmz6.fsf@mid.deneb.enyo.de> <6fae45d84c7a5cd7e88aab3898c5597809742422.camel@klomp.org> <87zghybaic.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zghybaic.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 14:08:13 -0000 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