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?
Cheers,
Dhiman
The best place for USB or network code would be in the non-secure bootloader (a.k.a. BL33).
Is there any stock code available in bl33 for usb communication or network communication?
Is it possible to move/write some usb communication/network communication code in bl1 or bl2* ?
From ARM trusted firmware’s point of BL33 is the name of a user supplied payload, it is not part of the trusted firmware. So your question makes no sense unless you have already selected what your BL33 payload will be.
In terms of stock code, both u-boot and EDK2 are good choices to be the BL33 payload and both have network and USB support.
It is possible… but it is very unlikely to be a good idea! Code in BL1, BL2 or BL2U runs in secure mode and this is generally not what you want for complex communication stacks; they should typically be run in normal mode.
@danielt Thank you, that helps.
I am new to edk2. So can you please tell which part of edk2 code is responsible to create BL33 payload?
A starting point will be very helpful, if you can provide.
I should warn you that EDK2 can be very difficult to learn because its
component structure makes it difficult to study with a source code
navigator (I certainly don’t claim to know all that much about it).
Nevertheless getting started instructions are here:
@danielt Thank you for the reply.
After some research I found out that it is possible to update the BL images over USB/Network using the Firmware Update process. 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.
So technically I can use NS_BL1U to perform usb/network communication if I can able to play with the payload.
I found a NS_BL1U implementation [https://github.com/96boards-hikey/atf-fastboot](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.
Can it be used with normal ATF-UEFI-build for hikey960?
No. For hikey960, the edk2 binary itself is reused for ns_bl1u.
@dhiman Please note that both atf-fastboot for hikey and reused edk2 binary for hikey960 are just to provide fastboot functionality during recovery and not necessary a full/proper implementation of ns_bl1u or fwu!
I don’t think so. NS_BL1U is designed to be implemented in mask programmed ROM within the SoC. On platforms where there is no BL1/NS_BL1U in ROM then there is not really much value in implementing NS-BL1U (or any other FWU features).
Being brutal I’d have to say attaching the TPM over USB is a mistake. I don’t much care whether or not it violates the global platform specification or not… it is more that getting the low level bootloaders to talk to it is going to be a huge amount of pointless work. It’s not that it can’t be done, but hooking it up using a simpler bus such as I2C will give you more time for the actual research.
Consider taking a look at secure96 instead (even if only as inspiration for hacking together your own hardware… it shouldn’t be hard):
Secure96 recently became available on Amazon in the US (although I’m told I have to wait little longer before they come out in Europe).
Finally regarding the networking it can be implemented in other places but personally I’d still be inclined to run the actual network stack from BL33 and use SMC to pass any crypto tokens we get from network to code running in secure mode to complete the custom authentication.
