Hi,
I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`.
Per-partition files done:
CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message):
Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
target architecture is known. Please enable at least one language before
including GNUInstallDirs.
Call Stack (most recent call first):
build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hello.
I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2
In TF-M v2.2.2, I found code for ROTPK revocation and updates.
I think this code is intended for scenarios where keys,
such as the private key corresponding to a ROTPK, need to be replaced.
It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK.
If this understanding is correct,
I would expect an additional authorization step to take place before TF-M processes the request.
For example, if changing ROTPK “A” can be authorized
by a signature generated with its corresponding private key, “A_private,”
this seems potentially risky from a security perspective.
Am I understanding this correctly, or am I missing something?
If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M,
could you provide an example of what that step would involve?
Thanks
Best Regards
Phillip
Hello.
I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2
In TF-M v2.2.2, I found code for ROTPK revocation and updates.
I think this code is intended for scenarios where keys,
such as the private key corresponding to a ROTPK, need to be replaced.
It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK.
If this understanding is correct,
I would expect an additional authorization step to take place before TF-M processes the request.
For example, if changing ROTPK “A” can be authorized
by a signature generated with its corresponding private key, “A_private,”
this seems potentially risky from a security perspective.
Am I understanding this correctly, or am I missing something?
If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M,
could you provide an example of what that step would involve?
Thanks
Best Regards
Phillip
