On Tue, Oct 13, 2020 at 9:40 PM GitLab Bridge on behalf of jeremycline <cki-gitlab@xxxxxxxxxx> wrote: > From: Fedora Kernel Team <kernel-team@xxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxx/ > > --- > > 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. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
