From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1B2DB386F0DB for ; Mon, 27 Jun 2022 11:40:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B2DB386F0DB Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-22-iKOMEZq6Pye5sZoY2ZdIcw-1; Mon, 27 Jun 2022 07:39:58 -0400 X-MC-Unique: iKOMEZq6Pye5sZoY2ZdIcw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7B3B229DD98B; Mon, 27 Jun 2022 11:39:58 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.138]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A2E711415108; Mon, 27 Jun 2022 11:39:57 +0000 (UTC) From: Florian Weimer To: Mark Wielaard Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 2/4] tst-pkey.c: Handle no permission to alloc memory protection keys References: <20220626205915.33201-1-mark@klomp.org> <20220626205915.33201-3-mark@klomp.org> <87letjnmz6.fsf@mid.deneb.enyo.de> <6fae45d84c7a5cd7e88aab3898c5597809742422.camel@klomp.org> Date: Mon, 27 Jun 2022 13:39:55 +0200 In-Reply-To: <6fae45d84c7a5cd7e88aab3898c5597809742422.camel@klomp.org> (Mark Wielaard's message of "Mon, 27 Jun 2022 11:50:19 +0200") Message-ID: <87zghybaic.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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 11:40:01 -0000 * Mark Wielaard: > It is reasonably up to date. This is a container based on Fedora 36 > packages running under Fedora CoreOS stable (36.20220605.3.0, Release > Date: Jun 20, 2022) with moby-engine20.10.16. Okay. > 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). Could you switch to podman instead? > 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. Thanks, Florian