From patchwork Fri Apr 16 16:06:41 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 423503 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC36DC433ED for ; Fri, 16 Apr 2021 16:06:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAE52610CE for ; Fri, 16 Apr 2021 16:06:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239658AbhDPQHT (ORCPT ); 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 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" From patchwork Fri Apr 16 16:06:42 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 422764 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6243C433ED for ; Fri, 16 Apr 2021 16:06:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BA8B8611C2 for ; Fri, 16 Apr 2021 16:06:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239767AbhDPQHV (ORCPT ); Fri, 16 Apr 2021 12:07:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:37438 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239183AbhDPQHU (ORCPT ); Fri, 16 Apr 2021 12:07:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 24F9C6113D; Fri, 16 Apr 2021 16:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618589215; bh=rTkLI/G7keGXQVgDyrI7UE8GeDTwoxdlSggyy76+H4g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y6gVbgDxaz/ZztWn7rWw5DW6/Swqkno/dGBQ0fhO3aHMiuaY/kd/YOVkyCU4suAio fm6sZKg1DezRKaqo0OSX/WYpxo4nvopfoUd5t9BMaL34lQBU3EJy1bXzwRWPUJPnef 0xZ351NAknAzONLoPA/txYI2w2KytoQZ5W5WzMdHi+aph0HIuQZhAhpVdA0Y5JRos5 7LKTuoufSK7STg44rpcrOViMO67VolqQLpXli9poWOgm5FFrWeGlCV0PF+TqcsDfIT Uak50ip4IVV1EorGmBMESs02rndc2AnTQfIXAxWcgWPXIuRXSBe4W/Tu7wffRi2zUK Iihedt1/QqAEg== 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 2/2] fsverity: relax build time dependency on CRYPTO_SHA256 Date: Fri, 16 Apr 2021 18:06:42 +0200 Message-Id: <20210416160642.85387-3-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 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org CONFIG_CRYPTO_SHA256 denotes the generic C implementation of the SHA-256 shash algorithm, which is selected as the default crypto shash provider for fsverity. However, fsverity has no strict link time dependency, and the same shash could be exposed by an optimized implementation, and arm64 has a number of those (scalar, NEON-based and one based on special crypto instructions). In such cases, it makes little sense to require that the generic C implementation is incorporated as well, given that it will never be called. To address this, relax the 'select' clause to 'imply' so that the generic driver can be omitted from the build if desired. Signed-off-by: Ard Biesheuvel Acked-by: Eric Biggers --- fs/verity/Kconfig | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/verity/Kconfig b/fs/verity/Kconfig index 88fb25119899..24d1b54de807 100644 --- a/fs/verity/Kconfig +++ b/fs/verity/Kconfig @@ -3,9 +3,13 @@ config FS_VERITY bool "FS Verity (read-only file-based authenticity protection)" select CRYPTO - # SHA-256 is selected as it's intended to be the default hash algorithm. + # SHA-256 is implied as it's intended to be the default hash algorithm. # To avoid bloat, other wanted algorithms must be selected explicitly. - select CRYPTO_SHA256 + # Note that CRYPTO_SHA256 denotes the generic C implementation, but + # some architectures provided optimized implementations of the same + # algorithm that may be used instead. In this case, CRYPTO_SHA256 may + # be omitted even if SHA-256 is being used. + imply CRYPTO_SHA256 help This option enables fs-verity. fs-verity is the dm-verity mechanism implemented at the file level. On supported