I understand that after writing the new firmware to the corresponding Flash slot in SFW, you need to set the "magic", so SBL will be aware of the new firmware update.
But the "magic" I mentioned above refers to the magic in image's head.This magic bit is used in SFW to determine whether the firmware that the user wants to upgrade is valid or not.
the header is added through imgtool.py,and below is the structure:
struct image_header {
uint32_t ih_magic;
uint32_t ih_load_addr;
uint16_t ih_hdr_size; /* Size of image header (bytes). */
uint16_t _pad1;
uint32_t ih_img_size; /* Does not include header. */
uint32_t ih_flags; /* IMAGE_F_[...]. */
struct image_version {
uint8_t iv_major;
uint8_t iv_minor;
uint16_t iv_revision;
uint32_t iv_build_num;
};
uint32_t _pad2;
};
At the same time, if OTFAD is enabled, imgtool.py will place the OTFAD Key blob at the address 0x100. The compiled image will be placed at 0x400.
If both RSA encryption and OTFAD are enabled, I need to follow these steps: First, use imgtool.py to add the header and RSA verification tail to the image. Next, I use image_enc.exe along with OTFAD's IEK (Image Encryption Key) to encrypt the entire image.
However, according to the SBL and SFW's approach, each image can have a unique OTFAD Key Blob. Therefore, after updating image in SFW, the OTFAD Key Blob located at 0x100 in the image will be written to the SBL's address 0x40 used by BootROM.
The current problem is that before writing a new image to flash, SFW checks the magic bit at offset 0x00 of the image,and after writing a new image,SFW write the OTFAD Key blob at 0x100 to SBL's 0x40. If I encrypt the entire image using image_enc.exe, the magic and OTFAD Key Blob read by SFW at 0x00 and 0x100 respectively will be encrypted, leading to incorrect values. Therefore, based on SFW's logic, the header cannot be encrypted using image_enc.exe.
However, this creates another issue. If I don't encrypt the header, OTFAD Key Blob at 0x40 is correct.But RSA verification in SBL will fail, because the image header is already decrypted, which means OTFAD would be decrypting data that is already in plaintext. On the other hand, if I encrypt this header using image_enc.exe, the OTFAD Key Blob written to 0x40 in SFW will not be correct.
