- TF-M - lists.trustedfirmware.org

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

OK, Thank you for sharing the plan. About applying patch you gave,(https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838)… Using variables immediately after TRAM enable can cause bus errors due to the same reason we discussing. /* Enable the TRAM */ *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001; In actual, the access to variables in DTCM occur bus error after TRAM enabled. So i modified that it temporarily clear to 0 without using variable.     /* Enable the TRAM */     *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;     /* Erase the DTCM */     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x038) = 0; // FILLVAL     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x02c) = 0x000F0044; // DESTRANSCFG     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x018) =  DTCM_CPU0_BASE_S; // DESADDR     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x030) = 0x00010000; // XADDRINC     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x020) = (DTCM_SIZE / sizeof(uint64_t)) << 16; // XSIZE     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x00c) = 0x1200603; // CONFIG     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x008) = 0x00000000; // Disable All Interrupt     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000) = 0x00000001; // RUN_CMD          while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000)) & 0x1) != 0) {} But, it needs to find a fundamental solution. Please check it and i will share the solution if we find good idea. Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: 김륜현 <winxp4333@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> 날짜: 2025-07-28 19:28:00 제목: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

7 months, 2 weeks

2
1
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by Raef Coles

Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>,김륜현 <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

7 months, 2 weeks

1
0
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur.  I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

7 months, 2 weeks

1
0
0 0

RSE booting with HardFault issue when TRAM enabled

by 김륜현

Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM                     OFF       CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM                     ON       CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM  In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.  setup_tram_encryption()(a)startup_rse_bl1_1.c     tram_enable_encryption(&tram_dev_s);     if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {         bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));         for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {             ((uint32_t *)DTCM_BASE_S)[idx] = random_word;         }     } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below.     tram_enable_encryption(&tram_dev_s); -    if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { +   if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {         bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));         for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {             ((uint32_t *)DTCM_BASE_S)[idx] = random_word;         }     } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().  But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable?  or is there anything to fix this problem? Best Regards RH Kim

7 months, 3 weeks

2
1
0 0

Re: Issue with integrity_checker_compute_value() and cache coherence on RDV3R1 with TF-M

by 박진국

Hi Raef Based on your advice, I made the modifications as below and confirmed that it works properly. Thank you for your help. JK Park enum integrity_checker_error_t integrity_checker_compute_value_bl2(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, uint32_t *value, size_t value_size, size_t *value_len) { //volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) // temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; //jkpark volatile uint32_t __ALIGNED(32) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, true); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH; } init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Set to compute mode */ iccval |= 1 << 4; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set output address */ p_integrity_checker->iccva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED; } SCB_InvalidateDCache_by_Addr((void *)temp_val, 32); if (value_ptr != value) { for (int idx = 0; idx < mode_sizes[mode] / sizeof(uint32_t); idx++) { value[idx] = value_ptr[idx]; } } if (value_len != NULL) { *value_len = mode_sizes[mode]; } return INTEGRITY_CHECKER_ERROR_NONE; } enum integrity_checker_error_t integrity_checker_check_value_bl2(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, const uint32_t *value, size_t value_size) { //volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) // temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; //jkpark volatile uint32_t __ALIGNED(32) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; const volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, false); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_LENGTH; } //if (((uintptr_t)value % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0 // || (value_size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { for (int idx = 0; idx < value_size / sizeof(uint32_t); idx++) { temp_val[idx] = value[idx]; } value_ptr = temp_val; //} SCB_CleanDCache_by_Addr((void *)temp_val, 32); init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set compare address */ p_integrity_checker->iceva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_OPERATION_FAILED; } else if (p_integrity_checker->icis & (0b10)) { /* Check for comparison failure */ NONFATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_COMPARISON_FAILED); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_COMPARISON_FAILED; } return INTEGRITY_CHECKER_ERROR_NONE; }

7 months, 3 weeks

1
0
0 0

Security vulnerability notice - Fix unchecked TLV payload length

by Anton Komlev

Hello, This is a notification regarding a newly reported security vulnerability in Trusted Firmware-M (TF-M): TFMV-9: Fix unchecked TLV payload length by Bartek Piekarski from Product Security team, Arm Ltd. Please find the detailed security advisory attached. The fix for this issue has been merged into the latest main branch under the same identifier: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40872 We are currently preparing hotfix releases v2.1.3 and v2.2.1, which will include this fix along with other bug fixes reported up to the release date via the TF-M issue tracker: https://github.com/TrustedFirmware-M/trusted-firmware-m/issues?q=is%3Aissue Thanks, and best regards Anton Komlev

7 months, 3 weeks

1
0
0 0

Issue with integrity_checker_compute_value() and cache coherence on RDV3R1 with TF-M

by 박진국

Hello, I am currently developing TF-M on the RDV3R1 S/W platform, and I would like to report a potential issue observed during runtime with the integrity_checker_compute_value() function in BL2. Problem Description: Inside the integrity_checker_compute_value() function, the iccva register is set to the address of either the value or temp_val variable, as shown in the example below. enum integrity_checker_error_t integrity_checker_compute_value(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, uint32_t *value, size_t value_size, size_t *value_len) { volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, true); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH; } if (((uintptr_t)value % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { value_ptr = temp_val; } init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Set to compute mode */ iccval |= 1 << 4; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set output address */ p_integrity_checker->iccva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED; } if (value_ptr != value) { for (int idx = 0; idx < mode_sizes[mode] / sizeof(uint32_t); idx++) { value[idx] = value_ptr[idx]; } } if (value_len != NULL) { *value_len = mode_sizes[mode]; } return INTEGRITY_CHECKER_ERROR_NONE; } static void init_integrity_checker(struct integrity_checker_dev_t *dev, uint32_t *iccval) { struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; /* Set MatchTriggerDisable, as it is mandatory. */ *iccval |= 1 << 5; /* Set EncompvalOut so the integrity checker writes the value pointer in * compute mode. */ *iccval |= 1 << 6; *iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 7; *iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 9; /* Disable all alarms */ p_integrity_checker->icae = 0; /* Enable and clear all interrupts */ p_integrity_checker->icie = 0xFF; p_integrity_checker->icic = 0xFF; } The issue arises because the memory areas pointed to by value and temp_val are cacheable (e.g., located in the vm0 memory region, which is configured as cacheable). As a result, even though the integrity checker writes the output data to the physical address of value or temp_val, the CPU cache is not updated, and this leads to stale data being read later in software, resulting in runtime errors. Expected Behavior: Ideally, the memory region used for integrity checker output should either be: Non-cacheable, or Explicitly synchronized (e.g., cache invalidated or cleaned) after the integrity checker operation. Could you please confirm whether this is a known issue, and advise on the recommended way to handle integrity checker outputs with respect to cache settings? Thank you. JK Park

8 months

2
1
0 0

TF-M BL2 compiling issue using RDINFRA

by 김태훈

Hello, I'm a RSE firmware developer for Arm Neoverse V3 core. I tried to build with argument MCUBOOT_ENC_IMAGES, MCUBOOT_ENCRYPT_RSA, and MCUBOOT_USE_PSA_CRYPTO for RSE PE encryption. In this process, I encountered an error during build TF-M using the repo for tag:RD-INFRA-2025.07.03. It seems that linking problem, and I found out that the error occurred while configuring BL2. However, that's all. Can anyone help me? Below log is in my terminal output.  p.s. If I reached wrong site, please forgive me and teach me a right one. cmake --build build --target bl2 [  0%] Built target manifest_tool [  0%] Built target bl2_scatter [ 10%] Built target bl2_cc3xx_psa_driver_api [ 31%] Built target bl2_cc3xx [ 68%] Built target platform_bl2 [ 78%] Built target bl2_crypto [ 94%] Built target bootutil [ 94%] Linking C executable ../bin/bl2.axf /home/gth1919/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: ext/mcuboot/bootutil/libbootutil.a(encrypted.o): in function `bootutil_rsa_oaep_decrypt': /TF_M/build/lib/ext/mcuboot-src/boot/bootutil/include/bootutil/crypto/rsa.h:107: undefined reference to `psa_asymmetric_decrypt' Memory region         Used Size  Region Size  %age Used            FLASH:       80356 B       126 KB     62.28%              RAM:       35360 B       896 KB      3.85% collect2: error: ld returned 1 exit status gmake[3]: *** [bl2/CMakeFiles/bl2.dir/build.make:222: bin/bl2.axf] Error 1 gmake[2]: *** [CMakeFiles/Makefile2:2661: bl2/CMakeFiles/bl2.dir/all] Error 2 gmake[1]: *** [CMakeFiles/Makefile2:2668: bl2/CMakeFiles/bl2.dir/rule] Error 2 gmake: *** [Makefile:520: bl2] Error 2 HP. Mail.  010-6768-7791  gth1919(a)adtek.co.kr Application Platform Group김태훈 연구원 (주)에이디테크놀로지 (16512) 경기도 수원시 영통구 광교중앙로248번길 7-8 Web. http://www.adtek.co.kr

8 months

2
1
0 0

Proposal to deprecate Musca-S1 and BL5340_dvk_cpuapp platforms

by Anton Komlev

Hi everyone, We would like to propose the deprecation of the following two TF-M platforms: 1. Musca-S1 (Arm) Musca-S1 was one of the earliest platforms featuring an Armv8-M silicon implementation, providing a valuable real hardware target for initial development. However, with the availability of many modern hardware platforms, Musca-S1 is no longer essential and can be deprecated. 2. BL5340_dvk_cpuapp (Laird Connectivity) This platform was initially proposed for deprecation at the end of 2023. Support activity has been minimal, and it closely mirrors the already-supported nRF5340 platform from Nordic Semiconductor. Please share any comments or objections regarding this proposal. If no major concerns are raised by the end of June 2025, we plan to mark these platforms as deprecated and proceed with their removal from the codebase. Thank you, Anton

8 months, 1 week

1
1
0 0

Trusted Firmware Gerrit issues

by Matthew Dalzell

Hi All, We have recently undergone a migration of our Gerrit server and are seeing some issues. One such change appears to be that https://review.trustedfirmware.org/TF-M/trusted-firmware-m no longer resolves to https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m. So please use the latter link if that is what you wish to access. This is causing a large slow-down on the CI causing jobs to not be run. These issues are being actively worked on and we hope all will be back up and running normally soon. If you have any questions or related issues please feel free to respond to this chain. Thank you for your patience, Matt

8 months, 2 weeks

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M