core: imx: 8m phytec boards: increase CFG_DDR_SIZE

[ymoog]

PHYTEC imx8m boards have different RAM configurations, from 1 up to 8 GiB. optee_os should accept addresses up to the max possible address of the largest RAM board variant when communicating to non-secure os via shared DRAM, so CFG_DDR_SIZE is adjusted accordingly. Set CFG_TZDRAM_START explicitly now, since the goal is to support the reference optee_os with a single binary on all board variants. Thus optee_os must reside within the 1st GiB of DRAM.

[jforissier]

PHYTEC imx8m boards have different RAM configurations, from 1 up to 8 GiB. optee_os should accept addresses up to the max possible address of the largest RAM board variant when communicating to non-secure os via shared DRAM, so CFG_DDR_SIZE is adjusted accordingly.

The drawback is that it weakens validation of addresses by secure world. If NS world passes an out-of-range address, SW will crash and the system is dead. Why not pass proper memory information via DT instead?

Set CFG_TZDRAM_START explicitly now, since the goal is to support the reference optee_os with a single binary on all board variants. Thus optee_os must reside within the 1st GiB of DRAM.

[ymoog]

PHYTEC imx8m boards have different RAM configurations, from 1 up to 8 GiB. optee_os should accept addresses up to the max possible address of the largest RAM board variant when communicating to non-secure os via shared DRAM, so CFG_DDR_SIZE is adjusted accordingly.

The drawback is that it weakens validation of addresses by secure world. If NS world passes an out-of-range address, SW will crash and the system is dead. Why not pass proper memory information via DT instead?

Okay. Just to verify, we assume that there is a bad actor passing bogus addresses to SW that are out of bounds of actual physical ram address space? (assume 4GiB actual RAM, while SW thinks it only has 1GiB. After all, NS shared memory will work fine for anything within 4GiB even though SW only knows of 1GiB)

Anyway, I'll work on your suggestion since we would end up with the proper main memory size in that case.
Thanks.

Set CFG_TZDRAM_START explicitly now, since the goal is to support the reference optee_os with a single binary on all board variants. Thus optee_os must reside within the 1st GiB of DRAM.

[sahilnxp]

Hi @ymoog

From commit message, shared memory address will be in first 1GB memory, but this address is not in first 1GB of memory, please check.

[ymoog]

Hi @sahilnxp, thanks for calling that out. The phygate tauri does not exist as a 1GiB memory variant. I'll rework the commit message.

[sahilnxp]

Did you test with these changes on all 8m phytec platforms ?
Since tzc380.c is enabled on 8MM and 8MP platforms, and it takes CFG_DDR_SIZE in account while configuring the regions, I am not sure what impact this will have on TZC programming.
Can you please check this also.

[ymoog]

I tested that all boards boot and xtest runs successfully. Is there a specific test you recommend me to run or what I should check? I'll take a closer look at how tzc-380 works.

[sahilnxp]

From 8MM and 8MP reference manual, DDR addresses are aligned as shown below:

For the boards having more than, 3GB of memory, I think you need to define CFG_NSEC_DDR_1_BASE and CFG_NSEC_DDR_1_SIZE also.

[ymoog]

Forgot about that, thanks.

ifneq (,$(filter $(PLATFORM_FLAVOR),mx8mpevk))
CFG_DDR_SIZE ?= UL(0x180000000)
CFG_UART_BASE ?= UART2_BASE

Does the imx8mp evk have this problem as well, then?

[sahilnxp]

Yes imx8mp evk has same memory map like this one.

[ymoog]

PHYTEC imx8m boards have different RAM configurations, from 1 up to 8 GiB. optee_os should accept addresses up to the max possible address of the largest RAM board variant when communicating to non-secure os via shared DRAM, so CFG_DDR_SIZE is adjusted accordingly.

The drawback is that it weakens validation of addresses by secure world. If NS world passes an out-of-range address, SW will crash and the system is dead. Why not pass proper memory information via DT instead?

Hi @jforissier. I need some assistance on the dt topic.
In U-Boot spl, we read the actual memory size through rom data and could then configure/fixup the dtb. However, it is not clear to me through which mechanism this dtb is then passed to tf-a and then further to the tee.
I stumbled upon Firmware Handoff which appears to be supported by tf-a. Does optee_os and U-Boot support that, too?
Can you point me to the appropriate documentation?

Set CFG_TZDRAM_START explicitly now, since the goal is to support the reference optee_os with a single binary on all board variants. Thus optee_os must reside within the 1st GiB of DRAM.

[jforissier]

PHYTEC imx8m boards have different RAM configurations, from 1 up to 8 GiB. optee_os should accept addresses up to the max possible address of the largest RAM board variant when communicating to non-secure os via shared DRAM, so CFG_DDR_SIZE is adjusted accordingly.

The drawback is that it weakens validation of addresses by secure world. If NS world passes an out-of-range address, SW will crash and the system is dead. Why not pass proper memory information via DT instead?

Hi @jforissier. I need some assistance on the dt topic. In U-Boot spl, we read the actual memory size through rom data and could then configure/fixup the dtb. However, it is not clear to me through which mechanism this dtb is then passed to tf-a and then further to the tee. I stumbled upon Firmware Handoff which appears to be supported by tf-a. Does optee_os and U-Boot support that, too? Can you point me to the appropriate documentation?

Yes, OP-TEE and U-Boot do support Firmware Handoff. For U-Boot there is documentation at https://docs.u-boot.org/en/latest/develop/bloblist.html. For OP-TEE there is no formal documentation but you may want to check commit OP-TEE/build@0048f71dd59b which enabled Firmware Handoff in the QEMUv8 test config of OP-TEE. This configuration has TF-A, U-Boot and OP-TEE so it will hopefully be helpful. CC @raymo200915 who worked on this.

[raymo200915]

PHYTEC imx8m boards have different RAM configurations, from 1 up to 8 GiB. optee_os should accept addresses up to the max possible address of the largest RAM board variant when communicating to non-secure os via shared DRAM, so CFG_DDR_SIZE is adjusted accordingly.

The drawback is that it weakens validation of addresses by secure world. If NS world passes an out-of-range address, SW will crash and the system is dead. Why not pass proper memory information via DT instead?

Hi @jforissier. I need some assistance on the dt topic. In U-Boot spl, we read the actual memory size through rom data and could then configure/fixup the dtb. However, it is not clear to me through which mechanism this dtb is then passed to tf-a and then further to the tee. I stumbled upon Firmware Handoff which appears to be supported by tf-a. Does optee_os and U-Boot support that, too? Can you point me to the appropriate documentation?

Yes, OP-TEE and U-Boot do support Firmware Handoff. For U-Boot there is documentation at https://docs.u-boot.org/en/latest/develop/bloblist.html. For OP-TEE there is no formal documentation but you may want to check commit OP-TEE/build@0048f71dd59b which enabled Firmware Handoff in the QEMUv8 test config of OP-TEE. This configuration has TF-A, U-Boot and OP-TEE so it will hopefully be helpful. CC @raymo200915 who worked on this.

Recently Firmware Handoff lib was migrated from TF-A to https://review.trustedfirmware.org/plugins/gitiles/shared/transfer-list-library/, I think you can get more information there.

[github-actions]

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.