search

ARM-software / tf-issues

Issue tracking for the ARM Trusted Firmware project
37 stars 16 forks source link

Usb and network support at bootloader #532

Closed dhimanchakraborty closed 6 years ago

dhimanchakraborty commented 6 years ago

Is it possible to have usb and network communication at the bootloader level(bl1, bl2, bl2u or bl3)? Which bootloader is good for usb and netwrok communication? Is there any stock code available in bl for usb communication or network communication?

soby-mathew commented 6 years ago

No, there is no USB/network support in BL2. Typically the BL images are stored within the platform in internal secure storage.

You could possibly update the BL images over USB/Network using the Firmware Update process described here. The NS_BL1U could arrange to have the FWU FIP downloaded via USB/Network. This would then get authenticated by BL1 and then updated in the internal secure storage. There is no implementation of NS_BL1U available upstream though.

dhimanchakraborty commented 6 years ago

So technically I can use NS_BL1U to perform usb/network communication if I can able to play with the payload. Am I correct here?

I found a NS_BL1U implementation https://github.com/96boards-hikey/atf-fastboot for hikey. Can it be used with normal ATF-UEFI-build for hikey960? If board is an issue I have a hikey620 handy also.

Is there any NS_BL1U implementation available for hikey boards other than the link I used.

What I want to achieve is authenticated boot using a TPM (detachable, currently connected through usb. I know it violates global platform specification. But it is part of a research) and then perform a custom direct anonymous authentication (reason why I need network at such a low level) and I want to do it from bootloader (looks like bl1 is not possible to include and that will be the trust anchor of the authenticated boot chain).

What is your opinion.

danh-arm commented 6 years ago

I can't comment on the suitability of HiKey code, but for your authenticated boot use-case, I'd expect BL2 to contain the USB stack to talk to the TPM, as that is the image that does most of the boot firmware authentication. BL1 is typically in ROM so it may not be possible to change this code, but in theory this could also contain enough of a USB stack to authenticate BL2.

The Firmware Update images (NS_BL1U, NS_BL2U) should not be needed for your use-case, but it sounds like the USB stack within HiKey NS_BL1U could potentially be ported to your modified BL2 implementation.

Similarly, I'd expect any authentication across a network to be implemented by BL1/BL2. This sounds like a device attestation use-case. Potentially such attestation could be implemented by any or all boot loader stages, especially if each image is provided by a different entity. There's no upstream support for any of this, though.

hzhuang1 commented 6 years ago

Is there any NS_BL1U implementation available for hikey boards other than the link I used.

I don't prefer to implement USB and network support in NS_BL1U. We do it for hikey just because of silicon limitation. In recovery mode, we needn't to flush images into eMMC. But the ROM could only access a few hundred kilobytes memory in SRAM. As a workaround, I have to implement the USB device driver in atf-fastboot. In HiKey960, there's no such silicon limitation. I just reuse UEFI for recovery mode.

For your case, it's better to implement USB and network support in your bootloader. For example, we implemented USB device and host in hikey UEFI, too.