Add support to verify more images

[Leo-Yan]

When ATF booting, now it only support the image loading and verification for BL2/BL30/BL31/BL32/BL33; is it possible to load other images (for example, some firmware images) and verify for them? And how about enhance FIP to be more flexible to support more images loading?

[danh-arm]

I can see this would be a useful enhancement. I think we would need to look at the naming convention for the BL3-X images. However, our current focus in this area is on enhancing the Trusted Board Boot (authentication) support of the existing images, since the current implementation is only a prototype.

I'd like to understand your requirements a bit more.

• Are you suggesting that it would be useful for you for BL2 to load additional images even without authentication support?
• Presumably you do not require these additional images to be executed on the Application Processor? Is this for loading of firmware for other processors?
• I presume you are expecting some platform specific hook in BL2 after each image is loaded/authenticated?
• Do you have any requirements on the order of the images being loaded? I can imagine a use-case where some images must be loaded before others (e.g. like BL3-0 on Juno).
• Do you expect the list of firmware images to be known at build time, or will there need to be some detection of which images to load (e.g. via metadata in the FIP header).

[Leo-Yan]

On Tue, Apr 14, 2015 at 04:47:13AM -0700, danh-arm wrote:

I can see this would be a useful enhancement. I think we would need to look at the naming convention for the BL3-X images. However, our current focus in this area is on enhancing the Trusted Board Boot (authentication) support of the existing images, since the current implementation is only a prototype.

Understand.

here give more input: this question is coming from i need enable hikey
board with one mcu firmware image, the mcu is only used for power
controller purpose. This looks like very simliar w/t Juno's SCP
firmware; so we also use BL3-0's section for loading mcu firmware. But
originally i think BL3-0 is most likely to be used for secure
processor, so i think it's better we can add more entries in FIP; And
later this firmware image need to verify during booting phase.

I'd like to understand your requirements a bit more.

• Are you suggesting that it would be useful for you for BL2 to load additional images even without authentication support?

This can be flexible. i think it's better we can just set FIP's
property to tell ATF whether need authentication or not. So that we
can use one binary to support normal boot or trust boot.

• Presumably you do not require these additional images to be executed on the Application Processor? Is this for loading of firmware for other processors?

Yes, pls refer upper background. But from customer's requirement, we
need verify this firmware for trust boot.

• I presume you are expecting some platform specific hook in BL2 after each image is loaded/authenticated?

On 96board hikey. We want to figure out whether now use BL3-0 to load
mcu firmware is reasonable or not, originally i think BL3-0 is used
for secure processor; but after read again for firmware-design.md,
looks like BL3-0 also can be used by other firmware loading if there
have no confliction:

"Some systems have a separate System Control Processor (SCP) for power, clock,
reset and system control. BL2 loads the optional BL3-0 image from platform
storage into a platform-specific region of secure memory. The subsequent
handling of BL3-0 is platform specific. For example, on the Juno ARM development
platform port the image is transferred into SCP memory using the SCPI protocol
after being loaded in the trusted SRAM memory at address 0x04009000. The SCP
executes BL3-0 and signals to the Application Processor (AP) for BL2 execution
to continue."

• Do you have any requirements on the order of the images being loaded? I can imagine a use-case where some images must be loaded before others (e.g. like BL3-0 on Juno).

Yes, the mcu image should be loaded before kernel; because it's better
can be ready before kernel's init so that kernel can smoothly send
request related w/t power modules.

• Do you expect the list of firmware images to be known at build time, or will there need to be some detection of which images to load (e.g. via metadata in the FIP header).

i prefer the later choice, it will decouple FIP's format w/t boot sequence;
In ATF, it just simply parse the metadata and load images (or also verify
the image accroding to the property of every image in FIP).

---

Reply to this email directly or view it on GitHub:
#301 (comment)

[danh-arm]

here give more input: this question is coming from i need enable hikey
board with one mcu firmware image, the mcu is only used for power
controller purpose. This looks like very simliar w/t Juno's SCP
firmware; so we also use BL3-0's section for loading mcu firmware. But
originally i think BL3-0 is most likely to be used for secure
processor, so i think it's better we can add more entries in FIP; And
later this firmware image need to verify during booting phase.

Actually, BL3-0 was always originally for SCP (System Control and Power) firmware so it seems to me your mcu firmware can directly replace this, although I agree that support for additional images would be good.

• Do you have any requirements on the order of the images being loaded? I can imagine a use-case where some images must be loaded before others (e.g. like BL3-0 on Juno).

Yes, the mcu image should be loaded before kernel; because it's better
can be ready before kernel's init so that kernel can smoothly send
request related w/t power modules.

I actually meant whether it needs to be loaded before other firmware images - I already assumed that all firmware is loaded before the kernel! For example, the SCP firmware on Juno has to be loaded and executed before the normal world firmware is loaded, since the SCP firmware is responsible for initializing DRAM.

Anyway, I think your previous answer explains that you need this loaded early, at the same time as SCP firmware on Juno.

• Do you expect the list of firmware images to be known at build time, or will there need to be some detection of which images to load (e.g. via metadata in the FIP header).

i prefer the later choice, it will decouple FIP's format w/t boot sequence;
In ATF, it just simply parse the metadata and load images (or also verify
the image accroding to the property of every image in FIP).

I prefer that too but it's more work. Do you actually need it?

At the moment, I don't see any hard requirements from you, just nice to have improvements.

[Leo-Yan]

On Thu, Apr 16, 2015 at 09:15:45AM -0700, danh-arm wrote:

here give more input: this question is coming from i need enable hikey
board with one mcu firmware image, the mcu is only used for power
controller purpose. This looks like very simliar w/t Juno's SCP
firmware; so we also use BL3-0's section for loading mcu firmware. But
originally i think BL3-0 is most likely to be used for secure
processor, so i think it's better we can add more entries in FIP; And
later this firmware image need to verify during booting phase.

Actually, BL3-0 was always originally for SCP (System Control and Power) firmware so it seems to me your mcu firmware can directly replace this, although I agree that support for additional images would be good.

Okay, we will follow this to use BL3-0 for mcu firmware.

• Do you have any requirements on the order of the images being loaded? I can imagine a use-case where some images must be loaded before others (e.g. like BL3-0 on Juno).

Yes, the mcu image should be loaded before kernel; because it's better
can be ready before kernel's init so that kernel can smoothly send
request related w/t power modules.

I actually meant whether it needs to be loaded before other firmware images - I already assumed that all firmware is loaded before the kernel! For example, the SCP firmware on Juno has to be loaded and executed before the normal world firmware is loaded, since the SCP firmware is responsible for initializing DRAM.

Anyway, I think your previous answer explains that you need this loaded early, at the same time as SCP firmware on Juno.

In my case, the mcu firmware has no dependency w/t other firmware
images, just need init it before kernel.

• Do you expect the list of firmware images to be known at build time, or will there need to be some detection of which images to load (e.g. via metadata in the FIP header).

i prefer the later choice, it will decouple FIP's format w/t boot sequence;
In ATF, it just simply parse the metadata and load images (or also verify
the image accroding to the property of every image in FIP).

I prefer that too but it's more work. Do you actually need it?

Not really need for current case.

At the moment, I don't see any hard requirements from you, just nice to have improvements.

Exactly.

Thanks for explanation; Now it's much clear. :)

---

Reply to this email directly or view it on GitHub:
#301 (comment)

[danh-arm]

Internal ref: http://jira.arm.com/browse/GENFW-1204

[danh-arm]

This is effectively implemented by ARM-software/arm-trusted-firmware#781