Hi all,

 

I think I know what the problem is.

I believe it is related to the problem I have reported earlier in mailing thread https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.org/message/F3WT4OBAOLTBFCSRXC7KFJTFWZRONOD3/

Problem occurs during built of psa_generate_database target. The same was reported by me in the mailing thread. The only difference is that I used Windows.

So I have investigated the problem and found the solution, hope it will help you.

 

Turns out PSA arch tests use native platform compiler (e.g. GCC for windows) to compile some generated files and then these compiled files are used in the rest of the build using compiler for arm platform.

<psa-arch-tests>/api-tests/CMakeLists.txt adds External project (ExternalProject_Add()) which generates the device database that is needed for the rest of the build.

 

As I said psa_generate_database built invokes native compiler, so call to cc1 is not the call to gcc-arm-none-eabi-10.3-2021.10/lib/gcc/arm-none-eabi/10.3.1/cc1, it is a call to linux native cc1 compiler (to compile given .c file to be executed on Linux)

 

I have installed llvm-mingw and added its bin folder to PATH and this fixed the problem. I think GCC (or other native compilers) will also work.

 

Looks like ARM TF-M team has native compiler installed on their working machines so arch tests build works right away.

 

So my suggestion is to install linuz native cc1 compiler and add it to the PATH

 

Please let me know if this fixed the problem.

 

Regards,

Bohdan Hunko

 

Cypress Semiconductor Ukraine

Engineer

CSUKR CSS ICW SW FW

Mobile: +38099 50 19 714
Bohdan.Hunko@infineon.com

 

 

From: Shebu Varghese Kuriakose via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 9 February 2023 15:27
To: Andersson, Joakim <Joakim.Andersson@nordicsemi.no>; Kevin Townsend (kevin.townsend@linaro.org) <kevin.townsend@linaro.org>; Andrej Butok <andrey.butok@nxp.com>; tf-m@lists.trustedfirmware.org
Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>; nd <nd@arm.com>
Subject: [TF-M] Re: Non-OSI license issue with QCBOR

 

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

 

Hi Joakim,

 

The license is acceptable for Trusted Firmware-M with QCBOR being used as an external library.

 

Please refer Section 9 of the Trusted Firmware Project Charter - https://www.trustedfirmware.org/docs/Trusted_Firmware_Charter_v_2021_07_14.pdf

9 c) states that the original license text needs to be used and documented.   There is documentation about license here - https://tf-m-user-guide.trustedfirmware.org/introduction/index.html?highlight=license#license but can be improved.

 

Understand QCBOR license is problematic for Zephyr and needs to be resolved.

 

HTH,

Shebu

 

From: Andersson, Joakim via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, February 9, 2023 11:05 AM
To: Kevin Townsend (kevin.townsend@linaro.org) <kevin.townsend@linaro.org>; Andrej Butok <andrey.butok@nxp.com>
Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Non-OSI license issue with QCBOR

 

Does that mean that the License is acceptable for use in the Trusted-Firmware organization?

Does trusted-firmware have any policy on what kind of licenses it’s the dependencies (like TF-M) are allowed to use?

-Joakim

 

From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.org>
Sent: torsdag 9. februar 2023 09:29
To: Andrej Butok <andrey.butok@nxp.com>
Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Non-OSI license issue with QCBOR

 

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi Andrej,

 

We’re trying to work with the Qualcomm TSC rep in Zephyr to see if it can be relicensed, but there are about 20 authors to track down to make this happen, so it won’t be a quick solution even if it is possible.

 

In the interim, we’ll likely have to disable all use of the library to avoid blocking the Zephyr 3.3 release, meaning disabling use of the attestation service until a legal solution can be found.

 

Best regards,

Kevin

 

On Thu, 9 Feb 2023 at 08:52, Andrej Butok <andrey.butok@nxp.com> wrote:

Hi Kevin,

 

TFM may not change the 3rd party license clauses.

Can it be solved directly with the QCBOR project https://github.com/laurencelundblade/QCBOR to make it OSI compliant?

 

Thanks,

Andrej

 

From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, February 8, 2023 6:12 PM
To: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Non-OSI license issue with QCBOR

 

We were discussing a problem with the Zephyr integration of TF-M today on the Zephyr TSC call, determining how to avoid QCBOR being downloaded at build time, which is against Zephyr project policy. Zephyr project policy is that all build dependencies need to exist in the Zephyr project Github org, and be downloaded before building.

 

During the discussion, it came up that QCBOR actually doesn't have an OSI approved open license, even if it appears to have one on first glance: https://github.com/zephyrproject-rtos/zephyr/issues/54017#issuecomment-1422934516

 

"Essentially" 3-Clause BSD really doesn't legally mean anything https://github.com/laurencelundblade/QCBOR/blob/master/README.md?plain=1#L527

 

It looks like `NON-INFRINGEMENT` has been added to the license text, which is easy to miss, but entirely changes the license terms.

 

This is highly problematic, since not being OSI compliant now puts us in a position where we may have to remove TF-M from Zephyr to avoid blocking the 3.3 release, due to project policy around licenses, or I need to remove anything that relies on QCBOR until the license can be sorted out, with the 3.3 release and freeze scheduled for Friday. I'll look tomorrow at disabling attestation tokens, which seem to be the main user of this, but I wanted to bring the license issues up for anyone else who requires OSI-complliant licenses since this is easy to miss, and has been missed until now days from a release.

 

Thought it was important enough to quickly bring up here for TSC attention, while I try to find a solution less radical that removing TF-M to avoid blocking the Zephyr release.


--

Thanks and best regards,

Kevin Townsend
Tech Lead - LITE, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs

--

Thanks and best regards,

Kevin Townsend
Tech Lead - LITE, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs