On Tue, Oct 13, 2020 at 9:40 PM GitLab Bridge on behalf of jeremycline
<cki-gitlab(a)redhat.com> wrote:
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
Hi,
As part of the ongoing rebase effort, the following configuration
options need to be reviewed.
As a reminder, the ARK configuration flow involves moving unreviewed
configuration options from the pending directory to the ark directory.
In the diff below, options are removed from the pending directory and
added to the ark hierarchy. The final options that need to be ACKed
are the files that are being added to the ark hierarchy.
If the value for a file that is added should be changed, please reply
with a better option.
CONFIG_CRYPTO_SM2:
Generic implementation of the SM2 public key algorithm. It was
published by State Encryption Management Bureau, China.
as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012.
References:
https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02
http://www.oscca.gov.cn/sca/xxgk/2010-12/17/content_1002386.shtml
http://www.gmbz.org.cn/main/bzlb.html
Symbol: CRYPTO_SM2 [=n]
Type : tristate
Defined at crypto/Kconfig:263
Prompt: SM2 algorithm
Depends on: CRYPTO [=y]
Location:
-> Cryptographic API (CRYPTO [=y])
Selects: CRYPTO_SM3 [=n] && CRYPTO_AKCIPHER [=y] && CRYPTO_MANAGER [=y]
&& MPILIB [=y] && ASN1 [=y]
Looking at the current state of SM* configs in ARK, there seems to be
some disconnect:
ark/generic/CONFIG_CRYPTO_SM3:# CONFIG_CRYPTO_SM3 is not set
ark/generic/CONFIG_CRYPTO_SM3_ARM64_CE:CONFIG_CRYPTO_SM3_ARM64_CE=m
ark/generic/CONFIG_CRYPTO_SM4:# CONFIG_CRYPTO_SM4 is not set
ark/generic/CONFIG_CRYPTO_SM4_ARM64_CE:CONFIG_CRYPTO_SM4_ARM64_CE=m
ark/generic/arm/aarch64/CONFIG_CRYPTO_SM3_ARM64_CE:#
CONFIG_CRYPTO_SM3_ARM64_CE is not set
ark/generic/arm/aarch64/CONFIG_CRYPTO_SM4:CONFIG_CRYPTO_SM4=m
Why is CONFIG_CRYPTO_SM4 enabled only on aarch64? Why is
CONFIG_CRYPTO_SM3_ARM64_CE enabled, but CONFIG_CRYPTO_SM3 is not?
These should be consolidated.
Herbert, what is your opinion? I guess we would like to have the
Chinese algorithms enabled on ARK/RHEL? It seems very likely that some
Chinese customers would want them.
---
CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE:
Allow obsolete cryptographic algorithms to be selected that have
already been phased out from internal use by the kernel, and are
only useful for userspace clients that still rely on them.
Symbol: CRYPTO_USER_API_ENABLE_OBSOLETE [=y]
Type : bool
Defined at crypto/Kconfig:1915
Prompt: Enable obsolete cryptographic algorithms for userspace
Depends on: CRYPTO [=y] && CRYPTO_USER_API [=y]
Location:
-> Cryptographic API (CRYPTO [=y])
I'd be inclined to recommend disabling this (and the 4 corresponding
configs - see [1]) in both Fedora and ARK. These somewhat obscure
algorithms have no in-kernel users and it is very unlikely that they
would be used from userspace (via dm-crypt/AF_ALG). Opinions?
[1]
https://lore.kernel.org/linux-crypto/20200911141103.14832-1-ardb@kernel.org/
---
CONFIG_CRYPTO_USER_API_RNG_CAVP:
This option enables extra API for CAVP testing via the user-space
interface: resetting of DRBG entropy, and providing Additional Data.
This should only be enabled for CAVP testing. You should say
no unless you know what this is.
Symbol: CRYPTO_USER_API_RNG_CAVP [=n]
Type : bool
Defined at crypto/Kconfig:1895
Prompt: Enable CAVP testing of DRBG
Depends on: CRYPTO [=y] && CRYPTO_USER_API_RNG [=y] && CRYPTO_DRBG
[=y]
Location:
-> Cryptographic API (CRYPTO [=y])
-> User-space interface for random number generator algorithms
(CRYPTO_USER_API_RNG [=y])
I don't know if this would be useful for some certification on RHEL,
but probably can be left disabled.
(My 2 cents...)
--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.