Hi all,
This started as an internal discussion for U-Booa and SSL which quickly span out of control, so the mailing list is a better suited place for this discussion.
Akashi-san had an interesting idea. Since we will try to implement StandaloneMM as an OP-TEE TA, why not add payload authentication capabilities on it. Since it's already doing variable authentication on the secure side, the needed changes would be minimal (at least that's what i think, please correct me if i am wrong), since most of the code should already be there.
This means that the payload authentication will be moved to the secure world. Although doing the authentication in secure world won't offer any security enhancements, the common code across firmware implementations is probably nice to have.
The obvious drawback is that you limit the payload authentication capabilities, since running StMM will become obligatory for image that.
Thanks /Ilias
Hi Ilias,
On 26 Apr 2019, at 06:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
This started as an internal discussion for U-Booa and SSL which quickly span out of control, so the mailing list is a better suited place for this discussion.
Akashi-san had an interesting idea. Since we will try to implement StandaloneMM as an OP-TEE TA, why not add payload authentication capabilities on it. Since it's already doing variable authentication on the secure side, the needed changes would be minimal (at least that's what i think, please correct me if i am wrong), since most of the code should already be there.
This means that the payload authentication will be moved to the secure world. Although doing the authentication in secure world won't offer any security enhancements, the common code across firmware implementations is probably nice to have.
So, as discussed on the private thread, I do not think this is a good idea. The main reasons to use StandaloneMM are to protect secrets (private keys) or to protect storage against unauthorised writes (protect against reset or rollback). When it come to firmware image updates and secure variable changes, using StandaloneMM makes sense.
However, image authentication doesn’t involve access to any secrets. Nor does it change any secure variables. Moving image authentication into the secure world increases complexity without any additional security benefit, and it precludes any secure boot implementations when StandaloneMM is not available.
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
g.
The obvious drawback is that you limit the payload authentication capabilities, since running StMM will become obligatory for image that.
Thanks /Ilias _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Grant,
Hi Ilias,
On 26 Apr 2019, at 06:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
This started as an internal discussion for U-Booa and SSL which quickly span out of control, so the mailing list is a better suited place for this discussion.
Akashi-san had an interesting idea. Since we will try to implement StandaloneMM as an OP-TEE TA, why not add payload authentication capabilities on it. Since it's already doing variable authentication on the secure side, the needed changes would be minimal (at least that's what i think, please correct me if i am wrong), since most of the code should already be there.
This means that the payload authentication will be moved to the secure world. Although doing the authentication in secure world won't offer any security enhancements, the common code across firmware implementations is probably nice to have.
So, as discussed on the private thread, I do not think this is a good idea. The main reasons to use StandaloneMM are to protect secrets (private keys) or to protect storage against unauthorised writes (protect against reset or rollback). When it come to firmware image updates and secure variable changes, using StandaloneMM makes sense.
However, image authentication doesn’t involve access to any secrets. Nor does it change any secure variables. Moving image authentication into the secure world increases complexity without any additional security benefit, and it precludes any secure boot implementations when StandaloneMM is not available.
I don't have any strong opinion for this either.
To be honest i can live with StandaloneMM used for this, although as you pointed out crosses the boundary of the it's current functionality. The reason is, i like the common abstraction for firmware implementation on these kind of things.
That being said i think imposing a limitation on who can run a 'secure boot' by moving the authentication in the secure world is a no-go. It will probably produce more fragmentation than the one we are trying to fix :)
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works. That's how this dicussion came up. Since that's ready we tried to consider how to properly add the proper functions in U-Boot (for image authentication) and considered the secure-world option.
P.S: i'd still like to hear arguments if someone thinks this should happen
Thanks /Ilias
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
and u-boot performs the update ? The bracketed items [] being optional ?
A question then would it not also be possible to bypass capsule submission in Linux ?
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
--- bod
On 26/04/2019 11:35, Bryan O'Donoghue wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image authentication can happily be handled in unpriviledged normal world code.
However for firmware image updates to be secure they absolutely need to be authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the PK, KEK, DB, or DBX variables.
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR platforms do this. It is optional on EBBR.
There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background rather than taking the system down for a period of time.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
and u-boot performs the update ? The bracketed items [] being optional ?
I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the capsule-update-on-disk method (see below).
A question then would it not also be possible to bypass capsule submission in Linux ?
On a device designed with security in mind, none of the images (BL31, BL32, or BL33) would be able to be updated by normal world code. Image updates would probably be written by BL32. U-Boot pass the images to BL32
However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right signature (can protect against unsigned code, but cannot protect against rollbacks).
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined is there are 2 tables of function pointers: BootServices and RuntimeServices. Both are available before the call to ExitBootServices(), but only RuntimeServices are available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot currently stubs out most of the runtime services functions after ExitBootServices() is called.
g.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue bryan.odonoghue@linaro.org wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically
for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or
tested
yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
That shall be one of the few runtime services supported as well as get/set variables.
Is that the current POR ?
Yes
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
and u-boot performs the update ? The bracketed items [] being optional ?
only for the untrusted parts. S-EL3 shall update or validate the updates.
A question then would it not also be possible to bypass capsule submission in Linux ?
In a different thread (EFIBootguard: do you follow this one too?), someone
proposed that in the context of A/B partitions, Linux software agent updates a partition and the reboot cycle validates if it accepts. This may be a flow but I see issues in this approach that need a lot of discussion.
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background >rather than taking the system down for a period of time.
I think, secure world has capability of writing to flash, mainly for secure variables. On x86, what I recall they have two partitions on flash , one is holding firmware and another is variables. And partition which has firmware is locked after end-of-dxe, due to this they have to reset to update the image. On ARM side, specifically on our platforms, we don’t have such scheme to partition flash. Then why not to write flash in context of OS instead of doing additional reset.
Regards Udit
-----Original Message----- From: boot-architecture boot-architecture-bounces@lists.linaro.org On Behalf Of Grant Likely Sent: Friday, April 26, 2019 4:28 PM To: Bryan O'Donoghue bryan.odonoghue@linaro.org; boot- architecture@lists.linaro.org Cc: nd nd@arm.com Subject: [EXT] Re: StandaloneMM discussion
Caution: EXT Email
On 26/04/2019 11:35, Bryan O'Donoghue wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image authentication can happily be handled in unpriviledged normal world code.
However for firmware image updates to be secure they absolutely need to be authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the PK, KEK, DB, or DBX variables.
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR platforms do this. It is optional on EBBR.
There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background rather than taking the system down for a period of time.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
and u-boot performs the update ? The bracketed items [] being optional ?
I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the capsule- update-on-disk method (see below).
A question then would it not also be possible to bypass capsule submission in Linux ?
On a device designed with security in mind, none of the images (BL31, BL32, or BL33) would be able to be updated by normal world code. Image updates would probably be written by BL32. U-Boot pass the images to BL32
However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right signature (can protect against unsigned code, but cannot protect against rollbacks).
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined is there are 2 tables of function pointers: BootServices and RuntimeServices. Both are available before the call to ExitBootServices(), but only RuntimeServices are available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot currently stubs out most of the runtime services functions after ExitBootServices() is called.
g.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.linaro.org%2Fmailman%2Flistinfo%2Fboot-
architecture&data=02%7C01
%7Cudit.kumar%40nxp.com%7Cffbc5c786c91432d9a2e08d6ca3634a6%7C686e a1d3b
c2b4c6fa92cd99c5c301635%7C0%7C0%7C636918731493779757&sdata=% 2FA38X
UlqnPzYkHajk0EAanUvCMiOnOfz37M3nk%2Bqe4A%3D&reserved=0
boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lina... o.org%2Fmailman%2Flistinfo%2Fboot- architecture&data=02%7C01%7Cudit.kumar%40nxp.com%7Cffbc5c786c91 432d9a2e08d6ca3634a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% 7C636918731493779757&sdata=%2FA38XUlqnPzYkHajk0EAanUvCMiOnOfz 37M3nk%2Bqe4A%3D&reserved=0
On Fri, 26 Apr 2019 at 12:58, Grant Likely Grant.Likely@arm.com wrote:
On 26/04/2019 11:35, Bryan O'Donoghue wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image authentication can happily be handled in unpriviledged normal world code.
However for firmware image updates to be secure they absolutely need to be authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the PK, KEK, DB, or DBX variables.
I disagree. Firmware *updates* need to be authenticated to whichever agent is in charge of writing the flash. It is perfectly reasonable for the non-secure firmware to be in charge of this, e.g., before the flash is locked down, just like the non-secure firmware is 'trusted' in terms of booting chain of trust all the way into the OS. This is the model that x86 uses on UEFI systems.
Whether the secure component of that firmware update can actually *boot* is an entirely different matter, and so a firmware update payload will typically consist of a signed payload (for execution) in a signed container (for updating)
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR platforms do this. It is optional on EBBR.
There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background rather than taking the system down for a period of time.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
and u-boot performs the update ? The bracketed items [] being optional ?
I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the capsule-update-on-disk method (see below).
A question then would it not also be possible to bypass capsule submission in Linux ?
On a device designed with security in mind, none of the images (BL31, BL32, or BL33) would be able to be updated by normal world code. Image updates would probably be written by BL32. U-Boot pass the images to BL32
However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right signature (can protect against unsigned code, but cannot protect against rollbacks).
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined is there are 2 tables of function pointers: BootServices and RuntimeServices. Both are available before the call to ExitBootServices(), but only RuntimeServices are available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot currently stubs out most of the runtime services functions after ExitBootServices() is called.
g.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Fri, 26 Apr 2019 at 13:14, Udit Kumar udit.kumar@nxp.com wrote:
There is renewed interest in this approach though if secureworld firmware
has the capability of writing images while the OS is running as it would allow image updates to be performed in the background >rather than taking the system down for a period of time.
I think, secure world has capability of writing to flash, mainly for secure variables. On x86, what I recall they have two partitions on flash , one is holding firmware and another is variables. And partition which has firmware is locked after end-of-dxe, due to this they have to reset to update the image. On ARM side, specifically on our platforms, we don’t have such scheme to partition flash. Then why not to write flash in context of OS instead of doing additional reset.
Agreed. this is a perfectly valid method. We do not intend to just mimic
x86, we intend to provide a solution that can work in all cases AND take advantages of Arm architecture.
Regards Udit
-----Original Message----- From: boot-architecture boot-architecture-bounces@lists.linaro.org On Behalf Of Grant Likely Sent: Friday, April 26, 2019 4:28 PM To: Bryan O'Donoghue bryan.odonoghue@linaro.org; boot- architecture@lists.linaro.org Cc: nd nd@arm.com Subject: [EXT] Re: StandaloneMM discussion
Caution: EXT Email
On 26/04/2019 11:35, Bryan O'Donoghue wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image
authentication
can happily be handled in unpriviledged normal world code.
However for firmware image updates to be secure they absolutely need to
be
authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the
PK, KEK, DB,
or DBX variables.
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR
platforms do
this. It is optional on EBBR.
There is renewed interest in this approach though if secureworld
firmware has
the capability of writing images while the OS is running as it would
allow image
updates to be performed in the background rather than taking the system
down
for a period of time.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
and u-boot performs the update ? The bracketed items [] being optional
?
I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the
capsule-
update-on-disk method (see below).
A question then would it not also be possible to bypass capsule submission in Linux ?
On a device designed with security in mind, none of the images (BL31,
BL32, or
BL33) would be able to be updated by normal world code. Image updates
would
probably be written by BL32. U-Boot pass the images to BL32
However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right
signature (can
protect against unsigned code, but cannot protect against rollbacks).
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined
is
there are 2 tables of function pointers: BootServices and
RuntimeServices. Both
are available before the call to ExitBootServices(), but only
RuntimeServices are
available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot
currently
stubs out most of the runtime services functions after ExitBootServices() is called.
g.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.linaro.org%2Fmailman%2Flistinfo%2Fboot-
architecture&data=02%7C01
%7Cudit.kumar%40nxp.com%7Cffbc5c786c91432d9a2e08d6ca3634a6%7C686e a1d3b
c2b4c6fa92cd99c5c301635%7C0%7C0%7C636918731493779757&sdata=% 2FA38X
UlqnPzYkHajk0EAanUvCMiOnOfz37M3nk%2Bqe4A%3D&reserved=0
boot-architecture mailing list boot-architecture@lists.linaro.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lina...
o.org%2Fmailman%2Flistinfo%2Fboot- architecture&data=02%7C01%7Cudit.kumar%40nxp.com%7Cffbc5c786c91 432d9a2e08d6ca3634a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% 7C636918731493779757&sdata=%2FA38XUlqnPzYkHajk0EAanUvCMiOnOfz 37M3nk%2Bqe4A%3D&reserved=0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Fri, 26 Apr 2019 at 14:26, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Fri, 26 Apr 2019 at 12:58, Grant Likely Grant.Likely@arm.com wrote:
On 26/04/2019 11:35, Bryan O'Donoghue wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image authentication can happily be handled in unpriviledged normal world code.
However for firmware image updates to be secure they absolutely need to be authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the PK, KEK, DB, or DBX variables.
I disagree. Firmware *updates* need to be authenticated to whichever agent is in charge of writing the flash. It is perfectly reasonable for the non-secure firmware to be in charge of this, e.g., before the flash is locked down, just like the non-secure firmware is 'trusted' in terms of booting chain of trust all the way into the OS. This is the model that x86 uses on UEFI systems.
Whether the secure component of that firmware update can actually *boot* is an entirely different matter, and so a firmware update payload will typically consist of a signed payload (for execution) in a signed container (for updating)
Agreed with the condition that the agent writing directly the new firmware
cannot update the chain of trust that led to the update. So if we have an A/B partition (here partition is used in a broader sense than a disk partition or MMC partition), booted on partition A, the partition A is locked. partition B can be freely updated, including trusted software, providing that next boot partition A will deal with validating partition B.
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you
submit
a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR platforms do this. It is optional on EBBR.
There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background rather than taking the system down for a period of time.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] ->
u-boot
and u-boot performs the update ? The bracketed items [] being optional
?
I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the capsule-update-on-disk method (see below).
A question then would it not also be possible to bypass capsule submission in Linux ?
On a device designed with security in mind, none of the images (BL31, BL32, or BL33) would be able to be updated by normal world code. Image updates would probably be written by BL32. U-Boot pass the images to BL32
However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right signature (can protect against unsigned code, but cannot protect against rollbacks).
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined is there are 2 tables of function pointers: BootServices and RuntimeServices. Both are available before the call to ExitBootServices(), but only RuntimeServices are available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot currently stubs out most of the runtime services functions after ExitBootServices() is called.
g.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 26/04/2019 12:01, Francois Ozog wrote:
On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue <bryan.odonoghue@linaro.org mailto:bryan.odonoghue@linaro.org> wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote: >> I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available. > Akashi and Sughosh already have code on that. It's not 100% complete or tested > yet, but the basic concept works. Is that to say that u-boot will provide, Runtime services for EFI capsule update ?That shall be one of the few runtime services supported as well as get/set variables.
Is that the current POR ?Yes
Well - implementing the RunTime service in u-boot or TEE doesn't make much difference from the use-case I'm looking at.
It's a positive that the model we are looking at is a runtime updating - as opposed to a reset based model, which was a bit of a concern for me - thinking about how long a Capsule would need to persist in memory BootROM -> ATF/OPTEE -> uboot and then finally a jump to program the flash.
Of course as Udit pointed out, the reason x86 does a reset is because it has to. SPI flash is locked before the DXE phase.
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update. On Arm then the flow is #1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot and u-boot performs the update ? The bracketed items [] being optional ?only for the untrusted parts. S-EL3 shall update or validate the updates.
OK.
Just to clarify then. For the runtime update model.
- u-boot will implement enough in RuntimeServices to enable EFI variables CapsuleUpdate
- OP-TEE/TA Will aim to provide a similar set of functionality
But, you will be able to everything you need to do from what is being implemented in u-boot.
The TA then is extra security sugar on top, giving a more secure version of EFI variables and CapsuleUpdate ?
A question then would it not also be possible to bypass capsule submission in Linux ?In a different thread (EFIBootguard: do you follow this one too?), someone proposed that in the context of A/B partitions, Linux software agent updates a partition and the reboot cycle validates if it accepts.
There's a nearly identical proposal in the mix in ISG - with the missing bit being - where is the A/B stuff stored and how is it updated.
EFI variables, updated by a Linux agent is a nice fit.
--- bod
On Fri, 26 Apr 2019 at 14:45, Bryan O'Donoghue bryan.odonoghue@linaro.org wrote:
On 26/04/2019 12:01, Francois Ozog wrote:
On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue <bryan.odonoghue@linaro.org mailto:bryan.odonoghue@linaro.org> wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote: >> I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available. > Akashi and Sughosh already have code on that. It's not 100% complete or tested > yet, but the basic concept works. Is that to say that u-boot will provide, Runtime services for EFI capsule update ?That shall be one of the few runtime services supported as well as get/set variables.
Is that the current POR ?Yes
Well - implementing the RunTime service in u-boot or TEE doesn't make much difference from the use-case I'm looking at.
It's a positive that the model we are looking at is a runtime updating - as opposed to a reset based model, which was a bit of a concern for me - thinking about how long a Capsule would need to persist in memory BootROM -> ATF/OPTEE -> uboot and then finally a jump to program the flash.
Of course as Udit pointed out, the reason x86 does a reset is because it has to. SPI flash is locked before the DXE phase.
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmwaredoes
your update. On Arm then the flow is #1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] ->u-boot
and u-boot performs the update ? The bracketed items [] beingoptional ?
only for the untrusted parts. S-EL3 shall update or validate the updates.
OK.
Just to clarify then. For the runtime update model.
u-boot will implement enough in RuntimeServices to enable EFI variables CapsuleUpdate
OP-TEE/TA Will aim to provide a similar set of functionality
But, you will be able to everything you need to do from what is being implemented in u-boot.
The TA then is extra security sugar on top, giving a more secure version of EFI variables and CapsuleUpdate ?
The UEFI implementer in U-Boot can implement the whole process of update in its context or just pass to OPTEE or use OPTEE for a limited set of things. The runtime service is just the interface. Implementation will be free. We will provide a reference implementation for a set of boards that may use some form of OPTEE. The StandAloneMM TA is the mandatory object (if you don't have dedicated secure storage) to deal with UEFI secure storage for UEFI secure variables. There may be additional TAs such as firmwareTPM or others.
A question then would it not also be possible to bypass capsule submission in Linux ?In a different thread (EFIBootguard: do you follow this one too?), someone proposed that in the context of A/B partitions, Linux software agent updates a partition and the reboot cycle validates if it accepts.
There's a nearly identical proposal in the mix in ISG - with the missing bit being - where is the A/B stuff stored and how is it updated.
can you use EFIBootGuard that is used by CIP and with whom we also have
disccusions?
EFI variables, updated by a Linux agent is a nice fit.
bod
On 26.04.19 15:01, Francois Ozog wrote:
On Fri, 26 Apr 2019 at 14:45, Bryan O'Donoghue bryan.odonoghue@linaro.org wrote:
On 26/04/2019 12:01, Francois Ozog wrote:
On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue <bryan.odonoghue@linaro.org mailto:bryan.odonoghue@linaro.org> wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote: >> I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available. > Akashi and Sughosh already have code on that. It's not 100% complete or tested > yet, but the basic concept works. Is that to say that u-boot will provide, Runtime services for EFI capsule update ?That shall be one of the few runtime services supported as well as get/set variables. Is that the current POR ?
Yes
Well - implementing the RunTime service in u-boot or TEE doesn't make much difference from the use-case I'm looking at.
It's a positive that the model we are looking at is a runtime updating - as opposed to a reset based model, which was a bit of a concern for me - thinking about how long a Capsule would need to persist in memory BootROM -> ATF/OPTEE -> uboot and then finally a jump to program the flash.
Of course as Udit pointed out, the reason x86 does a reset is because it has to. SPI flash is locked before the DXE phase.
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmwaredoes
your update. On Arm then the flow is #1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] ->u-boot
and u-boot performs the update ? The bracketed items [] beingoptional ?
only for the untrusted parts. S-EL3 shall update or validate the updates.
OK.
Just to clarify then. For the runtime update model.
u-boot will implement enough in RuntimeServices to enable EFI variables CapsuleUpdate
OP-TEE/TA Will aim to provide a similar set of functionality
But, you will be able to everything you need to do from what is being implemented in u-boot.
The TA then is extra security sugar on top, giving a more secure version of EFI variables and CapsuleUpdate ?
The UEFI implementer in U-Boot can implement the whole process of update in its context or just pass to OPTEE or use OPTEE for a limited set of things.
If you don't have a storage that's only accessible from secure world, chances are *very* low you can safely access it from UEFI RTS because any access may conflict with the OS (clocks, pinctrl, device registers, window mappings, etc etc). So implementing anything but TA calls as U-Boot UEFI RTS is a waste of time for CapsuleUpdate IMHO.
For UEFI variables, I'm not 100% convinced we ever got to any other conclusion that the above. The main difference is that you *can* expose an in-memory cache of variables which only persist on reset. If you really have to :).
Alex
Please bear with [EXT] added in subject Tag, now a days outlook is adding this funny tag
-----Original Message----- From: boot-architecture boot-architecture-bounces@lists.linaro.org On Behalf Of Francois Ozog Sent: Friday, April 26, 2019 6:12 PM To: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Bryan O'Donoghue bryan.odonoghue@linaro.org; boot- architecture@lists.linaro.org; Grant Likely Grant.Likely@arm.com; nd nd@arm.com Subject: [EXT] Re: StandaloneMM discussion
Caution: EXT Email
On Fri, 26 Apr 2019 at 14:26, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Fri, 26 Apr 2019 at 12:58, Grant Likely Grant.Likely@arm.com wrote:
On 26/04/2019 11:35, Bryan O'Donoghue wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available.
Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image authentication can happily be handled in unpriviledged normal world
code.
However for firmware image updates to be secure they absolutely need to be authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the PK, KEK, DB, or DBX variables.
I disagree. Firmware *updates* need to be authenticated to whichever agent is in charge of writing the flash. It is perfectly reasonable for the non-secure firmware to be in charge of this, e.g., before the flash is locked down, just like the non-secure firmware is 'trusted' in terms of booting chain of trust all the way into the OS. This is the model that x86 uses on UEFI systems.
Whether the secure component of that firmware update can actually *boot* is an entirely different matter, and so a firmware update payload will typically consist of a signed payload (for execution) in a signed container (for updating)
Agreed with the condition that the agent writing directly the new firmware
cannot update the chain of trust that led to the update. So if we have an A/B partition (here partition is used in a broader sense than a disk partition or MMC partition), booted on partition A, the partition A is locked. partition B can be freely updated, including trusted software, providing that next boot partition A will deal with validating partition B.
Does *freely* means, OS is updating partition B , and at next boot if firmware finds B partition valid, it will use those images ??
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you
submit
a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR platforms do this. It is optional on EBBR.
There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background rather than taking the system down for a period of time.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] ->
u-boot
and u-boot performs the update ? The bracketed items [] being optional
?
I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the capsule-update-on-disk method (see below).
A question then would it not also be possible to bypass capsule submission in Linux ?
On a device designed with security in mind, none of the images (BL31, BL32, or BL33) would be able to be updated by normal world code. Image updates would probably be written by BL32. U-Boot pass the images to BL32
However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right signature (can protect against unsigned code, but cannot protect against rollbacks).
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I ask.
This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined is there are 2 tables of function pointers: BootServices and RuntimeServices. Both are available before the call to ExitBootServices(), but only RuntimeServices are available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot currently stubs out most of the runtime services functions after ExitBootServices() is called.
g.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F lists.linaro.org%2Fmailman%2Flistinfo%2Fboot-architecture&data
=02%7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd 0e
%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915790056 &a
mp;sdata=vtQUGIyZnZKzeBbqbKGKqjEJY0vfCSSHDU8MD9l2xpo%3D&reserv
ed=0
boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli sts.linaro.org%2Fmailman%2Flistinfo%2Fboot-architecture&data=02%
7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd0e%7 C686
ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915800061&s data
=BGeWRY5A4erpJzI8bwFxT3pemvvFVU2uULoct91Yl5U%3D&reserved=0
boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.linaro.org%2Fmailman%2Flistinfo%2Fboot-
architecture&data=02%7C01
%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd0e%7C686 ea1d3b
c2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915800061&sdata=B GeWRY5
A4erpJzI8bwFxT3pemvvFVU2uULoct91Yl5U%3D&reserved=0
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lina... o.org%2Fmailman%2Flistinfo%2Fboot- architecture&data=02%7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e 14a5ab08008d6ca44bd0e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 %7C636918793915800061&sdata=BGeWRY5A4erpJzI8bwFxT3pemvvFVU2u ULoct91Yl5U%3D&reserved=0
On Mon, 29 Apr 2019 at 08:56, Udit Kumar udit.kumar@nxp.com wrote:
Please bear with [EXT] added in subject Tag, now a days outlook is adding this funny tag
-----Original Message----- From: boot-architecture boot-architecture-bounces@lists.linaro.org On Behalf Of Francois Ozog Sent: Friday, April 26, 2019 6:12 PM To: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Bryan O'Donoghue bryan.odonoghue@linaro.org; boot- architecture@lists.linaro.org; Grant Likely Grant.Likely@arm.com; nd nd@arm.com Subject: [EXT] Re: StandaloneMM discussion
Caution: EXT Email
On Fri, 26 Apr 2019 at 14:26, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Fri, 26 Apr 2019 at 12:58, Grant Likely Grant.Likely@arm.com
wrote:
On 26/04/2019 11:35, Bryan O'Donoghue wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote:
> I’d rather see Secure Boot image authentication implemented > generically for all u-boot platforms, even when secure world > variable updates are not available. Akashi and Sughosh already have code on that. It's not 100% complete or tested yet, but the basic concept works.
Is that to say that u-boot will provide, Runtime services for EFI capsule update ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image authentication can happily be handled in unpriviledged normal
world
code.
However for firmware image updates to be secure they absolutely need to be authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the PK, KEK, DB, or DBX variables.
I disagree. Firmware *updates* need to be authenticated to whichever agent is in charge of writing the flash. It is perfectly reasonable for the non-secure firmware to be in charge of this, e.g., before the flash is locked down, just like the non-secure firmware is 'trusted' in terms of booting chain of trust all the way into the OS. This is the model that x86 uses on UEFI systems.
Whether the secure component of that firmware update can actually *boot* is an entirely different matter, and so a firmware update payload will typically consist of a signed payload (for execution) in a signed container (for updating)
Agreed with the condition that the agent writing directly the new firmware
cannot update the chain of trust that led to the update. So if we have an A/B partition (here partition is used in a broader
sense than a
disk partition or MMC partition), booted on partition A, the partition A
is locked.
partition B can be freely updated, including trusted software, providing
that next
boot partition A will deal with validating partition B.
Does *freely* means, OS is updating partition B , and at next boot if firmware finds B partition valid, it will use those images ??
Yes.
Is that the current POR ?
Maybe its a stupid question but, on x86 the way this works is you
submit
a capsule to the EFI runtime service, reboot and the EFI firmware does your update.
This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR platforms do this. It is optional on EBBR.
There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background rather than taking the system down for a period of time.
On Arm then the flow is
#1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] ->
u-boot
and u-boot performs the update ? The bracketed items [] being optional
?
I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the capsule-update-on-disk method (see below).
A question then would it not also be possible to bypass capsule submission in Linux ?
On a device designed with security in mind, none of the images (BL31, BL32, or BL33) would be able to be updated by normal world code. Image updates would probably be written by BL32. U-Boot pass the images to BL32
However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right signature (can protect against unsigned code, but cannot protect against rollbacks).
#2 Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot
with u-boot looking for say /boot/FirmwareUpdate.cap
In the second case, there's no need from Runtime services is why I
ask.
This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined is there are 2 tables of function pointers: BootServices and RuntimeServices. Both are available before the call to ExitBootServices(), but only RuntimeServices are available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot currently stubs out most of the runtime services functions after ExitBootServices() is called.
g.
bod _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F lists.linaro.org%2Fmailman%2Flistinfo%2Fboot-architecture&data
=02%7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd 0e
%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915790056 &a
mp;sdata=vtQUGIyZnZKzeBbqbKGKqjEJY0vfCSSHDU8MD9l2xpo%3D&reserv
ed=0
boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli sts.linaro.org%2Fmailman%2Flistinfo%2Fboot-architecture&data=02%
7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd0e%7 C686
ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915800061&s data
=BGeWRY5A4erpJzI8bwFxT3pemvvFVU2uULoct91Yl5U%3D&reserved=0
boot-architecture mailing list boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.linaro.org%2Fmailman%2Flistinfo%2Fboot-
architecture&data=02%7C01
%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd0e%7C686 ea1d3b
c2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915800061&sdata=B GeWRY5
A4erpJzI8bwFxT3pemvvFVU2uULoct91Yl5U%3D&reserved=0
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lina...
o.org%2Fmailman%2Flistinfo%2Fboot- architecture&data=02%7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e 14a5ab08008d6ca44bd0e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 %7C636918793915800061&sdata=BGeWRY5A4erpJzI8bwFxT3pemvvFVU2u ULoct91Yl5U%3D&reserved=0
boot-architecture@lists.linaro.org
-
Alexander Graf -
Ard Biesheuvel -
Bryan O'Donoghue -
Francois Ozog -
Grant Likely -
Ilias Apalodimas -
Udit Kumar