Yes, I just noticed.
Hi Thomas, tfm-twin-cpu is a dedicated project tag for multi-core feature development with special schedule, task plan and target, which have been determined.
Please select other tags. Sorry for any inconvenience.
Changes for this issue had been merged.
Could you please elaborate on your issue? How are you trying to configure your email address in Gerrit? Are you doing it from the user settings page? Do you have no email address registered on Gerrit at all or are you trying to add a secondary one? When is the error 422 showing?
Mark this task as resolved since IPC is available.
Tue, Sep 17
Fix for this issue: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1959/
Mon, Sep 16
@ainh Any thoughts, please?
Fri, Sep 13
Fix has been merged.
This task is sorted - https://review.trustedfirmware.org/c/trusted-firmware-m/+/1811 and can be closed.
To fix the erase part, I'd like to propose that we have a new definition in the partition of each target
#define SST_SECTORS_PER_BLOCK 8
#define SST_SECTOR_SIZE FLASH_AREA_IMAGE_SECTOR_SIZE #define SST_BLOCK_SIZE (SST_SECTORS_PER_BLOCK * SST_SECTOR_SIZE)
and should support all the targets. Other targets would simply adhere to 4KB emulated block size where SST_SECTORS_PER_BLOCK is 1.
I think we shall discuss the issue internally with the team first.
Change for this issue is: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1952/
Change for this issue is
Thu, Sep 12
I will investigate adding instructions for using virtualenv. My feeling is that some users will consider it too complicated to set up just to build the project though. Maybe we could provide instructions for both alternatives?
Wed, Sep 11
What's wrong with virtualenv? How does it hurt the user experience?
While using virtualenv with a requirements.txt with recommended hard-coded versions is definitely best solution it may come at the expense of user experience.
Using pip instead of the Linux distributions package manager is considered bad practice because:
- may end up having two version of a package installed which can trigger problems. (Packages installed by pip are not visible to apt and vice-versa.)
- some pip packages have binary components. Some versions of these components may be not compatible to other binaries installed on the machine. This means only some versions of such pip packages are compatible with a specific distro.
I don't know what options you tried to build with, but I managed to build with the ROMLIB feature for the FVP platform. I will post everything I did here, hoping it will be of some use to you.
I used the following command to build:
MBEDTLS_DIR=<path_to_mbedtls> make ARM_ROTPK_LOCATION=devel_rsa CROSS_COMPILE=<path_to_cross_compiler(aarch64)> GENERATE_COT=1 PLAT=fvp ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem TRUSTED_BOARD_BOOT=1 USE_ROMLIB=1 DEBUG=1 fiptool all
The cross-compiler I used is GCC 8.3 for AArch64 ELF bare-metal target. You can get it from here:
move nspm sources to ns_callable: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1921
Tue, Sep 10
Fixes for the issue had been merged
Change for this issue had been merged.
So, just to be clear: Imagine a scenario with two devices - one I made (I know the keys and code on BL1) and another one that some malicious user cloned (he signed with his own keys). My device will have a Root of Trust in BL1 based on my hardware and the keys I own. The second device also has a BL1 but that image was signed by someone I don't trust. In the end, both devices will boot up successfully because they are based on each individual Chain of Trust but there's no way a third party (i.e. remote attestation server) can know the difference between the malicious device and my device solely relying on Verified Boot, right?
Mon, Sep 9
Verified boot in itself already proves the boot integrity of all firmware images from BL1 up to BL33.
BL1 is the root of trust and cannot be tampered with, as it is hardware-protected. All other BL image are signed and their signature is verified before they get executed: BL1 verifies the signature of BL2, and BL2 does the same for all subsequent BL3x images. If one of the signatures is invalid then TF-A refuses to execute the corresponding image. This is treated as a fatal error that the firmware cannot recover from and the platform will typically panic in this case.
Sorry, I completely missed your point at first!
Various aspects of this task are to be addressed in different broader conceptual changes in the code base.
Fri, Sep 6
Patch for this task https://review.trustedfirmware.org/c/trusted-firmware-m/+/1907
Thu, Sep 5
Are you thinking something similar to measured boot ?
The TF-A implements what is called verified boot. Found a good description for difference between verified and measured boot here:
Wed, Sep 4
Patch for this task https://review.trustedfirmware.org/c/trusted-firmware-m/+/1893
Tue, Sep 3
After detailed debugging, also increase IPC test client secure partition stack size to 0x220.
patch link: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1785
I think the mechanism is changed during this patch:
Done by David Hu's patch:
Mon, Sep 2
Patch-set with the fix: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1884/