linux-kernel - Re: [PATCH v6 0/3] nvmem: stm32: add OP-TEE support for STM32MP13x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Jan 2023 22:02:43 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Patrick Delaunay" <patrick.delaunay@...s.st.com>,
        "Alexandre Torgue" <alexandre.torgue@...s.st.com>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        "Maxime Coquelin" <mcoquelin.stm32@...il.com>,
        "Srinivas Kandagatla" <srinivas.kandagatla@...aro.org>
Cc:     "Etienne CARRIERE" <etienne.carriere@...aro.org>,
        "Fabrice GASNIER" <fabrice.gasnier@...s.st.com>,
        "Amelie DELAUNAY" <amelie.delaunay@...s.st.com>,
        "Lionel DEBIEVE" <lionel.debieve@...s.st.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH v6 0/3] nvmem: stm32: add OP-TEE support for STM32MP13x

On Wed, Jan 18, 2023, at 18:29, Patrick Delaunay wrote:
> 
> +config NVMEM_STM32_BSEC_OPTEE_TA
> +	bool "STM32MP BSEC OP-TEE TA support for nvmem-stm32-romem driver"
> +	depends on OPTEE
> +	help
> +	  Say y here to enable the accesses to STM32MP SoC OTPs by the OP-TEE
> +	  trusted application STM32MP BSEC.
> +
> +	  This library is a used by stm32-romem driver or included in the 
> module
> +	  called nvmem-stm32-romem.
> +
>  config NVMEM_STM32_ROMEM
>  	tristate "STMicroelectronics STM32 factory-programmed memory support"
>  	depends on ARCH_STM32 || COMPILE_TEST
> +	imply NVMEM_STM32_BSEC_OPTEE_TA
>  	help
>  	  Say y here to enable read-only access for STMicroelectronics STM32
>  	  factory-programmed memory area.

This is now causing a link failure with CONFIG_OPTEE=m if
NVMEM_STM32_ROMEM is built-in. My guess is that you saw something
like that earlier and someone recommended using the 'imply' keyword
without understanding what it does (no worries, nobody understands it).

I've prepared a patch now based on the most likely interpretation
of what you actually meant here:

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index ed8ef7460be2..ae2c5257ed97 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -295,8 +295,7 @@ config NVMEM_SPRD_EFUSE
          will be called nvmem-sprd-efuse.
 
 config NVMEM_STM32_BSEC_OPTEE_TA
-       bool "STM32MP BSEC OP-TEE TA support for nvmem-stm32-romem driver"
-       depends on OPTEE
+       def_bool NVMEM_STM32_ROMEM && OPTEE
        help
          Say y here to enable the accesses to STM32MP SoC OTPs by the OP-TEE
          trusted application STM32MP BSEC.
@@ -307,7 +306,7 @@ config NVMEM_STM32_BSEC_OPTEE_TA
 config NVMEM_STM32_ROMEM
        tristate "STMicroelectronics STM32 factory-programmed memory support"
        depends on ARCH_STM32 || COMPILE_TEST
-       imply NVMEM_STM32_BSEC_OPTEE_TA
+       depends on OPTEE || !OPTEE
        help
          Say y here to enable read-only access for STMicroelectronics STM32
          factory-programmed memory area.

This enables NVMEM_STM32_BSEC_OPTEE_TA whenever OPTEE is
available, but prevents the link error by forcing NVMEM_STM32_ROMEM
to also be a loadable module if that is how OPTEE is built.

I'll send that if it passes the randconfig builds over night.

      Arnd