Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp450709pxb; Fri, 16 Apr 2021 09:25:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwG0veqUBxdYz2MHVL0Yhp698ezYUVLnyTQNGV8+zcL8Eaf+ujAzEhLEMb4Fx5Z9z3StA4a X-Received: by 2002:a17:907:ea7:: with SMTP id ho39mr2477889ejc.315.1618590339619; Fri, 16 Apr 2021 09:25:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618590339; cv=none; d=google.com; s=arc-20160816; b=pFU8YI4jmVk403HPa/yUpzxPbi6AWJkzlzFLv6MKbqNPyZaIhDb0KP30b2oTpE/qR+ XBfUvlAFJP6fL2STyXvEK/CTAZKQSGQ7Rw71UQNEfRBTV/7E/LByPyTJ3+PR7CCfZlZb sqYrWFhh71sQc8EwuGSsRigfu1Slz79uIc279uvjCqIstaMxJvnkHE0MBoDgGR1lGp2M 11wnwQuF+4WLNhhno9n5U7zipiMAqr1TUCOaxk3YoRdB6rgxVPMqTfgHyHPedOMni5Jb 8VmOTnFGJEUqJIsFSymAjLZWRKOPMqFWpXaj5sREqL5KJaka8lNDqnz39m2X5ox55nzE 5J+Q== 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; bh=Gsnw9zZoryN6zMekfGO8oImWcGwtKHYT+qsW23WtL44=; b=FHZ7uVroMtJLoeCUDinRGGQ8VlF17vgqazAvizewt22jWUga0uM2Qg1EljudufVlR3 ypmILgBV8yWwBRVedQx9JDVZPZwF8U0mGJmw6dLq0aQUt2q8900zjRHV418nHp4bhN7x VJTq6vaSA4fMo4mL+RPhNlz7vHf5oShhIPZYWGRJyTsK40KtYaDKYyuNx30Qh+CNtb4v 4gryCkyo3muKzWoq6xg/dkpBg6xocAUYfv5mZwIGqrCKxun7mW8nzEBd6kllJI1vGINg rQTxJm3Yrq0NGgi05waG7ATtrLVaSmcwvnN3OCH/my+nU7Qggo9hvyYQp6O3W9h7zxor 1Hbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=GOhJfHCT; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz11si4755347ejc.257.2021.04.16.09.25.12; Fri, 16 Apr 2021 09:25:39 -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=@kernel.org header.s=k20201202 header.b=GOhJfHCT; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239658AbhDPQHT (ORCPT + 99 others); Fri, 16 Apr 2021 12:07:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:37408 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239183AbhDPQHS (ORCPT ); Fri, 16 Apr 2021 12:07:18 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 050AD613B0; Fri, 16 Apr 2021 16:06:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618589213; bh=BuDdLNq+a5myEjWt3+SxtbuydJd0suwiIyzOBikPkl0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GOhJfHCTtCe99iZ3wPALnl12b6A/uZm/nNGox6+085bkTyCIxbYK38XjtHoLayGmn /ubPHCRi925fzGb/Jb6xrL0j1WsfEs7KDrqCtuCVwRJnJnspKq85v42djSkq3GlwQ/ 6q1ydHfTYbiSYGaz5w97F+muhyOF7BQjdTfhPc27b36dEk9MBtNhrWiLqfuCAQI3p8 yUZy1sN4ZY2MMl1fd71CZ43AtFdIILDmpQTQG2Wayr2kfA5IZIKtx1+xXiBPgwydNw P4g9bvhbdCe+M695HuC9yxmtfOJ9FUOsP44dHLxYKx4+2ikFFXAgcPkOJbxIaLs4xy 68wLOJBSosJSg== From: Ard Biesheuvel To: linux-crypto@vger.kernel.org Cc: linux-fscrypt@vger.kernel.org, Ard Biesheuvel , "Theodore Y. Ts'o" , Jaegeuk Kim , Eric Biggers Subject: [PATCH 1/2] fscrypt: relax Kconfig dependencies for crypto API algorithms Date: Fri, 16 Apr 2021 18:06:41 +0200 Message-Id: <20210416160642.85387-2-ardb@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210416160642.85387-1-ardb@kernel.org> References: <20210416160642.85387-1-ardb@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Even if FS encryption has strict functional dependencies on various crypto algorithms and chaining modes. those dependencies could potentially be satisified by other implementations than the generic ones, and no link time dependency exists on the 'depends on' claused defined by CONFIG_FS_ENCRYPTION_ALGS. So let's relax these clauses to 'imply', so that the default behavior is still to pull in those generic algorithms, but in a way that permits them to be disabled again in Kconfig. Signed-off-by: Ard Biesheuvel --- fs/crypto/Kconfig | 23 ++++++++++++++------ 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig index a5f5c30368a2..1e6c11de95c8 100644 --- a/fs/crypto/Kconfig +++ b/fs/crypto/Kconfig @@ -17,13 +17,22 @@ config FS_ENCRYPTION # allows the algorithms to be built as modules when all the filesystems are. config FS_ENCRYPTION_ALGS tristate - select CRYPTO_AES - select CRYPTO_CBC - select CRYPTO_CTS - select CRYPTO_ECB - select CRYPTO_HMAC - select CRYPTO_SHA512 - select CRYPTO_XTS + imply CRYPTO_AES + imply CRYPTO_CBC + imply CRYPTO_CTS + imply CRYPTO_ECB + imply CRYPTO_HMAC + imply CRYPTO_SHA512 + imply CRYPTO_XTS + help + This pulls in the generic implementations of the various + cryptographic algorithms and chaining modes that filesystem + encryption relies on. These are 'soft' dependencies only, as + architectures may supersede these generic implementations with + special, optimized ones. + + If unsure, keep the generic algorithms enabled, as they can + happily co-exist with per-architecture implementations. config FS_ENCRYPTION_INLINE_CRYPT bool "Enable fscrypt to use inline crypto" -- 2.30.2