2023-12-15 03:07 PM - edited 2023-12-15 04:42 PM
The Issue
Background
__HAL_RCC_CRC_FORCE_RESET();
__HAL_RCC_CRC_RELEASE_RESET();
__HAL_RCC_CRC_CLK_ENABLE();
ctx.handle.Instance->CR = ctx.regs.CR;
ctx.handle.Instance->POL = ctx.regs.POL;
__HAL_CRC_INITIALCRCVALUE_CONFIG(&ctx.handle, value);
__HAL_CRC_DR_RESET(&ctx.handle);
value = ~HAL_CRC_Accumulate(&ctx.handle, (uint32_t *)data, (uint32_t)size);
__HAL_CRC_INITIALCRCVALUE_CONFIG(&ctx.handle, ~0);
I would like to know how to correctly reinit the CRC after jumping from my bootloader to application as everything I have tried has failed?
Solved! Go to Solution.
2023-12-21 04:25 PM - edited 2023-12-22 06:17 AM
I have managed to resolve the issue.
1. Snapshot the state of the CRC peripheral on POR.
2. Snapshot the state of CR and POL register after HAL_CRC_Init().
3. Apply the snapshot from step 2 before calling HAL_CRC_Accumulate()
3. Apply the snapshot from step 1 after calling HAL_CRC_Accumulate()
Note you must apply the entire snapshot of the peripheral from step 1. Even if the register didn't changed. I observed that if I only reverted the changed registered back to their POR state it didn't work. I cannot say why this is though
2023-12-21 08:55 AM
Hello @desmond,
Something is not fully clear in your description.
CRC is used by cryptolib in both bootloader and application
CRC is also used by application independently from cryptolib.
You say it fails when bootloader is involved but succeeds when application runs on it own.
Does this mean that sharing CRC between cryptolib and other purpose in application is working fine and only bootloader usage make things fail ?
Also, I understand that disabling usage of CRC for other purpose in application results in bootloader + application succeed to work with cryptolib.
This is strange indeed.
I would propose 2 things:
1) in Application reset the data cache if is was enabled in bootloader
2) Check status of CRC before the call to cryptolib in application with debugger to make sure it is in good state.
Best regards
Jocelyn
2023-12-21 09:15 AM - edited 2023-12-21 09:17 AM
> Does this mean that sharing CRC between cryptolib and other purpose in application is working fine and only bootloader usage make things fail ?
Not exactly. Sharing the CRC and crytpoLib works fine until I perform an unconditional branch from the bootloader to the application. Anything out of POR and it will work anything else and it will fail. See further explanation below.
> You say it fails when bootloader is involved but succeeds when application runs on it own.
- POR
- Bootloader runs using CRC and Cryptolib. Everything works.
- Bootloader jumps to the application. CryptoLib starts failing (not API fail) ciphers are not decrypted/encrypted correctly.
- Since the application constantly has failure the watchdog reboots the system. The system is now back in the bootloader. The bootloader cryptolib are now failing.
- Crypotlib now fails forever until I do a POR. (Via reset button or via debugger).
> in Application reset the data cache if is was enabled in bootloader
- Ours boards use a common board bring up sequence. The data cache and instruction cache are disabled on board bring up. So when the bootloader launches it does this. When the application launches it does this. The data cache are invalidate prior to disabling them.
- I can give this code a closer look to ensure we have no issue though.
> Check status of CRC before the call to cryptolib in application with debugger to make sure it is in good state.
- Can you provide the state variables of the CRC peripheral that represent a good state?
- Also keep in mind on board bring for any application/bootloader the following sequence is issue to the CRC peripheral which should reset the IP to POR state as far as I understand.
__HAL_RCC_CRC_FORCE_RESET(); __HAL_RCC_CRC_RELEASE_RESET(); __HAL_RCC_CRC_CLK_ENABLE();
2023-12-21 10:04 AM
Why do these libraries need to use the CRC at all? Is there that much of a threat of them being used on other devices where the test can't simply be patched out, or removed? Are the adversaries really assumed to be that dull-witted? For all the headaches it causes normal users?
Being SYNCHRONOUS, I'd enable the clock *before* generating resets into the state machines, this will be safe even if the reset is asynchronous.
__HAL_RCC_CRC_CLK_ENABLE(); // Sychronous Logic
__HAL_RCC_CRC_FORCE_RESET(); // Drive Reset
__HAL_RCC_CRC_RELEASE_RESET();
The test vector is driving into an STM32 CRC using ST's standard 32-bit polynomial, initial value and bit/byte reversal directions. Check registers out of reset, these are the anticipated defaults.
Is all this interaction with the HW CRC even that efficient? A clean table driven parallel solution in SW can be fast and thread-safe. The HW has no accommodation for multiple concurrent usage case and is not interrupt or thread safe.
2023-12-21 10:05 AM
Hi @desmond ,
Regarding IP reset I would first enable the clock and then perform a reset. But in your case it should be already enabled.
The values in CRC register should match the default values after reset as you can find in the reference manual (RM0351)
Anyway, the failure of cryptolib after watchdog reset looks very strange because non context should be saved.
First check would be to compare CRC registers values after POR and after WD reset just before calling first crypto lib function.
Best regards
Jocelyn
2023-12-21 10:08 AM - edited 2023-12-21 12:05 PM
> Why do these libraries need to use the CRC at all?
- ST Crytpolib requirement.
> Being SYNCHRONOUS, I'd enable the clock *before* generating resets into the state machines, this will be safe even if the reset is asynchronous.
- The clock is enabled. It was not disabled prior to the unconditional jump from the bootoloader to the App. However I also tried what you said explicitly and it didn't fix the issue. I am try again to confirm
> Is all this interaction with the HW CRC even that efficient? A clean table driven parallel solution in SW can be fast and thread-safe. The HW has no accommodation for multiple concurrent usage case and is not interrupt or thread safe.
- The concurrence works prior to the jump, so it should work after the jump. On the STM32L4 we have been doing this for few years with no issue but an older cryptolib that not offered for the stm32U5.
- SW solution can work but I want to try to figure out the issue before defaulting to a work around
2023-12-21 10:11 AM
Hello @Tesla DeLorean ,
yes CRC is a kind of protection to avoid libraries being used on other competition devices. I agree this is a pain ...
I'm cannot anything about it!
Best regards
Jocelyn
2023-12-21 10:34 AM - edited 2023-12-21 10:34 AM
I understand why it's there, I just question it's efficacy, I tend to assume the most dangerous adversaries are on the Elon Musk side of the Bell Curve, not the room temperature side..
Given the market share STM32 has, I'm not sure the competitors, or users of their parts, represent a significant problem, vs the libraries malfunctioning and giving erroneous output on parts it's supposed to work on. From a functional safety point of view having something purposefully fail under inopportune cases seems like a recipe for litigation.
I would just say to shake the management / decision making tree hard enough that some of the stup1d ideas fall out.
2023-12-21 02:02 PM
Not tested, but if the CRC is in the right mode, and reset/initialized a write of 0xDEADBEEF should see a 0x81DA1A18 response.
Init condition 0xFFFFFFFF (can read and check), Poly 0x04C11DB7, 32-bit
2023-12-21 04:22 PM
There is an even better question - would anyone even use that library or would it provide an actual benefit for them. I'll remind that we are talking about a closed source security library from a company, who is known for SPL/LL/HAL/CubeMX - a spectacularly broken bloatware developed by people, who do not even understand the bug reports and just ignores them. The microcontrollers are not like a Cortex-A with virtual memory and a complete memory protection. Adding a broken code can easily break anything or be catastrophic. On the other hand there are Mbed-TLS, BearSSL, uECC developed by known security experts and a bunch of other open source quality libraries. What type of mushrooms one has to eat to choose a closed source rarely updated security library from a company with a terrible reputation for a software over those decent open source libraries?
I just question it's efficacy, I tend to assume the most dangerous adversaries are on the Elon Musk side of the Bell Curve, not the room temperature side..
But the decision making managers are on the room temperature side... Anyway it's a funny comparison. I guess for the rest of the world the analogy could be the liquid water vs the steam side. In that scale the HAL team is definitely in a hot water, but out of steam...