From patchwork Sun Oct 3 18:14:06 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532977 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 557B6C433F5 for ; Sun, 3 Oct 2021 18:15:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3DEC061A0A for ; Sun, 3 Oct 2021 18:15:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231414AbhJCSQ4 (ORCPT ); Sun, 3 Oct 2021 14:16:56 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50796 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231296AbhJCSQ4 (ORCPT ); Sun, 3 Oct 2021 14:16:56 -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 8694E22188; Sun, 3 Oct 2021 18:15:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284907; 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=Y0NsFhX+iG9v6yqRJSdn1Z2f2KeEAmY9udesNCSPze4=; b=v4dQuBfoqmSTqpkMZUOhOsV4qIDJ3Y5ljpmBoms1igjAWc1soBgofdAJen/7vq+uAcTssM a/OR5FZUSFQVYduv0AOErdiSJNGoFggdfI7lMLiO0Mr7FMf1kSRgI6DmSYoxjVl+EBFGi1 fIViuoYNy9U0ga5mjbIwMsC0tp9YeRI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284907; 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=Y0NsFhX+iG9v6yqRJSdn1Z2f2KeEAmY9udesNCSPze4=; b=kam+WftdXtX/I9KJz0HzyoTx8LALywNtb2Nqqlz9bqthdBbCzAk9704pMuFBQ1IUjE/+sY AoPqhu8CytwWjvAA== 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 73EDA13A09; Sun, 3 Oct 2021 18:15:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id L+UJGyvzWWGlEwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:07 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?St?= =?utf-8?q?ephan_M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 1/8] crypto: af_alg - reject requests for untested algorithms Date: Sun, 3 Oct 2021 20:14:06 +0200 Message-Id: <20211003181413.12465-2-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Currently it's possible for userspace to specify any combination of ->salg_feat and ->salg_mask with respect to CRYTPO_ALG_TESTED via the af_alg interface. As these are passed onwards to crypto_larval_lookup() unmodified as 'mask' and 'type' parameters eventually, this can lead to the creation of obscure lookup larvals like e.g. (mask & CRYTPO_ALG_TESTED) but not (type & CRYTPO_ALG_TESTED) or the other way around. Userspace should have no business in asking for untested algorithms. Make af_alg's alg_bind() reject nonsensical combinations of ->salg_feat and ->salg_mask with respect to CRYTPO_ALG_TESTED with -EINVAL. Note that CRYTPO_ALG_TESTED not being set in either of mask and type is considered equivalent to that flag being set in both and these two combinations are the only ones supported as of now. Signed-off-by: Nicolai Stange --- crypto/af_alg.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/crypto/af_alg.c b/crypto/af_alg.c index 8bd288d2b089..83e68f3f71db 100644 --- a/crypto/af_alg.c +++ b/crypto/af_alg.c @@ -166,6 +166,15 @@ static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len) if ((sa->salg_feat & ~allowed) || (sa->salg_mask & ~allowed)) return -EINVAL; + /* + * Don't allow requests for untested algorithms, i.e. those + * where the selftests are still in progress or have failed. + * CRYPTO_ALG_TESTED must be set either in none or both of + * type and mask (which is equivalent). + */ + if ((sa->salg_feat ^ sa->salg_mask) & CRYPTO_ALG_TESTED) + return -EINVAL; + sa->salg_type[sizeof(sa->salg_type) - 1] = 0; sa->salg_name[addr_len - sizeof(*sa) - 1] = 0; From patchwork Sun Oct 3 18:14:07 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532979 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4B7DC4332F for ; Sun, 3 Oct 2021 18:15:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AEDA261A54 for ; Sun, 3 Oct 2021 18:15:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231461AbhJCSQ6 (ORCPT ); Sun, 3 Oct 2021 14:16:58 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50816 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231447AbhJCSQ6 (ORCPT ); Sun, 3 Oct 2021 14:16:58 -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 7BE7322188; Sun, 3 Oct 2021 18:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284909; 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=HL6CTQHPtji59S+giSYYALkCAHuGrPm7hT4YVgG6v2A=; b=n8o5IDYzrUVyIGYNeozSfikcGlX/dyE+WNeB85ekxbDcJEBlJvFlXKGLBZXeOtNurZe3QK 496OB2aCqUXA3svSGtbQlysWB7NW9LpiN2wmaMy4kd57xeCF8TpVVGYV12BWgX1WEbalCp ADwm+D6NooWxn7bjkkb2slDkKTau89g= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284909; 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=HL6CTQHPtji59S+giSYYALkCAHuGrPm7hT4YVgG6v2A=; b=agGXak8dAMyk02ULqxajW8UGsKuuOCj5E90Ifaq8uV1trBVxbdLDa3CbMPEk2/zkGSSBNB 25Rbmfz+wwY4ByDQ== 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 682CB13A09; Sun, 3 Oct 2021 18:15:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id K5/2Fy3zWWGpEwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:09 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?St?= =?utf-8?q?ephan_M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 2/8] crypto: user - reject requests for untested algorithms Date: Sun, 3 Oct 2021 20:14:07 +0200 Message-Id: <20211003181413.12465-3-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Currently it's possible for userspace to specify any combination of ->cru_type and ->cru_mask with respect to CRYTPO_ALG_TESTED via the CRYPTO_MSG_NEWALG crypto_user interface. As these are passed onwards to crypto_larval_lookup() unmodified as 'mask' and 'type' parameters eventually, this can lead to the creation of obscure lookup larvals like e.g. (mask & CRYTPO_ALG_TESTED) but not (type & CRYTPO_ALG_TESTED) or the other way around. Userspace should have no business in asking for untested algorithms. Make crypto_user's crypto_add_alg() reject nonsensical combinations of ->cru_type and ->cru_mask with respect to CRYTPO_ALG_TESTED with -EINVAL. Note that CRYTPO_ALG_TESTED not being set in either of mask and type is considered equivalent to that flag being set in both and these two combinations are the only ones supported as of now. Signed-off-by: Nicolai Stange --- crypto/crypto_user_base.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/crypto/crypto_user_base.c b/crypto/crypto_user_base.c index 3fa20f12989f..a9c06cd98a8c 100644 --- a/crypto/crypto_user_base.c +++ b/crypto/crypto_user_base.c @@ -352,6 +352,9 @@ static int crypto_add_alg(struct sk_buff *skb, struct nlmsghdr *nlh, if (priority && !exact) return -EINVAL; + if ((p->cru_type ^ p->cru_mask) & CRYPTO_ALG_TESTED) + return -EINVAL; + alg = crypto_alg_match(p, exact); if (alg) { crypto_mod_put(alg); From patchwork Sun Oct 3 18:14:08 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532981 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53996C433EF for ; Sun, 3 Oct 2021 18:15:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36AF861A0A for ; Sun, 3 Oct 2021 18:15:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231354AbhJCSRA (ORCPT ); Sun, 3 Oct 2021 14:17:00 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50830 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231462AbhJCSQ7 (ORCPT ); Sun, 3 Oct 2021 14:16:59 -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 12CD92218C; Sun, 3 Oct 2021 18:15:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284911; 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=iH2JsL7W0xFKKIPPGaOXY8EOQcn93ljDlGisHT9c2fU=; b=LE2B/ax5Jrt6VMxT4z7VrQN2dEWSIOffeumzR30X8ppJhW4Cw6Mq+Bi9TT1qVRIffTzRD8 5um3UEUWndbhFxKlCBrMXVKBLNHVY3l1g5xFgEI0nWJ0Bp3ZFh4Jx+UlTK0HjdGUjFxY/W WJbB/0Saqk8lzDbMQd+asewoViud59Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284911; 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=iH2JsL7W0xFKKIPPGaOXY8EOQcn93ljDlGisHT9c2fU=; b=r3Nv3qg+c+kaifURTfwv4KCKuNOLXnj3PrQPlusz/HxPetTY2kRD3UibonraDd7raGqFjU MHMVBMTxx7H3rVDw== 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 F3AC213A09; Sun, 3 Oct 2021 18:15:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id f44ZOi7zWWGtEwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:10 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?St?= =?utf-8?q?ephan_M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 3/8] crypto: api - only support lookups for specific CRYPTO_ALG_TESTED status Date: Sun, 3 Oct 2021 20:14:08 +0200 Message-Id: <20211003181413.12465-4-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Commit ff753308d2f7 ("crypto: api - crypto_alg_mod_lookup either tested or untested") introduced support to crypto_alg_lookup() for ignoring the CRYPTO_ALG_TESTED status in the search. According to the patch description, this had been needed at the time for "constructing givcipher and aead". Callers of crypto_alg_lookup() would enable this behaviour by the special combination of setting CRYPTO_ALG_TESTED in type only, but not in mask. However, the last user invoking this functionality has been gone with commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level givcipher interface"). With the previous two patches making the userspace facing APIs to validate the mask and type values passed in, the combination of (type & CRYPTO_ALG_TESTED), but !(mask & CRYPTO_ALG_TESTED) is not possible in crypto_alg_lookup() anymore. In preparation for subsequent patches, make this explicit by effectively applying what is a revert of commit ff753308d2f7 ("crypto: api - crypto_alg_mod_lookup either tested or untested") and adding a corresponding WARN_ON_ONCE() to crypto_alg_mod_lookup(). There is no change in behaviour. Note that it is now guaranteed that the first __crypto_alg_lookup() invocation from crypto_alg_mod_lookup() will always have CRYPTO_ALG_TESTED in the mask passed in, which will be needed for a subsequent patch enforcing the same for lookup larvals. Signed-off-by: Nicolai Stange --- crypto/api.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/crypto/api.c b/crypto/api.c index ee5991fe11f8..5cced204b6b4 100644 --- a/crypto/api.c +++ b/crypto/api.c @@ -239,8 +239,10 @@ static struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, struct crypto_alg *alg; u32 test = 0; - if (!((type | mask) & CRYPTO_ALG_TESTED)) + if (!(mask & CRYPTO_ALG_TESTED)) { + WARN_ON_ONCE(type & CRYPTO_ALG_TESTED); test |= CRYPTO_ALG_TESTED; + } down_read(&crypto_alg_sem); alg = __crypto_alg_lookup(name, type | test, mask | test); From patchwork Sun Oct 3 18:14:09 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532983 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC961C433F5 for ; Sun, 3 Oct 2021 18:15:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B26B161A35 for ; Sun, 3 Oct 2021 18:15:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231549AbhJCSRF (ORCPT ); Sun, 3 Oct 2021 14:17:05 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50842 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231478AbhJCSRB (ORCPT ); Sun, 3 Oct 2021 14:17:01 -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 7732722188; Sun, 3 Oct 2021 18:15:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284912; 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=C4It3Crvsgci8LL9uk9/4Ibxe6/puzhSaqOGEO6h/s8=; b=py82Nf+CmigVKZ/7tXtyptQnN6/QyQFXbr5+TnsFAopI8L0K4CxqZlyu6h6lOSBwQa8OnO y/+NDjgfQMmvXPPMcR+M85uR8it7hHJKifjBcbwYv8dBlVLSHRe1Guhv2rOWaDgO8I1U+u HYAb+06ExUPObO7+iiH7qmeT+D2fZuI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284912; 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=C4It3Crvsgci8LL9uk9/4Ibxe6/puzhSaqOGEO6h/s8=; b=MPqTk80oaHSZYBrL7XGcgmQ0Y0tXtrMcKCyxT6cmA1B5C2zVqj1DmF7uXdzQUOXZ9wrSnc XlR360KtHnULIjDw== 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 6362D13A09; Sun, 3 Oct 2021 18:15:12 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id tmjYFjDzWWG1EwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:12 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?St?= =?utf-8?q?ephan_M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 4/8] crypto: api - don't add larvals for !(type & CRYPTO_ALG_TESTED) lookups Date: Sun, 3 Oct 2021 20:14:09 +0200 Message-Id: <20211003181413.12465-5-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org As of now, the only valid (and existent) usecase for requesting an algorithm with !(type & CRYPTO_ALG_TESTED) and (mask & CRYPTO_ALG_TESTED) via crypto_alg_mod_lookup() is the testmgr invoked upon a CRYPTO_MSG_ALG_REGISTER notification. However, in this case it is expected and required that the lookup returns the actual crypto_alg instance subject to testing. If OTOH we were to assume for a moment that the crypto_larval_lookup() called from crypto_alg_mod_lookup() would allocate and return a lookup larval (which cannot happen, except for perhaps in some corner case like with concurrent crypto_alg unregistrations), the subsequent wait in crypto_alg_mod_lookup() would timeout anyway. Make crypto_larval_wait() skip the lookup larval allocation if the specified values of mask and type indicate a lookup request for some crypto_alg instance still not in CRYPTO_ALG_TESTED state and the search for such one failed. Instead, fail the call with -ENOENT in this case. This reduces the number of possible ->mask and ->type configurations with respect to CRYPTO_ALG_TESTED for pending lookup larvals and will enable further cleanup with subsequent patches. There is no change in functionality. Signed-off-by: Nicolai Stange --- crypto/api.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/crypto/api.c b/crypto/api.c index 5cced204b6b4..3bee52d7fe4b 100644 --- a/crypto/api.c +++ b/crypto/api.c @@ -283,8 +283,22 @@ static struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, if (!IS_ERR_OR_NULL(alg) && crypto_is_larval(alg)) alg = crypto_larval_wait(alg); - else if (!alg) - alg = crypto_larval_add(name, type, mask); + else if (!alg) { + /* + * Only add a lookup larval if the request is for a + * tested algorithm, everything else makes no sense. + */ + bool tested = type & mask & CRYPTO_ALG_TESTED; + + if (!(mask & CRYPTO_ALG_TESTED)) { + WARN_ON_ONCE((type & CRYPTO_ALG_TESTED)); + tested = true; + } + if (tested) + alg = crypto_larval_add(name, type, mask); + else + alg = ERR_PTR(-ENOENT); + } return alg; } From patchwork Sun Oct 3 18:14:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532985 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79616C433EF for ; Sun, 3 Oct 2021 18:15:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 605BC61A35 for ; Sun, 3 Oct 2021 18:15:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231562AbhJCSRG (ORCPT ); Sun, 3 Oct 2021 14:17:06 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50862 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231491AbhJCSRC (ORCPT ); Sun, 3 Oct 2021 14:17:02 -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 F31972218D; Sun, 3 Oct 2021 18:15:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284913; 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=Qhv2+vYlcI291SP2REKJE8w2xNUeOIz7+A3x97DTCJ8=; b=td0yrrgpOvz6tM0QZn3YFHnrLbs6qJ2M8KFDQd/VKgdWUEWdOZA/5e41flNFwaBikLVAZS t4XAoFGMSP/RtIjO0CcrQikrI6I5CkyPIW+sGbN24cluXLqtcpMF6u8oUCQE26oGvmzXKh ROvQ/7bGTn1Cphj4bxHAISPxYV4AaMY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284914; 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=Qhv2+vYlcI291SP2REKJE8w2xNUeOIz7+A3x97DTCJ8=; b=YPu2vygvSsTSZTbpGkXqme/+693hKeqiN58BdjVv/IXfp7mgH4L1e2AurnlpSBx+HVRQm5 8G0NEqvyJpxxZvBA== 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 DE87913A09; Sun, 3 Oct 2021 18:15:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id HSXKNDHzWWG7EwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:13 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?St?= =?utf-8?q?ephan_M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 5/8] crypto: api - always set CRYPTO_ALG_TESTED in lookup larvals' ->mask/type Date: Sun, 3 Oct 2021 20:14:10 +0200 Message-Id: <20211003181413.12465-6-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org For crypto_alg_lookup(), the input parameter combination of mask and type where both have CRYPTO_ALG_TESTED unset is special in that it is supposed to be handled as if said flag had been set in both for convenience. However, the code in crypto_alg_lookup() is not equivalent between these two cases: - If CRYPTO_ALG_TESTED is unset in both type and mask, a pending lookup larval with or without ->CRYPTO_ALG_TESTED being set in its ->mask and ->type can potentially get returned, whereas if CRYPTO_ALG_TESTED is set in both, only the former is possible. - If CRYPTO_ALG_TESTED is unset in both type and mask, an error would get returned if there was one or more matching algorithms which all had failed their selftests. If OTOH CRYPTO_ALG_TESTED had been set in both type and mask, NULL would get returned in this case of universal failure and the caller would proceed to re-request the algorithm in question, which is not desired. Even though the first issue is only a cosmetic one and does not affect functionality in any way AFAICT, addressing it with this patch here will improve consistency and allow for streamlining crypto_alg_lookup() a bit later in this series. The second item in the list from above will be left to a later patch. Remember that crypto_larval_lookup() will only invoke crypto_larval_add() if CRYPTO_ALG_TESTED has been set in either none or both of mask and type. Make crypto_larval_lookup() always set CRYPTO_ALG_TESTED for the mask and type values passed to crypto_larval_add(). That is, the "issue" described above is being addressed by sticking to a canonical lookup larval representation for the two equivalent cases. There is no change in functionality. Signed-off-by: Nicolai Stange --- crypto/api.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/crypto/api.c b/crypto/api.c index 3bee52d7fe4b..71406f486c65 100644 --- a/crypto/api.c +++ b/crypto/api.c @@ -284,17 +284,17 @@ static struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, if (!IS_ERR_OR_NULL(alg) && crypto_is_larval(alg)) alg = crypto_larval_wait(alg); else if (!alg) { + if (!(mask & CRYPTO_ALG_TESTED)) { + WARN_ON_ONCE((type & CRYPTO_ALG_TESTED)); + mask |= CRYPTO_ALG_TESTED; + type |= CRYPTO_ALG_TESTED; + } + /* * Only add a lookup larval if the request is for a * tested algorithm, everything else makes no sense. */ - bool tested = type & mask & CRYPTO_ALG_TESTED; - - if (!(mask & CRYPTO_ALG_TESTED)) { - WARN_ON_ONCE((type & CRYPTO_ALG_TESTED)); - tested = true; - } - if (tested) + if (type & CRYPTO_ALG_TESTED) alg = crypto_larval_add(name, type, mask); else alg = ERR_PTR(-ENOENT); From patchwork Sun Oct 3 18:14:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532987 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DD34C433EF for ; Sun, 3 Oct 2021 18:15:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8976561A6E for ; Sun, 3 Oct 2021 18:15:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231613AbhJCSRM (ORCPT ); Sun, 3 Oct 2021 14:17:12 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50878 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231536AbhJCSRF (ORCPT ); Sun, 3 Oct 2021 14:17:05 -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 E52332218C; Sun, 3 Oct 2021 18:15:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284916; 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=IXz0rPGeOFNXSRerxqWOPo9hzzsKQyz3winrnMFJ2Rg=; b=d0dzHAL81ueM4f/4EVo6rojUNoknlq1KAHTX+3mKf6mo9LWiIoMpdE3dRTZHJYfIitLkpO 8WdlUZIRcSnzXWsLvmvqNHSGvMoet2lr+CfnPofVt5BafPWofeUTIul80cax2+Zzd1tC7K 7Zx2/qQFZSDAVz8kY2fEMESjN6Qq7FI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284916; 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=IXz0rPGeOFNXSRerxqWOPo9hzzsKQyz3winrnMFJ2Rg=; b=ZF5iAmKmWHML9wbWsLFlFS8C7ubFBWOR2izVMaoPBEgHAnxKAi7ebOQAsAIl2cx5H1bQEv Bubg3h91CQIEdkDg== 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 D048713A09; Sun, 3 Oct 2021 18:15:16 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id vnrpMTTzWWHDEwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:16 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?St?= =?utf-8?q?ephan_M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 6/8] crypto: api - make crypto_alg_lookup() consistently check for failed algos Date: Sun, 3 Oct 2021 20:14:11 +0200 Message-Id: <20211003181413.12465-7-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org For convenience, input parameters to crypto_alg_lookup() where !(mask & CRYPTO_ALG_TESTED) holds are supposed to be equivalent to those having CRYPTO_ALG_TESTED set in both type and mask. However the crypto_alg_lookup() code does not behave equivalently in these two cases, in particular not in regard to the additional check for failed algorithms introduced with commit eb02c38f0197 ("crypto: api - Keep failed instances alive"). That is, if the user had explicitly set CRYPTO_ALG_TESTED in mask, the additional check for failed algorithms would never get to run. Make crypto_alg_lookup() behave the same for parameter sets considered equivalent. Note that with the current code, the first invocation of __crypto_alg_lookup() from crypto_alg_lookup() always receives a mask with CRYPTO_ALG_TESTED being set: either because that flag had been set from the beginning or because the local variable 'test' has been set to CRYPTO_ALG_TESTED otherwise. As lookup larvals always have CRYPTO_ALG_TESTED included in their ->mask by now, the first __crypto_alg_lookup() is guaranteed to find such lookup larvals. In particular, the second call of __crypto_alg_lookup(), which used to get invoked with a mask having CRYPTO_ALG_TESTED clear, is not needed anymore for matching any existing lookup larvals and, in fact, won't find any. In this context, also c.f. commit b346e492d712 ("crypto: api - fix finding algorithm currently being tested"). Moreover, because testing larvals have CRYPTO_ALG_TESTED set in their ->type, the first __crypto_alg_lookup() is and always has been able to find those, for any suitable initial combination of mask and value. In summary, - the second __crypto_alg_lookup() won't ever return a larval by now and - invoking it with the original values of mask and value, i.e. those specified by the user at function entry, is not needed anymore. As it currently stands, the only purpose of that second __crypto_alg_lookup() invocation is to check whether all matching algorithms, if any, have failed their selftests. This allows for the elimination of the local 'test' variable and some minor code simplification in crypto_alg_lookup(). More specifically, rather than keeping track of whether or not CRYPTO_ALG_TESTED had initially been set via said local 'test', simply set CRYPTO_ALG_TESTED in both mask and type at function entry if it had initially been unset in mask. That is, enforce equivalent behaviour for parameter sets considered equivalent. Adapt the if-condition guarding that second __crypto_alg_lookup() invocation as well as the invocation itself accordingly: the search is to be conducted only in the common case of the user asking for tested algorithms and it should watch out for failed algorithms, i.e. those crypto_alg instances having CRYPTO_ALG_TESTED clear in their ->type. Signed-off-by: Nicolai Stange --- crypto/api.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/crypto/api.c b/crypto/api.c index 71406f486c65..b96b65b3d5c7 100644 --- a/crypto/api.c +++ b/crypto/api.c @@ -237,18 +237,24 @@ static struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask) { struct crypto_alg *alg; - u32 test = 0; if (!(mask & CRYPTO_ALG_TESTED)) { WARN_ON_ONCE(type & CRYPTO_ALG_TESTED); - test |= CRYPTO_ALG_TESTED; + mask |= CRYPTO_ALG_TESTED; + type |= CRYPTO_ALG_TESTED; } down_read(&crypto_alg_sem); - alg = __crypto_alg_lookup(name, type | test, mask | test); - if (!alg && test) { + alg = __crypto_alg_lookup(name, type, mask); + if (!alg && (type & CRYPTO_ALG_TESTED)) { + /* + * Check whether there's an instance which failed the + * selftests in order to avoid pointless retries. + */ + type &= ~CRYPTO_ALG_TESTED; alg = __crypto_alg_lookup(name, type, mask); - if (alg && !crypto_is_larval(alg)) { + WARN_ON_ONCE(alg && crypto_is_larval(alg)); + if (alg) { /* Test failed */ crypto_mod_put(alg); alg = ERR_PTR(-ELIBBAD); From patchwork Sun Oct 3 18:14:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532989 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C92F9C433EF for ; Sun, 3 Oct 2021 18:15:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B26BA61A0C for ; Sun, 3 Oct 2021 18:15:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231653AbhJCSRQ (ORCPT ); Sun, 3 Oct 2021 14:17:16 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:38432 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231558AbhJCSRH (ORCPT ); Sun, 3 Oct 2021 14:17:07 -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-out2.suse.de (Postfix) with ESMTPS id A6F961FFB6; Sun, 3 Oct 2021 18:15:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1633284918; 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=1SyehLyUF0k4CXVaaOscaGHRcLN40Oiw8DIwqmaEfZk=; b=N0R4Izri/hZyt0I25gbBFPKSsrkipJloNSHydGQJ2cPbz1owODQkq7pmo2FUS1JfcPQRz0 e/aEf3LY2LqHATq54O9+XH0/TIvFv0YSIa5rdih/SlzQXQC0l6D9/0U+YS0BLnbTMzQshw bf4ao4WpIVDfktVx3Ghp9FWZsqLNtp4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1633284918; 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=1SyehLyUF0k4CXVaaOscaGHRcLN40Oiw8DIwqmaEfZk=; b=T11BUxDuyE6HuxzrEg7aPf5kXztCyVf3waTtowb2ns7ARNnrbQ1NtR9AOiq91Jpp8PfQk/ OGtsuLE8YV/Bz6Cw== 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 9129613A09; Sun, 3 Oct 2021 18:15:18 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id inMqIjbzWWHHEwAAMHmgww (envelope-from ); Sun, 03 Oct 2021 18:15:18 +0000 From: Nicolai Stange To: Herbert Xu , "David S. Miller" Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?q?St?= =?utf-8?q?ephan_M=C3=BCller?= , Torsten Duwe , Nicolai Stange Subject: [PATCH 7/8] crypto: api - lift common mask + type adjustment to crypto_larval_lookup() Date: Sun, 3 Oct 2021 20:14:12 +0200 Message-Id: <20211003181413.12465-8-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Both crypto_larval_lookup() as well as the crypto_alg_lookup() called therefrom (and only therefrom) will apply the very same adjustments to their mask and type parameters if the original mask value is found to not have CRYPTO_ALG_TESTED set. There is no point in having the code duplicated, do it once near the entry of crypto_larval_lookup(). There is no change in behaviour. Signed-off-by: Nicolai Stange --- crypto/api.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/crypto/api.c b/crypto/api.c index b96b65b3d5c7..594c494a27d9 100644 --- a/crypto/api.c +++ b/crypto/api.c @@ -238,12 +238,6 @@ static struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, { struct crypto_alg *alg; - if (!(mask & CRYPTO_ALG_TESTED)) { - WARN_ON_ONCE(type & CRYPTO_ALG_TESTED); - mask |= CRYPTO_ALG_TESTED; - type |= CRYPTO_ALG_TESTED; - } - down_read(&crypto_alg_sem); alg = __crypto_alg_lookup(name, type, mask); if (!alg && (type & CRYPTO_ALG_TESTED)) { @@ -276,6 +270,12 @@ static struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, type &= ~(CRYPTO_ALG_LARVAL | CRYPTO_ALG_DEAD); mask &= ~(CRYPTO_ALG_LARVAL | CRYPTO_ALG_DEAD); + if (!(mask & CRYPTO_ALG_TESTED)) { + WARN_ON_ONCE(type & CRYPTO_ALG_TESTED); + mask |= CRYPTO_ALG_TESTED; + type |= CRYPTO_ALG_TESTED; + } + alg = crypto_alg_lookup(name, type, mask); if (!alg && !(mask & CRYPTO_NOLOAD)) { request_module("crypto-%s", name); @@ -290,12 +290,6 @@ static struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, if (!IS_ERR_OR_NULL(alg) && crypto_is_larval(alg)) alg = crypto_larval_wait(alg); else if (!alg) { - if (!(mask & CRYPTO_ALG_TESTED)) { - WARN_ON_ONCE((type & CRYPTO_ALG_TESTED)); - mask |= CRYPTO_ALG_TESTED; - type |= CRYPTO_ALG_TESTED; - } - /* * Only add a lookup larval if the request is for a * tested algorithm, everything else makes no sense. From patchwork Sun Oct 3 18:14:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 12532991 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1AF2C433EF for ; Sun, 3 Oct 2021 18:15:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A4C461A58 for ; Sun, 3 Oct 2021 18:15:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231575AbhJCSR0 (ORCPT ); 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?St?= =?utf-8?q?ephan_M=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 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;