[PATCH 1/2] lib: optee: remove the duplicate CONFIG_OPTEE
Patrick DELAUNAY
patrick.delaunay at foss.st.com
Mon Sep 6 18:53:08 CEST 2021
Hi,
On 9/4/21 10:31 AM, Etienne Carriere wrote:
> Hello Alex and Patrick,
>
> (my apologies for my previous malformed post)
>
>
> On Fri, 3 Sept 2021 at 18:43, Alex G. <mr.nuke.me at gmail.com> wrote:
>> Hi Patrick
>>
>> On 9/2/21 4:56 AM, Patrick Delaunay wrote:
>>> The configuration CONFIG_OPTEE is defined 2 times:
>>> 1- in lib/optee/Kconfig for support of OPTEE images loaded by bootm command
>>> 2- in drivers/tee/optee/Kconfig for support of OP-TEE driver.
>>>
>>> It is abnormal to have the same CONFIG define for 2 purpose;
>>> and it is difficult to managed correctly their dependencies.
> +1
>
>>> Moreover CONFIG_SPL_OPTEE is defined in common/spl/Kconfig
>>> to manage OPTEE image load in SPL.
>>>
>>> This definition causes an issue with the macro CONFIG_IS_ENABLED(OPTEE)
>>> to test the availability of the OP-TEE driver.
>>>
>>> This patch cleans the configuration dependency with:
>>> - CONFIG_OPTEE_IMAGE (renamed) => support of OP-TEE image in U-Boot
>>> - CONFIG_SPL_OPTEE_IMAGE (renamed) => support of OP-TEE image in SPL
>>> - CONFIG_OPTEE (same) => support of OP-TEE driver in U-Boot
>>> - CONFIG_OPTEE_LIB (new) => support of OP-TEE library
>>>
>>> After this patch, the macro have the correct behavior:
>>> - CONFIG_IS_ENABLED(OPTEE_IMAGE) => Load of OP-TEE image is supported
>>> - CONFIG_IS_ENABLED(OPTEE) => OP-TEE driver is supported
>> It seems a little odd to have both OPTEE_LIB and OPTEE_IMAGE, since they
>> are both used together to support booting with OP-TEE. What also seems
>> odd is that "OP-TEE driver in U-Boot" does not depend on "OP-TEE library".
OP-TEE driver => communication with already loaded OP-TEE based on TEE
u-class
OP-TEE library => library for U-Boot helper function to use with OP-TEE
support , which allows
- to load OP-TEE image (in U-Boot proper / bootm command)
- to update Linux DT tree with OP-TEE nodes
so OP-TEE ibrary (for bootm support) can be activated without OP-TEE
driver support....
even it is strange (for me also)
The OP-TEE library is not used by OP-TEE driver
but I agree, it is odds to don't have optee_copy_firmware_node() not
depending of CONFIG_OPTEE
but I found at least one board wich enable the OP-TEE library without
CONFIG_TEE and so without OP-TEE driver
=> configs/odroid-go2_defconfig
you can see this patchset as a first step of dependancy cleanup...
for me it was the more simple migration path to avoid issue with
existing code
and more easy to review.
At my first try, I don't create CONFIG_OPTEE_LIB and CONFIG_OPTEE_IMAGE
but when I compile all the boards to check if the u-boot and SPL size change
(to be sure that this migration don't break any boards)
I have several issue in particular with the
include/configs/mx7_common.h
index 3d87690382..629b2c7c52 100644
* initialization since it was already done by ATF or OPTEE
*/
#if (CONFIG_OPTEE_TZDRAM_SIZE != 0)
#ifndef CONFIG_OPTEE
#define CONFIG_SKIP_LOWLEVEL_INIT
#endif
#endif
=> CONFIG_OPTEE_TZDRAM_SIZE can be defined and CONFIG_OPTEE not defined !?
I separate CONFIG_OPTEE_LIB and CONFIG_OPTEE_IMAGE to solve this issue....
a other issue can be see in
------------------------- configs/odroid-go2_defconfig
-------------------------
index aafec84f10..551f95f4f9 100644
@@ -95,7 +95,7 @@ CONFIG_DEBUG_UART_SHIFT=2
CONFIG_DEBUG_UART_SKIP_INIT=y
CONFIG_SOUND=y
CONFIG_SYSRESET=y
-CONFIG_OPTEE=y
+CONFIG_OPTEE_LIB=y
=> if I activate CONFIG_OPTEE_IMAGE instead of CONFIG_OPTEE_LIB the
board size increase.
>> Introducing OPTEE_LIB then, makes sense to me, provided that OPTEE
>> depends on OPTEE_LIB, but I'm not sure about OPTEE_IMAGE.
this config OPTEE_IMAGE / OPTEE_LIB also allows to don't break the
existing dependency for
- OPTEE_LOAD_ADDR
- OPTEE_TZDRAM_SIZE
- OPTEE_TZDRAM_BASE
>>
>>> diff --git a/lib/optee/optee.c b/lib/optee/optee.c
>>> index 672690dc53..5676785cb5 100644
>>> --- a/lib/optee/optee.c
>>> +++ b/lib/optee/optee.c
>>> @@ -20,6 +20,7 @@
>>> "\n\theader lo=0x%08x hi=0x%08x size=0x%08lx arch=0x%08x" \
>>> "\n\tuimage params 0x%08lx-0x%08lx\n"
>>>
>>> +#if defined(CONFIG_OPTEE_IMAGE)
>>> int optee_verify_image(struct optee_header *hdr, unsigned long tzdram_start,
>>> unsigned long tzdram_len, unsigned long image_len)
>>> {
>>> @@ -70,6 +71,7 @@ error:
>>>
>>> return ret;
>>> }
>>> +#endif
>> One the idea of having CONFIGs is to include/exclude code via
>> obj-$(CONFIG_FOO)+=code.c. This prevents the proliferation of #ifdefs.
>> It's fairly counterintuitive to have a CONFIG_OPTEE_IMAGE in a file
>> controlled by CONFIG_OPTEE_LIB.
>>
>> Going to optee_verify_image() itself. It essentially checks against
>> OPTEE_TZDRAM_(BASE/SIZE). But those are a derived from devicetree, not
>> Kconfig. So it seems the motivation behing optee_verify_bootm_image() is
>> flawed. Also the error message is not very helpful.
> The 2 functions are related to CONFIG_BOOTM_OPTEE. They could depend on.
> My 2 cents.
> If preserving the optee_verify_xxx() functions, they could move to a
> specific source lib/optee/optee_image.c
I agree for me, the next step of the migration could be to split the
optee lib to 2 files
lib/optee/optee_image.c
lib/optee/optee_fdt.c
with
lib/Makefile:
obj-$(CONFIG_OPTEE_LIB) += optee/
lib/optee/Makefile:
-obj-y += optee.o
+obj-$(CONFIG_OPTEE_IMAGE) += optee_image.o
+obj-$(CONFIG_OF_LIBFDT) += optee_fdt.o
=> I don't to it yet to after more easy review of the current patch....
but if you prefer, I can do it in v2
or the optee_copy_fdt_nodes() should be copied in drivers/tee/optee.c
(but this modification required to have the driver activated in all
boards expecting this feature)
PS: for SPL support, in future, we could manage SPL support for each
option:
obj-$(CONFIG_$(SPL_)OPTEE_LIB) += optee/
obj-$(CONFIG_$(SPL_)OPTEE_IMAGE) += optee_image.o
obj-$(CONFIG_$(SPL_)OF_LIBFDT) += optee_fdt.o
>
>> In fact, the SPL boot path for OP-TEE doesn't use this function. That's
>> intentional.
>>
>> Here's what I suggest:
>> - Remove OPTEE_TZDRAM_BASE and _SIZE
> There is some legacy here, board/warp7and board/technexion/pico-imx7d.
it is not possible, it is used for U-Boot proper on other platforms
configs/warp7_bl33_defconfig:70:CONFIG_OPTEE_TZDRAM_BASE=0x9e000000
configs/warp7_defconfig:76:CONFIG_OPTEE_TZDRAM_BASE=0x9d000000
board/warp7/warp7.c:37:#ifdef CONFIG_OPTEE_TZDRAM_SIZE
board/warp7/warp7.c:38: gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
board/warp7/warp7.c:118:#ifdef CONFIG_OPTEE_TZDRAM_SIZE
board/warp7/warp7.c:122: optee_start = optee_end -
CONFIG_OPTEE_TZDRAM_SIZE;
board/technexion/pico-imx7d/pico-imx7d.c:55:#ifdef CONFIG_OPTEE_TZDRAM_SIZE
board/technexion/pico-imx7d/pico-imx7d.c:56: gd->ram_size -=
CONFIG_OPTEE_TZDRAM_SIZE;
configs/warp7_bl33_defconfig:69:CONFIG_OPTEE_TZDRAM_SIZE=0x02000000
configs/warp7_defconfig:75:CONFIG_OPTEE_TZDRAM_SIZE=0x3000000
include/configs/mx7_common.h:52:#if (CONFIG_OPTEE_TZDRAM_SIZE != 0)
And for me this configuration (size of memory used by OPTEE) is more a
system configuration
depending of the OP-TEE firmware used than a Device Tree configuration
at SPL level
=> if the OP-TEE size change for 2 FW (OP-TEE with or wihout secure UI
for example)
on the same board, the the SPL device tree should not change....
(the kernel device tree can be hardcoded or updated by OP-TEE)
PS: for the TF-A case it is done in a secure FW configuration file => in
the FIP
this information is no hardcoded information in BL2
in SPL, the load address / entry point it is already provided by
FIT for OPTEE image
(=> optee_image_get_load_addr / optee_image_get_entry_point)
no need to have this information in DT (optee base address)
tools/default_image.c:119
if (params->os == IH_OS_TEE) {
addr = optee_image_get_load_addr(hdr);
ep = optee_image_get_entry_point(hdr);
}
for CONFIG_OPTEE_TZDRAM_SIZE, I think that can be also found by
parsing the OP-TEE header
=> see : init_mem_usage
the OPTEE should be access to this memory .....
and it can change the firewall configuration is it is necessary
for the shared memory for example
=> no need to update first stage boot loader = SPL (with the risk to
brick the device)
when only OP-TEE firmware change
> regards,
> etienne
>
>> - Remove optee_verify_bootm_image()
but it is used in
common/bootm_os.c:491: ret =
optee_verify_bootm_image(images->os.image_start,
for the use case OPTEE loaded and started by U-Boot , with bootm command
= CONFIG_OPTEE_IMAGE
(not supported by stm32mp15)
>>
>> - No need for CONFIG_OPTEE_IMAGE
>>
activate by CONFIG_BOOTM_OPTEE
activated in
configs/warp7_defconfig:77:CONFIG_BOOTM_OPTEE=y
and this option can be used to correctly handle the macro
CONFIG_IS_ENABLED(OPTEE_IMAGE) as it is expected
=> in U-Boot proper : test CONFIG_OPTEE_IMAGE
=> in SPL : test CONFIG_SPL_OPTEE_IMAGE (existing)
as it is almost the same meaning..... support of OP-TEE image load
And this marco is already used in SPL context
common/spl/spl.c:776:#if CONFIG_IS_ENABLED(OPTEE)
>>
>> Alex
Patrick
More information about the U-Boot
mailing list