Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2985904pxb; Sun, 3 Oct 2021 11:17:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJkYJFt23WWDy8K3mCyC7emI7p8TPJ4lm47q/HGMYoJyWEqg+IOWMY49n3aw5GfxxYXT7s X-Received: by 2002:a05:6402:44c:: with SMTP id p12mr13120345edw.145.1633285036283; Sun, 03 Oct 2021 11:17:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633285036; cv=none; d=google.com; s=arc-20160816; b=pMMlVSKgyNfaznaYAraUtoGjaA9RMz+2iietJS5Yb8eYbXk/fdF2JixKNoXUDPSS/s ryNRt3DfTtZRBpAyk34HlNzbyqSaSxFsWZq6/RKSmOGb4ypxHvQRKfj9oIt3Biw25RXB bwpgSqO5w28OFDQ/G2YoO0x3EK/kcLTjrw+Vn0xIaaTp1KoM37F6cBlhGnDbuviFn/0R Kqi63mdfQRWfG1ml//AevC3XIvCagD/r19+lUNVNxjKUPX0X8NCbIeuf9cYOYg6c0jZN 1YmZGQJocLeLnJsCNtvH8ntK8b6qiPnFGeJXuOaJ2r1kcmqWH4GIzjpLLmIhMNm5bopx Ak9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=QHjcDVVUouu29tsx4dLsP3winaBc90JSA/WlZXQce5w=; b=CfBsfcQmC5+cwyq57wWEzU0UnFUCCSbsa9pSUQXrKXGpL3ONXg7RUPzrNRpxyjIoOz 02smKX9faxylJqEk3O4Nk/qeorbHnc3A/tVljFd5Ixonu08UTrgxtpgedsTeeJuChYTA xD8FKnvpMZqNeA4zjL/BeIpG3YVXp/UvFXPLhSWYgboJGxp9kwiQCnSeUcLRFuQadmMS zO1Udm3FpOynBYm4YxV1ur1dbApofAMucVYbh0055m1cDdQhLxsu8mlMHo7AyCr/INXd uSwteYQY1NPmB9P30mTtj6TIF65dmV2HlV6c4Is5/w+/KeN1lLibFfb5Jujork/TLij3 W4wA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=1+uekvGT; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i24si7727540eds.331.2021.10.03.11.16.49; Sun, 03 Oct 2021 11:17:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=1+uekvGT; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231575AbhJCSR0 (ORCPT + 99 others); Sun, 3 Oct 2021 14:17:26 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50896 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231567AbhJCSRJ (ORCPT ); Sun, 3 Oct 2021 14:17:09 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 987AC22188; Sun, 3 Oct 2021 18:15:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284920; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QHjcDVVUouu29tsx4dLsP3winaBc90JSA/WlZXQce5w=; b=1+uekvGTjlw4cXArRNyEBNDOOk2NC8ve/KZ6ptteCneb3/sUzVuPQI3VAfa1HhsCch9th2 7uws+R2eSzdHsq/NJ0EUNK02w9KNsR1yo7yDrd+CASLgEwEDDcxrVEuNCRtyBHAWpcRCWb MUNS4rHQ5Jy1Es3I9RoWxdJFaMq8wHs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284920; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QHjcDVVUouu29tsx4dLsP3winaBc90JSA/WlZXQce5w=; b=2/V2yKc5PcrHcHKPkdESkTbJuk7SAeBCvzcH4gLK9c9/Erke+PieJDKpU0JJv4+V6Jn+Fy ZoiljKS5I/eD3CCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8203313A09; Sun, 3 Oct 2021 18:15:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id xHjaHjjzWWHPEwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:20 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?q?Stephan=20M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 8/8] crypto: api - make the algorithm lookup priorize non-larvals Date: Sun, 3 Oct 2021 20:14:13 +0200 Message-Id: <20211003181413.12465-9-nstange@suse.de> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20211003181413.12465-1-nstange@suse.de> References: <20211003181413.12465-1-nstange@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org crypto_alg_mod_lookup() invokes the crypto_larval_lookup() helper to run the actual search for matching crypto_alg implementation and larval entries. The latter is currently considering only the individual entries' relative ->cra_priority for determining which one out of multiple matches to return. This means that it would potentially dismiss a matching crypto_alg implementation in working state in favor of some pending testing larval of higher ->cra_priority. Now, if the testmgr instance invoked asynchronously on that testing larval came to the conclusion that it should mark the tests as failed, any pending crypto_alg_mod_lookup() waiting for it would be made to fail as well with -EAGAIN. In summary, crypto_alg_mod_lookup() can fail spuriously with -EAGAIN even though an implementation in working state would have been available, namely if the testmgr asynchronously marked another, competing implementation of higher ->cra_priority as failed. This is normally not a problem at all with upstream, because the situation where one algorithm passed its tests, but another competing one failed to do so, would indicate a bug anyway. However, for downstream distributions seeking FIPS certification, simply amending the list in crypto/testmgr.c with ->fips_allowed = 0 entries matching on ->cra_driver_name would provide a convenient way of selectively blacklisting implementations from drivers/crypto in fips mode. Note that in this scenario failure of competing crypto_alg implementations would become more common, in particular during device enumeration. If the algorithm in question happened to be needed for e.g. module signature verification, module loading could spuriously fail during bootup, which is certainly not desired. For transparency: this has not actually been observed, I merely came to the conclusion that it would be possible by reading the code. Make crypto_alg_lookup() run an additional search for non-larval matches upfront in the common case that the request has been made for CRYPTO_ALG_TESTED instances. Signed-off-by: Nicolai Stange --- crypto/api.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/crypto/api.c b/crypto/api.c index 594c494a27d9..4251eedef668 100644 --- a/crypto/api.c +++ b/crypto/api.c @@ -239,8 +239,25 @@ static struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, struct crypto_alg *alg; down_read(&crypto_alg_sem); + /* + * If the request is for an algorithm having passed its + * selftests, try to serve it with a matching instance already + * in operational state. That is, skip pending larvals in a + * first search: for these it is not guaranteed that they will + * eventually turn out successful and it would be a pity to + * potentially fail the request even though a working + * implementation would have been available. If OTOH the + * request is *not* for an algorithm having passed its + * selftest (yet), no larval can match it anyway, so the + * CRYPTO_ALG_LARVAL in the mask below won't make a + * difference. + */ + alg = __crypto_alg_lookup(name, type, mask | CRYPTO_ALG_LARVAL); + if (alg || !(type & CRYPTO_ALG_TESTED)) + goto out; + alg = __crypto_alg_lookup(name, type, mask); - if (!alg && (type & CRYPTO_ALG_TESTED)) { + if (!alg) { /* * Check whether there's an instance which failed the * selftests in order to avoid pointless retries. @@ -254,6 +271,8 @@ static struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, alg = ERR_PTR(-ELIBBAD); } } + +out: up_read(&crypto_alg_sem); return alg; -- 2.26.2