From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id AD3A5386DC5B for ; Sun, 26 Jun 2022 21:40:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AD3A5386DC5B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=38763 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1o5ZzJ-00DnBz-9u; Sun, 26 Jun 2022 21:40:13 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.94.2) (envelope-from ) id 1o5ZzI-0009Nf-UO; Sun, 26 Jun 2022 23:40:12 +0200 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> Date: Sun, 26 Jun 2022 23:40:12 +0200 In-Reply-To: <87letjnmz6.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Sun, 26 Jun 2022 23:17:33 +0200") Message-ID: <87a69znlxf.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, 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: Sun, 26 Jun 2022 21:40:16 -0000 * Florian Weimer: > * Mark Wielaard: > >> pkey_alloc might fail with errno EPERM if there is no permission >> to allocate memory protection keys. Use FAIL_UNSUPPORTED in that >> case. >> --- >> sysdeps/unix/sysv/linux/tst-pkey.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/sysdeps/unix/sysv/linux/tst-pkey.c b/sysdeps/unix/sysv/linux/tst-pkey.c >> index df51f695bc..48a20fa3e0 100644 >> --- a/sysdeps/unix/sysv/linux/tst-pkey.c >> +++ b/sysdeps/unix/sysv/linux/tst-pkey.c >> @@ -203,6 +203,9 @@ do_test (void) >> FAIL_UNSUPPORTED >> ("no keys available or kernel does not support memory" >> " protection keys"); >> + if (errno == EPERM) >> + FAIL_UNSUPPORTED >> + ("no permission to alloc memory protection keys"); >> FAIL_EXIT1 ("pkey_alloc: %m"); >> } >> TEST_COMPARE (pkey_get (keys[0]), 0); > > It's rather weird to restrict access to a hardening tool. Is this in > a container, and is the container tool reasonably up to date? They > should all have switchted to ENOSYS for reducing the system call > profile. I was thinking about this bug in particular: systemd: Unknown system calls should produce ENOSYS under systemd-nspawn