Support alloc caps in esp_encrypted_img (IEC-415)

[kevinresol]

Is your feature request related to a problem?

I am experiencing some kind of memory corruption when using esp_encrypted_img on esp32s3 with SPIRAM.

In a nutshell, it happens randomly that the decryption produces incorrect bytes. For the following code:

esp_encrypted_img_decrypt_data(self->m_decrypt_handle, &pargs);

if we inspect the decrypted bytes in pargs.data_out and compare that with the original plaintext firmware, we will see the following example discrepancies randomly.

# 1st column = address in file, 2nd+ columns = corresponding bytes

# original plaintext firmware
- 0079620 0710 0460 0122 048a 0136 04c1 010e 04cf
- 0079630 0001 04c0 04d0 0144 0561 0426 0000 0000

# decrypted firmware
+ 0079620 0027 0000 0027 0000 0026 0000 0026 0000
+ 0079630 0026 0000 0026 0000 0025 0000 0025 0000

and thus at the end of the OTA update that will result in a esp_image: Checksum failed. error.

Describe the solution you'd like.

After some investigation I suspect it is related to a bug in SPIRAM, and people suggest using internal RAM to workaround the issue. So I went on replacing all malloc, realloc & calloc calls in esp_encrypted_img.c with the heap_caps_* counterpart and MALLOC_CAP_INTERNAL, and that seems to fix the issue as it has been working perfectly for me so far.

So, I would like to suggest exposing a configuration to control where the memory should be allocated.

Describe alternatives you've considered.

No response

Additional context.

No response