Hi,
On 12/7/22 20:32, Marek Vasut wrote:
On 12/7/22 11:08, Patrick DELAUNAY wrote:
Hi Marek,
Hello Patrick,
Sorry for the delay.
No worries.
I cross-check with ROM code team to understood this API limitation.
Thank you!
On 12/6/22 23:49, Marek Vasut wrote:
In case Dcache is enabled while the ECDSA authentication function is
called via BootROM ROM API, the CRYP DMA might pick stale version of
data from DRAM. Disable Dcache around the BootROM call to avoid this
issue.
Signed-off-by: Marek Vasut <ma...@denx.de>
---
Cc: Alexandru Gagniuc <mr.nuke...@gmail.com>
Cc: Patrice Chotard <patrice.chot...@foss.st.com>
Cc: Patrick Delaunay <patrick.delau...@foss.st.com>
---
V2: - Initialize reenable_dcache variable
---
arch/arm/mach-stm32mp/ecdsa_romapi.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-stm32mp/ecdsa_romapi.c
b/arch/arm/mach-stm32mp/ecdsa_romapi.c
index a2f63ff879f..082178ce83f 100644
--- a/arch/arm/mach-stm32mp/ecdsa_romapi.c
+++ b/arch/arm/mach-stm32mp/ecdsa_romapi.c
@@ -63,6 +63,7 @@ static int romapi_ecdsa_verify(struct udevice *dev,
const void *hash, size_t hash_len,
const void *signature, size_t sig_len)
{
+ bool reenable_dcache = false;
struct ecdsa_rom_api rom;
uint8_t raw_key[64];
uint32_t rom_ret;
@@ -81,8 +82,21 @@ static int romapi_ecdsa_verify(struct udevice *dev,
memcpy(raw_key + 32, pubkey->y, 32);
stm32mp_rom_get_ecdsa_functions(&rom);
+
+ /*
+ * Disable D-cache before calling into BootROM, else CRYP DMA
+ * may fail to pick up the correct data.
+ */
+ if (dcache_status()) {
+ dcache_disable();
+ reenable_dcache = true;
+ }
+
rom_ret = rom.ecdsa_verify_signature(hash, raw_key, signature,
algo);
+ if (reenable_dcache)
+ dcache_enable();
+
return rom_ret == ROM_API_SUCCESS ? 0 : -EPERM;
}
In fact, the ecdsa_verify_signature() don't use the HW (no DMA and no
use of CRYP IP )
Hmmm, what does the BootROM use CRYP for then ?
used for SSP = Secure Secret Provisioning
https://wiki.st.com/stm32mpu/wiki/Secure_Secret_Provisioning_(SSP)
It is necessary to have MP15xC/F for the authenticated boot to work,
but it seems the only difference there is the presence of CRYP. Or is
there some BootROM fuse too ?
Yes, the secure boot feature availability is indicated in the security
field of the chip part number, for STM32MP13 and STM32MP15.
- SSP is not supported
- the associated authentication feature for secure boot is deactivated
in ROM code
=> the key is burned/locked in OTP on these chips
and checked by ROM code before to authenticate the FSBL
...
This indeed works, tested and sent V3.
Sorry again for the first review, not complete...
Thank you for checking !
Regards
Patrick
