[cip-dev] EFIBootGuard for CIP and SecureBoot

[cip-dev] EFIBootGuard for CIP and SecureBoot

[daniel.sangorrin at toshiba.co.jp]

Hello Francois, Jan, Christian, and all

Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked. I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).

Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI application, instead of using a Linux agent such as SWUpdate. Then, I had an online meeting with Francois, director of LEDGE. I explained to Francois that in CIP we are using the Linux agent approach right now, and we are also considering the use of a UEFI application (Efibootguard) to arm a watchdog and deal with the state-machine variables (installed, testing, ok, failed..) needed for A/B software updates. Efibootguard sounds like an excellent place to collaborate with Linaro (particularly on the watchdog drivers front) because it does not strictly depend on where the firmware is flashed (UEFI capsule or Linux agent). 

> On Fri, Apr 19, 2019 at 12:48:51PM +0200, Francois Ozog wrote:
> > Hi Daniel,
> >
> > We will be conducting a UEFI gap analysis to support EFIBootGuard in U-Boot.
> >
> > As we are working on UEFI SecureBoot implementation in U-Boot, how do
> > you expect the boot process to be secured? Would U-Boot UEFI
> > SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will
> > check either grub or Linux signature?
> >
> > Please elaborate on your vision of a secured boot process.

Efibootguard is composed of two parts.
  - A UEFI application that can arm a watchdog and decide what environment (kernel, boot args, etc.) to use next depending on a set of variables (update status, highest revision, etc.) stored in FAT16 partitions.
  - A Linux application that can read and set those variables from Linux (similar to u-boot's fw_setenv). This functionality is also available in the form of a library.

As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature checks before booting into the selected kernel would be a possible solution. 

Thanks,
Daniel

[U-Boot] EFIBootGuard for CIP and SecureBoot

[daniel.sangorrin at toshiba.co.jp]

Hello Francois, Jan, Christian, and all

Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked. I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).

Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI application, instead of using a Linux agent such as SWUpdate. Then, I had an online meeting with Francois, director of LEDGE. I explained to Francois that in CIP we are using the Linux agent approach right now, and we are also considering the use of a UEFI application (Efibootguard) to arm a watchdog and deal with the state-machine variables (installed, testing, ok, failed..) needed for A/B software updates. Efibootguard sounds like an excellent place to collaborate with Linaro (particularly on the watchdog drivers front) because it does not strictly depend on where the firmware is flashed (UEFI capsule or Linux agent). 

> On Fri, Apr 19, 2019 at 12:48:51PM +0200, Francois Ozog wrote:
> > Hi Daniel,
> >
> > We will be conducting a UEFI gap analysis to support EFIBootGuard in U-Boot.
> >
> > As we are working on UEFI SecureBoot implementation in U-Boot, how do
> > you expect the boot process to be secured? Would U-Boot UEFI
> > SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will
> > check either grub or Linux signature?
> >
> > Please elaborate on your vision of a secured boot process.

Efibootguard is composed of two parts.
  - A UEFI application that can arm a watchdog and decide what environment (kernel, boot args, etc.) to use next depending on a set of variables (update status, highest revision, etc.) stored in FAT16 partitions.
  - A Linux application that can read and set those variables from Linux (similar to u-boot's fw_setenv). This functionality is also available in the form of a library.

As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature checks before booting into the selected kernel would be a possible solution. 

Thanks,
Daniel

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Jan Kiszka]

[prolonging the CCs with the efibootguard mailing list]

On 24.04.19 03:23, daniel.sangorrin at toshiba.co.jp wrote:
> Hello Francois, Jan, Christian, and all
>  EFI Boot Guard is now shipped in quite a few devices, to my knowledge not only at 
> Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked. I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).
> 
> Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI application, instead of using a Linux agent such as SWUpdate.

How would capsules help with writing to arbitrary storage, updating only files 
on filesystem, reducing the update size (binary diffs), or talking to the cloud?

> Then, I had an online meeting with Francois, director of LEDGE. I explained to Francois that in CIP we are using the Linux agent approach right now, and we are also considering the use of a UEFI application (Efibootguard) to arm a watchdog and deal with the state-machine variables (installed, testing, ok, failed..) needed for A/B software updates. Efibootguard sounds like an excellent place to collaborate with Linaro (particularly on the watchdog drivers front) because it does not strictly depend on where the firmware is flashed (UEFI capsule or Linux agent).
> 
>> On Fri, Apr 19, 2019 at 12:48:51PM +0200, Francois Ozog wrote:
>>> Hi Daniel,
>>>
>>> We will be conducting a UEFI gap analysis to support EFIBootGuard in U-Boot.
>>>
>>> As we are working on UEFI SecureBoot implementation in U-Boot, how do
>>> you expect the boot process to be secured? Would U-Boot UEFI
>>> SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will
>>> check either grub or Linux signature?
>>>
>>> Please elaborate on your vision of a secured boot process.
> 
> Efibootguard is composed of two parts.
>    - A UEFI application that can arm a watchdog and decide what environment (kernel, boot args, etc.) to use next depending on a set of variables (update status, highest revision, etc.) stored in FAT16 partitions.
>    - A Linux application that can read and set those variables from Linux (similar to u-boot's fw_setenv). This functionality is also available in the form of a library.
> 
> As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature checks before booting into the selected kernel would be a possible solution.

Secure boot is a pending feature on our to-do list. It's a bit more complicated 
than that, like secure boot is "a bit" more complicated than you think once you 
actually try to implement it. Once we do that, it's really about adding 
signature checks or relying on UEFI validating the payloads we boot for us PLUS 
ensuring the our config sections can either be validated (despite being 
volatile) or split the security-wise critical parts (specifically EFI payload 
parameters) from the less critical ones (update states) and remove the latter 
from the validation.

BTW, what we do in EFI Board Guard could also be done in any other UEFI 
bootloader, may it be grub (if you like to use that complex and fragile beast in 
production), systemd-boot or even TianoCore. But for now, it was easier - and 
more robust - to add our requirements in form of this tiny bootloader to the 
ecosystem. EFI Boot Guard is now shipped in quite a few devices, to my best 
knowledge not only at Siemens.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Jan Kiszka]

[prolonging the CCs with the efibootguard mailing list]

On 24.04.19 03:23, daniel.sangorrin at toshiba.co.jp wrote:
> Hello Francois, Jan, Christian, and all
>  EFI Boot Guard is now shipped in quite a few devices, to my knowledge not only at 
> Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked. I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).
> 
> Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI application, instead of using a Linux agent such as SWUpdate.

How would capsules help with writing to arbitrary storage, updating only files 
on filesystem, reducing the update size (binary diffs), or talking to the cloud?

> Then, I had an online meeting with Francois, director of LEDGE. I explained to Francois that in CIP we are using the Linux agent approach right now, and we are also considering the use of a UEFI application (Efibootguard) to arm a watchdog and deal with the state-machine variables (installed, testing, ok, failed..) needed for A/B software updates. Efibootguard sounds like an excellent place to collaborate with Linaro (particularly on the watchdog drivers front) because it does not strictly depend on where the firmware is flashed (UEFI capsule or Linux agent).
> 
>> On Fri, Apr 19, 2019 at 12:48:51PM +0200, Francois Ozog wrote:
>>> Hi Daniel,
>>>
>>> We will be conducting a UEFI gap analysis to support EFIBootGuard in U-Boot.
>>>
>>> As we are working on UEFI SecureBoot implementation in U-Boot, how do
>>> you expect the boot process to be secured? Would U-Boot UEFI
>>> SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will
>>> check either grub or Linux signature?
>>>
>>> Please elaborate on your vision of a secured boot process.
> 
> Efibootguard is composed of two parts.
>    - A UEFI application that can arm a watchdog and decide what environment (kernel, boot args, etc.) to use next depending on a set of variables (update status, highest revision, etc.) stored in FAT16 partitions.
>    - A Linux application that can read and set those variables from Linux (similar to u-boot's fw_setenv). This functionality is also available in the form of a library.
> 
> As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature checks before booting into the selected kernel would be a possible solution.

Secure boot is a pending feature on our to-do list. It's a bit more complicated 
than that, like secure boot is "a bit" more complicated than you think once you 
actually try to implement it. Once we do that, it's really about adding 
signature checks or relying on UEFI validating the payloads we boot for us PLUS 
ensuring the our config sections can either be validated (despite being 
volatile) or split the security-wise critical parts (specifically EFI payload 
parameters) from the less critical ones (update states) and remove the latter 
from the validation.

BTW, what we do in EFI Board Guard could also be done in any other UEFI 
bootloader, may it be grub (if you like to use that complex and fragile beast in 
production), systemd-boot or even TianoCore. But for now, it was easier - and 
more robust - to add our requirements in form of this tiny bootloader to the 
ecosystem. EFI Boot Guard is now shipped in quite a few devices, to my best 
knowledge not only at Siemens.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Grant Likely]

On 24/04/2019 02:23, daniel.sangorrin at toshiba.co.jp wrote:
> Hello Francois, Jan, Christian, and all
> 
> Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked. I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).

Hmmm, that's weird. The boot-architecture list doesn't require approval 
to subscribe. It just requires confirmation of email address. I think 
there is a problem with lists.linaro.org. I'll send an IT support 
request to Linaro.

Regardless, I've approved this post and added you to the allowed senders 
list. You can post freely. :-)

g.

> Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI application, instead of using a Linux agent such as SWUpdate. Then, I had an online meeting with Francois, director of LEDGE. I explained to Francois that in CIP we are using the Linux agent approach right now, and we are also considering the use of a UEFI application (Efibootguard) to arm a watchdog and deal with the state-machine variables (installed, testing, ok, failed..) needed for A/B software updates. Efibootguard sounds like an excellent place to collaborate with Linaro (particularly on the watchdog drivers front) because it does not strictly depend on where the firmware is flashed (UEFI capsule or Linux agent).
> 
>> On Fri, Apr 19, 2019 at 12:48:51PM +0200, Francois Ozog wrote:
>>> Hi Daniel,
>>>
>>> We will be conducting a UEFI gap analysis to support EFIBootGuard in U-Boot.
>>>
>>> As we are working on UEFI SecureBoot implementation in U-Boot, how do
>>> you expect the boot process to be secured? Would U-Boot UEFI
>>> SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will
>>> check either grub or Linux signature?
>>>
>>> Please elaborate on your vision of a secured boot process.
> 
> Efibootguard is composed of two parts.
>    - A UEFI application that can arm a watchdog and decide what environment (kernel, boot args, etc.) to use next depending on a set of variables (update status, highest revision, etc.) stored in FAT16 partitions.
>    - A Linux application that can read and set those variables from Linux (similar to u-boot's fw_setenv). This functionality is also available in the form of a library.
> 
> As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature checks before booting into the selected kernel would be a possible solution.
> 
> Thanks,
> Daniel
> 
> 
> 
> _______________________________________________
> boot-architecture mailing list
> boot-architecture at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
> 

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Grant Likely]

On 24/04/2019 02:23, daniel.sangorrin at toshiba.co.jp wrote:
> Hello Francois, Jan, Christian, and all
> 
> Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked. I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).

Hmmm, that's weird. The boot-architecture list doesn't require approval 
to subscribe. It just requires confirmation of email address. I think 
there is a problem with lists.linaro.org. I'll send an IT support 
request to Linaro.

Regardless, I've approved this post and added you to the allowed senders 
list. You can post freely. :-)

g.

> Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI application, instead of using a Linux agent such as SWUpdate. Then, I had an online meeting with Francois, director of LEDGE. I explained to Francois that in CIP we are using the Linux agent approach right now, and we are also considering the use of a UEFI application (Efibootguard) to arm a watchdog and deal with the state-machine variables (installed, testing, ok, failed..) needed for A/B software updates. Efibootguard sounds like an excellent place to collaborate with Linaro (particularly on the watchdog drivers front) because it does not strictly depend on where the firmware is flashed (UEFI capsule or Linux agent).
> 
>> On Fri, Apr 19, 2019 at 12:48:51PM +0200, Francois Ozog wrote:
>>> Hi Daniel,
>>>
>>> We will be conducting a UEFI gap analysis to support EFIBootGuard in U-Boot.
>>>
>>> As we are working on UEFI SecureBoot implementation in U-Boot, how do
>>> you expect the boot process to be secured? Would U-Boot UEFI
>>> SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will
>>> check either grub or Linux signature?
>>>
>>> Please elaborate on your vision of a secured boot process.
> 
> Efibootguard is composed of two parts.
>    - A UEFI application that can arm a watchdog and decide what environment (kernel, boot args, etc.) to use next depending on a set of variables (update status, highest revision, etc.) stored in FAT16 partitions.
>    - A Linux application that can read and set those variables from Linux (similar to u-boot's fw_setenv). This functionality is also available in the form of a library.
> 
> As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature checks before booting into the selected kernel would be a possible solution.
> 
> Thanks,
> Daniel
> 
> 
> 
> _______________________________________________
> boot-architecture mailing list
> boot-architecture at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
> 

[cip-dev] EFIBootGuard for CIP and SecureBoot

[daniel.sangorrin at toshiba.co.jp]

Hi Jan, Francois:

Grant: thanks!

> From: Jan Kiszka <jan.kiszka@siemens.com>
> On 24.04.19 03:23, daniel.sangorrin at toshiba.co.jp wrote:
> > Hello Francois, Jan, Christian, and all
> >  EFI Boot Guard is now shipped in quite a few devices, to my knowledge not only at
> > Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my
> subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked.
> I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing
> list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).
> >
> > Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on
> a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI
> application, instead of using a Linux agent such as SWUpdate.
> 
> How would capsules help with writing to arbitrary storage, updating only files
> on filesystem, reducing the update size (binary diffs), or talking to the cloud?

- arbitrary storage: I guess they can only write to what is supported by the machine's UEFI implementation.
- updating only files on filesystem: I assume this is out of scope in their architecture (Francois: do you want to support file-based updates or only block-based ones?)
- reducing the update size (binary diffs), or talking to the cloud: they will do that from non-secure Linux. It would be dangerous to use a fragile network stack from an UEFI application or the secure world. In that sense, they also need a Linux agent.

I believe that LEDGE is looking for a software update method that works the same on any machine (that supports UEFI). To do that they want to use the UEFI interfaces/services. They also want the ability to update the TrustZone secure world (you can't do that unless you have enough privileges).

> > As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature
> checks before booting into the selected kernel would be a possible solution.
> 
> Secure boot is a pending feature on our to-do list. It's a bit more complicated
> than that, like secure boot is "a bit" more complicated than you think once you
> actually try to implement it. Once we do that, it's really about adding
> signature checks or relying on UEFI validating the payloads we boot for us PLUS
> ensuring the our config sections can either be validated (despite being
> volatile) or split the security-wise critical parts (specifically EFI payload
> parameters) from the less critical ones (update states) and remove the latter
> from the validation.

I suppose that those "bits" are hard to predict until you start the implementation. From an architectural point of view, I guess that the "revision" variables will need to be secured to avoid downgrades (e.g. an attacker causing a rollback to a previous revision of the OS image). 

> BTW, what we do in EFI Board Guard could also be done in any other UEFI
> bootloader, may it be grub (if you like to use that complex and fragile beast in
> production), systemd-boot or even TianoCore. But for now, it was easier - and
> more robust - to add our requirements in form of this tiny bootloader to the
> ecosystem. EFI Boot Guard is now shipped in quite a few devices, to my best
> knowledge not only at Siemens.

Jan: do you have a schedule or a list of tasks that need to be done?
Francois: what direction should we take from here?

Thanks,
Daniel

[U-Boot] EFIBootGuard for CIP and SecureBoot

[daniel.sangorrin at toshiba.co.jp]

Hi Jan, Francois:

Grant: thanks!

> From: Jan Kiszka <jan.kiszka@siemens.com>
> On 24.04.19 03:23, daniel.sangorrin at toshiba.co.jp wrote:
> > Hello Francois, Jan, Christian, and all
> >  EFI Boot Guard is now shipped in quite a few devices, to my knowledge not only at
> > Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my
> subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked.
> I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing
> list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).
> >
> > Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on
> a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI
> application, instead of using a Linux agent such as SWUpdate.
> 
> How would capsules help with writing to arbitrary storage, updating only files
> on filesystem, reducing the update size (binary diffs), or talking to the cloud?

- arbitrary storage: I guess they can only write to what is supported by the machine's UEFI implementation.
- updating only files on filesystem: I assume this is out of scope in their architecture (Francois: do you want to support file-based updates or only block-based ones?)
- reducing the update size (binary diffs), or talking to the cloud: they will do that from non-secure Linux. It would be dangerous to use a fragile network stack from an UEFI application or the secure world. In that sense, they also need a Linux agent.

I believe that LEDGE is looking for a software update method that works the same on any machine (that supports UEFI). To do that they want to use the UEFI interfaces/services. They also want the ability to update the TrustZone secure world (you can't do that unless you have enough privileges).

> > As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature
> checks before booting into the selected kernel would be a possible solution.
> 
> Secure boot is a pending feature on our to-do list. It's a bit more complicated
> than that, like secure boot is "a bit" more complicated than you think once you
> actually try to implement it. Once we do that, it's really about adding
> signature checks or relying on UEFI validating the payloads we boot for us PLUS
> ensuring the our config sections can either be validated (despite being
> volatile) or split the security-wise critical parts (specifically EFI payload
> parameters) from the less critical ones (update states) and remove the latter
> from the validation.

I suppose that those "bits" are hard to predict until you start the implementation. From an architectural point of view, I guess that the "revision" variables will need to be secured to avoid downgrades (e.g. an attacker causing a rollback to a previous revision of the OS image). 

> BTW, what we do in EFI Board Guard could also be done in any other UEFI
> bootloader, may it be grub (if you like to use that complex and fragile beast in
> production), systemd-boot or even TianoCore. But for now, it was easier - and
> more robust - to add our requirements in form of this tiny bootloader to the
> ecosystem. EFI Boot Guard is now shipped in quite a few devices, to my best
> knowledge not only at Siemens.

Jan: do you have a schedule or a list of tasks that need to be done?
Francois: what direction should we take from here?

Thanks,
Daniel

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Christian Storm]

Hi,

> > > Background: during the last Linaro connect in Bangkok I was told
> > > that Linaro Edge (LEDGE) were working on a secure software update
> > > mechanism based on UEFI capsules that would flash firmware updates
> > > from a UEFI application, instead of using a Linux agent such as
> > > SWUpdate.
> > 
> > How would capsules help with writing to arbitrary storage, updating
> > only files on filesystem, reducing the update size (binary diffs),
> > or talking to the cloud?
> 
> - arbitrary storage: I guess they can only write to what is supported
>   by the machine's UEFI implementation.
> 
> - updating only files on filesystem: I assume this is out of scope in
>   their architecture (Francois: do you want to support file-based
>   updates or only block-based ones?)

> - reducing the update size (binary diffs), or talking to the cloud:
>   they will do that from non-secure Linux. It would be dangerous to use
>   a fragile network stack from an UEFI application or the secure world.
>   In that sense, they also need a Linux agent.

If I understand the idea correctly, there's then a Linux companion agent
that does, e.g., the cloud communication and sets up the update payload
to be consumed and applied by the UEFI firmware update application. The
actual update action will take place on reboot, e.g., flashing the
inactive partition in an A/B setup and thereafter booting into the newly
flashed, then active partition.

If so, this would prolong the time the system is unavailable due to disk
flashing I/O in the UEFI firmware update application compared to flashing
the inactive partition from within Linux and have the bootloader just
switch the to be booted partitions.

Generally, but in particular regarding binary diffs, a binary diff
application mechanism would have to be implemented and maintained in the
UEFI realm as opposed to "just" using the respective shared libraries
(e.g. librsync, casync, ...) in the Linux realm. Granted, one could
come up with a unified format to which the output of, e.g, librsync's rdiff
or a casync run is converted but nonetheless, this creates some porting/
implementation and maintenance effort.


Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 M?nchen, Germany

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Christian Storm]

Hi,

> > > Background: during the last Linaro connect in Bangkok I was told
> > > that Linaro Edge (LEDGE) were working on a secure software update
> > > mechanism based on UEFI capsules that would flash firmware updates
> > > from a UEFI application, instead of using a Linux agent such as
> > > SWUpdate.
> > 
> > How would capsules help with writing to arbitrary storage, updating
> > only files on filesystem, reducing the update size (binary diffs),
> > or talking to the cloud?
> 
> - arbitrary storage: I guess they can only write to what is supported
>   by the machine's UEFI implementation.
> 
> - updating only files on filesystem: I assume this is out of scope in
>   their architecture (Francois: do you want to support file-based
>   updates or only block-based ones?)

> - reducing the update size (binary diffs), or talking to the cloud:
>   they will do that from non-secure Linux. It would be dangerous to use
>   a fragile network stack from an UEFI application or the secure world.
>   In that sense, they also need a Linux agent.

If I understand the idea correctly, there's then a Linux companion agent
that does, e.g., the cloud communication and sets up the update payload
to be consumed and applied by the UEFI firmware update application. The
actual update action will take place on reboot, e.g., flashing the
inactive partition in an A/B setup and thereafter booting into the newly
flashed, then active partition.

If so, this would prolong the time the system is unavailable due to disk
flashing I/O in the UEFI firmware update application compared to flashing
the inactive partition from within Linux and have the bootloader just
switch the to be booted partitions.

Generally, but in particular regarding binary diffs, a binary diff
application mechanism would have to be implemented and maintained in the
UEFI realm as opposed to "just" using the respective shared libraries
(e.g. librsync, casync, ...) in the Linux realm. Granted, one could
come up with a unified format to which the output of, e.g, librsync's rdiff
or a casync run is converted but nonetheless, this creates some porting/
implementation and maintenance effort.


Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Francois Ozog]

On Fri, 26 Apr 2019 at 10:30, Christian Storm
<christian.storm@siemens.com> wrote:
>
> Hi,
>
> > > > Background: during the last Linaro connect in Bangkok I was told
> > > > that Linaro Edge (LEDGE) were working on a secure software update
> > > > mechanism based on UEFI capsules that would flash firmware updates
> > > > from a UEFI application, instead of using a Linux agent such as
> > > > SWUpdate.
> > >
> > > How would capsules help with writing to arbitrary storage, updating
> > > only files on filesystem, reducing the update size (binary diffs),
> > > or talking to the cloud?
> >

See below
>
> > - arbitrary storage: I guess they can only write to what is supported
> >   by the machine's UEFI implementation.
> >

Yes, see below
>
> > - updating only files on filesystem: I assume this is out of scope in
> >   their architecture (Francois: do you want to support file-based
> >   updates or only block-based ones?)
>
Both, see below
>
> > - reducing the update size (binary diffs), or talking to the cloud:
> >   they will do that from non-secure Linux. It would be dangerous to use
> >   a fragile network stack from an UEFI application or the secure world.
> >   In that sense, they also need a Linux agent.
>
> If I understand the idea correctly, there's then a Linux companion agent
> that does, e.g., the cloud communication and sets up the update payload
> to be consumed and applied by the UEFI firmware update application. The
> actual update action will take place on reboot, e.g., flashing the
> inactive partition in an A/B setup and thereafter booting into the newly
> flashed, then active partition.
>
> If so, this would prolong the time the system is unavailable due to disk
> flashing I/O in the UEFI firmware update application compared to flashing
> the inactive partition from within Linux and have the bootloader just
> switch the to be booted partitions.
>
> Generally, but in particular regarding binary diffs, a binary diff
> application mechanism would have to be implemented and maintained in the
> UEFI realm as opposed to "just" using the respective shared libraries
> (e.g. librsync, casync, ...) in the Linux realm. Granted, one could
> come up with a unified format to which the output of, e.g, librsync's rdiff
> or a casync run is converted but nonetheless, this creates some porting/
> implementation and maintenance effort.
>
>
Here are the guiding principles of our efforts :
0) we want a cross architecture (x86/Arm/...), cross vendor and cross
processor model update solution
1) untrusted world cannot update trusted world
2) what the UEFI implementation does with the capsule is platform specific
3) the update capsule payload is opaque

1) is a "philosophy" decision. When you have a root of trust down to
the operating system. So in theory everything should be fine. But the
attack surface is such that we can't rule out hacking (and history
prove this is unfortunately a safe assumption). In addition, there may
be liability aspects related to the who does the update: the hardware
platform administrator may not be the legal entity than the operating
system administrator. For instance:
-  on Packet.net could, a customer can flash up to the BL33 untrusted
firmware but that is all.
- A surveillance camera can be operated by city personnel but only law
enforcement agency can see raw video (un-blurred faces and licence
plates). This can be implemented by a derivative of OPTEE SecureMedia
Path but if you allow untrusted world to update the trusted one, city
personnel can overcome the legal restriction.
With 1) this means that even U-Boot code shall not be able/allowed to
update S-EL3 firmware (be it Trusted Firmware A or something else),
Secure EL1/0 software (OPTEE and its applications or something else).
If possible, allowing the operating system administrator to
selectively (BL33 is OK but not S-EL3) update firmware is at least
platform dependent. Hence defeats 0)

With 2) we do not impose reboot to update. Some platform may impose
reboot or some designers will prefer reboot. We say that there is a
chain of responsibility for updates.
So it is perfectly OK to have a Linux software agent receive an update
by any mean (network, USB, serial...). The agent will pack this (or
those) into a capsule and push it to UEFI implementation.
The UEFI implementation (U-Boot or Tianocore) will then do whatever it
pleases for the update providing it complies with 1) So the UEFI
implementation can live update up to BL33 firmware.
Should the update be targeted to secure world, then the UEFI
implementation can pass it to S-EL3 for update (platform specific)
which means the update can also be live. It is a designer decision.

With 3) we have flexibility but sometimes too much flexibility is a
problem. Alexander Graf suggested we can use a FIT object to pass
diverse objects. It is "half" opaque but I really like the idea.
The contents of individual FIT components can be blocks to be placed
at a fix location in a NOR flash or a file, no importance.

What do everyone think about those design principles ?

>
> Kind regards,
>    Christian
>
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 M?nchen, Germany



-- 
Fran?ois-Fr?d?ric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Francois Ozog]

On Fri, 26 Apr 2019 at 10:30, Christian Storm
<christian.storm@siemens.com> wrote:
>
> Hi,
>
> > > > Background: during the last Linaro connect in Bangkok I was told
> > > > that Linaro Edge (LEDGE) were working on a secure software update
> > > > mechanism based on UEFI capsules that would flash firmware updates
> > > > from a UEFI application, instead of using a Linux agent such as
> > > > SWUpdate.
> > >
> > > How would capsules help with writing to arbitrary storage, updating
> > > only files on filesystem, reducing the update size (binary diffs),
> > > or talking to the cloud?
> >

See below
>
> > - arbitrary storage: I guess they can only write to what is supported
> >   by the machine's UEFI implementation.
> >

Yes, see below
>
> > - updating only files on filesystem: I assume this is out of scope in
> >   their architecture (Francois: do you want to support file-based
> >   updates or only block-based ones?)
>
Both, see below
>
> > - reducing the update size (binary diffs), or talking to the cloud:
> >   they will do that from non-secure Linux. It would be dangerous to use
> >   a fragile network stack from an UEFI application or the secure world.
> >   In that sense, they also need a Linux agent.
>
> If I understand the idea correctly, there's then a Linux companion agent
> that does, e.g., the cloud communication and sets up the update payload
> to be consumed and applied by the UEFI firmware update application. The
> actual update action will take place on reboot, e.g., flashing the
> inactive partition in an A/B setup and thereafter booting into the newly
> flashed, then active partition.
>
> If so, this would prolong the time the system is unavailable due to disk
> flashing I/O in the UEFI firmware update application compared to flashing
> the inactive partition from within Linux and have the bootloader just
> switch the to be booted partitions.
>
> Generally, but in particular regarding binary diffs, a binary diff
> application mechanism would have to be implemented and maintained in the
> UEFI realm as opposed to "just" using the respective shared libraries
> (e.g. librsync, casync, ...) in the Linux realm. Granted, one could
> come up with a unified format to which the output of, e.g, librsync's rdiff
> or a casync run is converted but nonetheless, this creates some porting/
> implementation and maintenance effort.
>
>
Here are the guiding principles of our efforts :
0) we want a cross architecture (x86/Arm/...), cross vendor and cross
processor model update solution
1) untrusted world cannot update trusted world
2) what the UEFI implementation does with the capsule is platform specific
3) the update capsule payload is opaque

1) is a "philosophy" decision. When you have a root of trust down to
the operating system. So in theory everything should be fine. But the
attack surface is such that we can't rule out hacking (and history
prove this is unfortunately a safe assumption). In addition, there may
be liability aspects related to the who does the update: the hardware
platform administrator may not be the legal entity than the operating
system administrator. For instance:
-  on Packet.net could, a customer can flash up to the BL33 untrusted
firmware but that is all.
- A surveillance camera can be operated by city personnel but only law
enforcement agency can see raw video (un-blurred faces and licence
plates). This can be implemented by a derivative of OPTEE SecureMedia
Path but if you allow untrusted world to update the trusted one, city
personnel can overcome the legal restriction.
With 1) this means that even U-Boot code shall not be able/allowed to
update S-EL3 firmware (be it Trusted Firmware A or something else),
Secure EL1/0 software (OPTEE and its applications or something else).
If possible, allowing the operating system administrator to
selectively (BL33 is OK but not S-EL3) update firmware is at least
platform dependent. Hence defeats 0)

With 2) we do not impose reboot to update. Some platform may impose
reboot or some designers will prefer reboot. We say that there is a
chain of responsibility for updates.
So it is perfectly OK to have a Linux software agent receive an update
by any mean (network, USB, serial...). The agent will pack this (or
those) into a capsule and push it to UEFI implementation.
The UEFI implementation (U-Boot or Tianocore) will then do whatever it
pleases for the update providing it complies with 1) So the UEFI
implementation can live update up to BL33 firmware.
Should the update be targeted to secure world, then the UEFI
implementation can pass it to S-EL3 for update (platform specific)
which means the update can also be live. It is a designer decision.

With 3) we have flexibility but sometimes too much flexibility is a
problem. Alexander Graf suggested we can use a FIT object to pass
diverse objects. It is "half" opaque but I really like the idea.
The contents of individual FIT components can be blocks to be placed
at a fix location in a NOR flash or a file, no importance.

What do everyone think about those design principles ?

>
> Kind regards,
>    Christian
>
> --
> Dr. Christian Storm
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Otto-Hahn-Ring 6, 81739 München, Germany



-- 
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Jan Kiszka]

On 26.04.19 11:07, Francois Ozog wrote:
> On Fri, 26 Apr 2019 at 10:30, Christian Storm
> <christian.storm@siemens.com> wrote:
>>
>> Hi,
>>
>>>>> Background: during the last Linaro connect in Bangkok I was told
>>>>> that Linaro Edge (LEDGE) were working on a secure software update
>>>>> mechanism based on UEFI capsules that would flash firmware updates
>>>>> from a UEFI application, instead of using a Linux agent such as
>>>>> SWUpdate.
>>>>
>>>> How would capsules help with writing to arbitrary storage, updating
>>>> only files on filesystem, reducing the update size (binary diffs),
>>>> or talking to the cloud?
>>>
> 
> See below
>>
>>> - arbitrary storage: I guess they can only write to what is supported
>>>    by the machine's UEFI implementation.
>>>
> 
> Yes, see below
>>
>>> - updating only files on filesystem: I assume this is out of scope in
>>>    their architecture (Francois: do you want to support file-based
>>>    updates or only block-based ones?)
>>
> Both, see below
>>
>>> - reducing the update size (binary diffs), or talking to the cloud:
>>>    they will do that from non-secure Linux. It would be dangerous to use
>>>    a fragile network stack from an UEFI application or the secure world.
>>>    In that sense, they also need a Linux agent.
>>
>> If I understand the idea correctly, there's then a Linux companion agent
>> that does, e.g., the cloud communication and sets up the update payload
>> to be consumed and applied by the UEFI firmware update application. The
>> actual update action will take place on reboot, e.g., flashing the
>> inactive partition in an A/B setup and thereafter booting into the newly
>> flashed, then active partition.
>>
>> If so, this would prolong the time the system is unavailable due to disk
>> flashing I/O in the UEFI firmware update application compared to flashing
>> the inactive partition from within Linux and have the bootloader just
>> switch the to be booted partitions.
>>
>> Generally, but in particular regarding binary diffs, a binary diff
>> application mechanism would have to be implemented and maintained in the
>> UEFI realm as opposed to "just" using the respective shared libraries
>> (e.g. librsync, casync, ...) in the Linux realm. Granted, one could
>> come up with a unified format to which the output of, e.g, librsync's rdiff
>> or a casync run is converted but nonetheless, this creates some porting/
>> implementation and maintenance effort.
>>
>>
> Here are the guiding principles of our efforts :
> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
> processor model update solution
> 1) untrusted world cannot update trusted world

Conceptually, it can. It's a matter of validating the update by the trusted 
world before using it. A trusted instance can allow an untrusted one to write 
version 2, validate that before switching to it, and stick with version 1 if 
that fails.

> 2) what the UEFI implementation does with the capsule is platform specific
> 3) the update capsule payload is opaque
> 
> 1) is a "philosophy" decision. When you have a root of trust down to
> the operating system. So in theory everything should be fine. But the
> attack surface is such that we can't rule out hacking (and history
> prove this is unfortunately a safe assumption). In addition, there may
> be liability aspects related to the who does the update: the hardware
> platform administrator may not be the legal entity than the operating
> system administrator. For instance:
> -  on Packet.net could, a customer can flash up to the BL33 untrusted
> firmware but that is all.
> - A surveillance camera can be operated by city personnel but only law
> enforcement agency can see raw video (un-blurred faces and licence
> plates). This can be implemented by a derivative of OPTEE SecureMedia
> Path but if you allow untrusted world to update the trusted one, city
> personnel can overcome the legal restriction.
> With 1) this means that even U-Boot code shall not be able/allowed to
> update S-EL3 firmware (be it Trusted Firmware A or something else),
> Secure EL1/0 software (OPTEE and its applications or something else).
> If possible, allowing the operating system administrator to
> selectively (BL33 is OK but not S-EL3) update firmware is at least
> platform dependent. Hence defeats 0)
> 
> With 2) we do not impose reboot to update. Some platform may impose
> reboot or some designers will prefer reboot. We say that there is a
> chain of responsibility for updates.
> So it is perfectly OK to have a Linux software agent receive an update
> by any mean (network, USB, serial...). The agent will pack this (or
> those) into a capsule and push it to UEFI implementation.
> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
> pleases for the update providing it complies with 1) So the UEFI
> implementation can live update up to BL33 firmware.
> Should the update be targeted to secure world, then the UEFI
> implementation can pass it to S-EL3 for update (platform specific)
> which means the update can also be live. It is a designer decision.
> 
> With 3) we have flexibility but sometimes too much flexibility is a
> problem. Alexander Graf suggested we can use a FIT object to pass
> diverse objects. It is "half" opaque but I really like the idea.
> The contents of individual FIT components can be blocks to be placed
> at a fix location in a NOR flash or a file, no importance.
> 
> What do everyone think about those design principles ?
> 

UEFI and capsules can be fine for those platform that support it (and it's still 
a rare feature) and for stuff like boot and peripheral firmware. I don't think 
it's a wise, future-proof idea to use it for more.

UEFI is not a very healthy ecosystem yet, and I'm personally skeptical it will 
evolve towards that (looking at that as both a user as well as an OEM). It's not 
even present in quite a few of our use cases. In some it will never be - think 
of safety-critical system: not affordable with such a complex approach like 
UEFI. It should not expand further into OS domains. Updating complete 
filesystems and their content is beyond its duties. We have all the required, 
tested, matured means for the OS in the OS. For firmware, it can be an option - 
if that firmware is UEFI compliant, with all needed options.

So let's use UEFI and capsules as a one possible building block in the design, 
but not as the cornerstone. Just like we do mandate that all updates must be 
served and managed by our IoT cloud ;).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Jan Kiszka]

On 26.04.19 11:07, Francois Ozog wrote:
> On Fri, 26 Apr 2019 at 10:30, Christian Storm
> <christian.storm@siemens.com> wrote:
>>
>> Hi,
>>
>>>>> Background: during the last Linaro connect in Bangkok I was told
>>>>> that Linaro Edge (LEDGE) were working on a secure software update
>>>>> mechanism based on UEFI capsules that would flash firmware updates
>>>>> from a UEFI application, instead of using a Linux agent such as
>>>>> SWUpdate.
>>>>
>>>> How would capsules help with writing to arbitrary storage, updating
>>>> only files on filesystem, reducing the update size (binary diffs),
>>>> or talking to the cloud?
>>>
> 
> See below
>>
>>> - arbitrary storage: I guess they can only write to what is supported
>>>    by the machine's UEFI implementation.
>>>
> 
> Yes, see below
>>
>>> - updating only files on filesystem: I assume this is out of scope in
>>>    their architecture (Francois: do you want to support file-based
>>>    updates or only block-based ones?)
>>
> Both, see below
>>
>>> - reducing the update size (binary diffs), or talking to the cloud:
>>>    they will do that from non-secure Linux. It would be dangerous to use
>>>    a fragile network stack from an UEFI application or the secure world.
>>>    In that sense, they also need a Linux agent.
>>
>> If I understand the idea correctly, there's then a Linux companion agent
>> that does, e.g., the cloud communication and sets up the update payload
>> to be consumed and applied by the UEFI firmware update application. The
>> actual update action will take place on reboot, e.g., flashing the
>> inactive partition in an A/B setup and thereafter booting into the newly
>> flashed, then active partition.
>>
>> If so, this would prolong the time the system is unavailable due to disk
>> flashing I/O in the UEFI firmware update application compared to flashing
>> the inactive partition from within Linux and have the bootloader just
>> switch the to be booted partitions.
>>
>> Generally, but in particular regarding binary diffs, a binary diff
>> application mechanism would have to be implemented and maintained in the
>> UEFI realm as opposed to "just" using the respective shared libraries
>> (e.g. librsync, casync, ...) in the Linux realm. Granted, one could
>> come up with a unified format to which the output of, e.g, librsync's rdiff
>> or a casync run is converted but nonetheless, this creates some porting/
>> implementation and maintenance effort.
>>
>>
> Here are the guiding principles of our efforts :
> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
> processor model update solution
> 1) untrusted world cannot update trusted world

Conceptually, it can. It's a matter of validating the update by the trusted 
world before using it. A trusted instance can allow an untrusted one to write 
version 2, validate that before switching to it, and stick with version 1 if 
that fails.

> 2) what the UEFI implementation does with the capsule is platform specific
> 3) the update capsule payload is opaque
> 
> 1) is a "philosophy" decision. When you have a root of trust down to
> the operating system. So in theory everything should be fine. But the
> attack surface is such that we can't rule out hacking (and history
> prove this is unfortunately a safe assumption). In addition, there may
> be liability aspects related to the who does the update: the hardware
> platform administrator may not be the legal entity than the operating
> system administrator. For instance:
> -  on Packet.net could, a customer can flash up to the BL33 untrusted
> firmware but that is all.
> - A surveillance camera can be operated by city personnel but only law
> enforcement agency can see raw video (un-blurred faces and licence
> plates). This can be implemented by a derivative of OPTEE SecureMedia
> Path but if you allow untrusted world to update the trusted one, city
> personnel can overcome the legal restriction.
> With 1) this means that even U-Boot code shall not be able/allowed to
> update S-EL3 firmware (be it Trusted Firmware A or something else),
> Secure EL1/0 software (OPTEE and its applications or something else).
> If possible, allowing the operating system administrator to
> selectively (BL33 is OK but not S-EL3) update firmware is at least
> platform dependent. Hence defeats 0)
> 
> With 2) we do not impose reboot to update. Some platform may impose
> reboot or some designers will prefer reboot. We say that there is a
> chain of responsibility for updates.
> So it is perfectly OK to have a Linux software agent receive an update
> by any mean (network, USB, serial...). The agent will pack this (or
> those) into a capsule and push it to UEFI implementation.
> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
> pleases for the update providing it complies with 1) So the UEFI
> implementation can live update up to BL33 firmware.
> Should the update be targeted to secure world, then the UEFI
> implementation can pass it to S-EL3 for update (platform specific)
> which means the update can also be live. It is a designer decision.
> 
> With 3) we have flexibility but sometimes too much flexibility is a
> problem. Alexander Graf suggested we can use a FIT object to pass
> diverse objects. It is "half" opaque but I really like the idea.
> The contents of individual FIT components can be blocks to be placed
> at a fix location in a NOR flash or a file, no importance.
> 
> What do everyone think about those design principles ?
> 

UEFI and capsules can be fine for those platform that support it (and it's still 
a rare feature) and for stuff like boot and peripheral firmware. I don't think 
it's a wise, future-proof idea to use it for more.

UEFI is not a very healthy ecosystem yet, and I'm personally skeptical it will 
evolve towards that (looking at that as both a user as well as an OEM). It's not 
even present in quite a few of our use cases. In some it will never be - think 
of safety-critical system: not affordable with such a complex approach like 
UEFI. It should not expand further into OS domains. Updating complete 
filesystems and their content is beyond its duties. We have all the required, 
tested, matured means for the OS in the OS. For firmware, it can be an option - 
if that firmware is UEFI compliant, with all needed options.

So let's use UEFI and capsules as a one possible building block in the design, 
but not as the cornerstone. Just like we do mandate that all updates must be 
served and managed by our IoT cloud ;).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Grant Likely]

On 26/04/2019 10:49, Jan Kiszka wrote:
> On 26.04.19 11:07, Francois Ozog wrote:
[...]
>> Here are the guiding principles of our efforts :
>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>> processor model update solution
>> 1) untrusted world cannot update trusted world
> 
> Conceptually, it can. It's a matter of validating the update by the 
> trusted world before using it. A trusted instance can allow an untrusted 
> one to write version 2, validate that before switching to it, and stick 
> with version 1 if that fails.
> 
>> 2) what the UEFI implementation does with the capsule is platform 
>> specific
>> 3) the update capsule payload is opaque
>>
>> 1) is a "philosophy" decision. When you have a root of trust down to
>> the operating system. So in theory everything should be fine. But the
>> attack surface is such that we can't rule out hacking (and history
>> prove this is unfortunately a safe assumption). In addition, there may
>> be liability aspects related to the who does the update: the hardware
>> platform administrator may not be the legal entity than the operating
>> system administrator. For instance:
>> -? on Packet.net could, a customer can flash up to the BL33 untrusted
>> firmware but that is all.
>> - A surveillance camera can be operated by city personnel but only law
>> enforcement agency can see raw video (un-blurred faces and licence
>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>> Path but if you allow untrusted world to update the trusted one, city
>> personnel can overcome the legal restriction.
>> With 1) this means that even U-Boot code shall not be able/allowed to
>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>> Secure EL1/0 software (OPTEE and its applications or something else).
>> If possible, allowing the operating system administrator to
>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>> platform dependent. Hence defeats 0)
>>
>> With 2) we do not impose reboot to update. Some platform may impose
>> reboot or some designers will prefer reboot. We say that there is a
>> chain of responsibility for updates.
>> So it is perfectly OK to have a Linux software agent receive an update
>> by any mean (network, USB, serial...). The agent will pack this (or
>> those) into a capsule and push it to UEFI implementation.
>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>> pleases for the update providing it complies with 1) So the UEFI
>> implementation can live update up to BL33 firmware.
>> Should the update be targeted to secure world, then the UEFI
>> implementation can pass it to S-EL3 for update (platform specific)
>> which means the update can also be live. It is a designer decision.
>>
>> With 3) we have flexibility but sometimes too much flexibility is a
>> problem. Alexander Graf suggested we can use a FIT object to pass
>> diverse objects. It is "half" opaque but I really like the idea.
>> The contents of individual FIT components can be blocks to be placed
>> at a fix location in a NOR flash or a file, no importance.
>>
>> What do everyone think about those design principles ?
>>
> 
> UEFI and capsules can be fine for those platform that support it (and 
> it's still a rare feature) and for stuff like boot and peripheral 
> firmware. I don't think it's a wise, future-proof idea to use it for more.
> 
> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical 
> it will evolve towards that (looking at that as both a user as well as 
> an OEM). It's not even present in quite a few of our use cases. In some 
> it will never be - think of safety-critical system: not affordable with 
> such a complex approach like UEFI.

Can I challenge that view a bit? On the Tianocore side I agree that the 
ecosystem isn't very healthy. That project in particular struggles with 
what to do with board support, having decided early on that board 
support generally doesn't need to be in the main repository.

However, U-Boot support for the UEFI ABI is improving in leaps and 
bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all 
the Arm SBCs that they support, and enabling UEFI in U-Boot is just a 
config option or two. There is a fair bit of encouragement from within 
the project to enable UEFI by default.

UEFI gets a bad rap at being complicated, but I think the U-Boot work 
has shown that implementing the core UEFI ABI doesn't require much code 
and isn't the complicated mess they everyone fears it to be.

I don't see the conflict with safety critical for boot services. I can 
however see the arguement against UEFI runtime services as a poor 
implementation could result in unbounded execution times. There's been 
recent movement on the UEFI spec to make runtime services optional, and 
in U-Boot they are mostly empty stubs.

> It should not expand further into OS 
> domains. Updating complete filesystems and their content is beyond its 
> duties. We have all the required, tested, matured means for the OS in 
> the OS. For firmware, it can be an option - if that firmware is UEFI 
> compliant, with all needed options.

Here I agree 100%. Capsule update is a useful ABI for the OS to pass 
firmware update blobs without needing to know specifics about the 
platform, but everything from the kernel on up is out of scope.

> So let's use UEFI and capsules as a one possible building block in the 
> design, but not as the cornerstone. Just like we do mandate that all 
> updates must be served and managed by our IoT cloud ;).

What do the firmware stacks in your projects look like? What percentage 
are based on U-Boot? Littlekernel? Others?

UEFI has the advantage that it has a defined ABI, and only a small 
amount of it needs to be implemented to execute UEFI OS loaders (ie. the 
Linux UEFI stub). For the reference platform, I think it makes sense to 
make the design decision that firmware provides UEFI, and the update 
infrastructure is based on that. However, if UEFI doesn't work for a 
particular stack/project then it can be swapped out. There will need to 
be work done on the boot sequence, but all the rest of the OS stack is 
still relevant.

g.

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Grant Likely]

On 26/04/2019 10:49, Jan Kiszka wrote:
> On 26.04.19 11:07, Francois Ozog wrote:
[...]
>> Here are the guiding principles of our efforts :
>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>> processor model update solution
>> 1) untrusted world cannot update trusted world
> 
> Conceptually, it can. It's a matter of validating the update by the 
> trusted world before using it. A trusted instance can allow an untrusted 
> one to write version 2, validate that before switching to it, and stick 
> with version 1 if that fails.
> 
>> 2) what the UEFI implementation does with the capsule is platform 
>> specific
>> 3) the update capsule payload is opaque
>>
>> 1) is a "philosophy" decision. When you have a root of trust down to
>> the operating system. So in theory everything should be fine. But the
>> attack surface is such that we can't rule out hacking (and history
>> prove this is unfortunately a safe assumption). In addition, there may
>> be liability aspects related to the who does the update: the hardware
>> platform administrator may not be the legal entity than the operating
>> system administrator. For instance:
>> -  on Packet.net could, a customer can flash up to the BL33 untrusted
>> firmware but that is all.
>> - A surveillance camera can be operated by city personnel but only law
>> enforcement agency can see raw video (un-blurred faces and licence
>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>> Path but if you allow untrusted world to update the trusted one, city
>> personnel can overcome the legal restriction.
>> With 1) this means that even U-Boot code shall not be able/allowed to
>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>> Secure EL1/0 software (OPTEE and its applications or something else).
>> If possible, allowing the operating system administrator to
>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>> platform dependent. Hence defeats 0)
>>
>> With 2) we do not impose reboot to update. Some platform may impose
>> reboot or some designers will prefer reboot. We say that there is a
>> chain of responsibility for updates.
>> So it is perfectly OK to have a Linux software agent receive an update
>> by any mean (network, USB, serial...). The agent will pack this (or
>> those) into a capsule and push it to UEFI implementation.
>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>> pleases for the update providing it complies with 1) So the UEFI
>> implementation can live update up to BL33 firmware.
>> Should the update be targeted to secure world, then the UEFI
>> implementation can pass it to S-EL3 for update (platform specific)
>> which means the update can also be live. It is a designer decision.
>>
>> With 3) we have flexibility but sometimes too much flexibility is a
>> problem. Alexander Graf suggested we can use a FIT object to pass
>> diverse objects. It is "half" opaque but I really like the idea.
>> The contents of individual FIT components can be blocks to be placed
>> at a fix location in a NOR flash or a file, no importance.
>>
>> What do everyone think about those design principles ?
>>
> 
> UEFI and capsules can be fine for those platform that support it (and 
> it's still a rare feature) and for stuff like boot and peripheral 
> firmware. I don't think it's a wise, future-proof idea to use it for more.
> 
> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical 
> it will evolve towards that (looking at that as both a user as well as 
> an OEM). It's not even present in quite a few of our use cases. In some 
> it will never be - think of safety-critical system: not affordable with 
> such a complex approach like UEFI.

Can I challenge that view a bit? On the Tianocore side I agree that the 
ecosystem isn't very healthy. That project in particular struggles with 
what to do with board support, having decided early on that board 
support generally doesn't need to be in the main repository.

However, U-Boot support for the UEFI ABI is improving in leaps and 
bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all 
the Arm SBCs that they support, and enabling UEFI in U-Boot is just a 
config option or two. There is a fair bit of encouragement from within 
the project to enable UEFI by default.

UEFI gets a bad rap at being complicated, but I think the U-Boot work 
has shown that implementing the core UEFI ABI doesn't require much code 
and isn't the complicated mess they everyone fears it to be.

I don't see the conflict with safety critical for boot services. I can 
however see the arguement against UEFI runtime services as a poor 
implementation could result in unbounded execution times. There's been 
recent movement on the UEFI spec to make runtime services optional, and 
in U-Boot they are mostly empty stubs.

> It should not expand further into OS 
> domains. Updating complete filesystems and their content is beyond its 
> duties. We have all the required, tested, matured means for the OS in 
> the OS. For firmware, it can be an option - if that firmware is UEFI 
> compliant, with all needed options.

Here I agree 100%. Capsule update is a useful ABI for the OS to pass 
firmware update blobs without needing to know specifics about the 
platform, but everything from the kernel on up is out of scope.

> So let's use UEFI and capsules as a one possible building block in the 
> design, but not as the cornerstone. Just like we do mandate that all 
> updates must be served and managed by our IoT cloud ;).

What do the firmware stacks in your projects look like? What percentage 
are based on U-Boot? Littlekernel? Others?

UEFI has the advantage that it has a defined ABI, and only a small 
amount of it needs to be implemented to execute UEFI OS loaders (ie. the 
Linux UEFI stub). For the reference platform, I think it makes sense to 
make the design decision that firmware provides UEFI, and the update 
infrastructure is based on that. However, if UEFI doesn't work for a 
particular stack/project then it can be swapped out. There will need to 
be work done on the boot sequence, but all the rest of the OS stack is 
still relevant.

g.

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Francois Ozog]

- team-ledge at linaro.org as it is now a public discussion

On Fri, 26 Apr 2019 at 12:21, Grant Likely <Grant.Likely@arm.com> wrote:

> On 26/04/2019 10:49, Jan Kiszka wrote:
> > On 26.04.19 11:07, Francois Ozog wrote:
> [...]
> >> Here are the guiding principles of our efforts :
> >> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
> >> processor model update solution
> >> 1) untrusted world cannot update trusted world
> >
> > Conceptually, it can. It's a matter of validating the update by the
> > trusted world before using it. A trusted instance can allow an untrusted
> > one to write version 2, validate that before switching to it, and stick
> > with version 1 if that fails.
> >
> >> 2) what the UEFI implementation does with the capsule is platform
> >> specific
> >> 3) the update capsule payload is opaque
> >>
> >> 1) is a "philosophy" decision. When you have a root of trust down to
> >> the operating system. So in theory everything should be fine. But the
> >> attack surface is such that we can't rule out hacking (and history
> >> prove this is unfortunately a safe assumption). In addition, there may
> >> be liability aspects related to the who does the update: the hardware
> >> platform administrator may not be the legal entity than the operating
> >> system administrator. For instance:
> >> -  on Packet.net could, a customer can flash up to the BL33 untrusted
> >> firmware but that is all.
> >> - A surveillance camera can be operated by city personnel but only law
> >> enforcement agency can see raw video (un-blurred faces and licence
> >> plates). This can be implemented by a derivative of OPTEE SecureMedia
> >> Path but if you allow untrusted world to update the trusted one, city
> >> personnel can overcome the legal restriction.
> >> With 1) this means that even U-Boot code shall not be able/allowed to
> >> update S-EL3 firmware (be it Trusted Firmware A or something else),
> >> Secure EL1/0 software (OPTEE and its applications or something else).
> >> If possible, allowing the operating system administrator to
> >> selectively (BL33 is OK but not S-EL3) update firmware is at least
> >> platform dependent. Hence defeats 0)
> >>
> >> With 2) we do not impose reboot to update. Some platform may impose
> >> reboot or some designers will prefer reboot. We say that there is a
> >> chain of responsibility for updates.
> >> So it is perfectly OK to have a Linux software agent receive an update
> >> by any mean (network, USB, serial...). The agent will pack this (or
> >> those) into a capsule and push it to UEFI implementation.
> >> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
> >> pleases for the update providing it complies with 1) So the UEFI
> >> implementation can live update up to BL33 firmware.
> >> Should the update be targeted to secure world, then the UEFI
> >> implementation can pass it to S-EL3 for update (platform specific)
> >> which means the update can also be live. It is a designer decision.
> >>
> >> With 3) we have flexibility but sometimes too much flexibility is a
> >> problem. Alexander Graf suggested we can use a FIT object to pass
> >> diverse objects. It is "half" opaque but I really like the idea.
> >> The contents of individual FIT components can be blocks to be placed
> >> at a fix location in a NOR flash or a file, no importance.
> >>
> >> What do everyone think about those design principles ?
> >>
> >
> > UEFI and capsules can be fine for those platform that support it (and
> > it's still a rare feature) and for stuff like boot and peripheral
> > firmware. I don't think it's a wise, future-proof idea to use it for
> more.
> >
> > UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
> > it will evolve towards that (looking at that as both a user as well as
> > an OEM). It's not even present in quite a few of our use cases. In some
> > it will never be - think of safety-critical system: not affordable with
> > such a complex approach like UEFI.
>
> Can I challenge that view a bit? On the Tianocore side I agree that the
> ecosystem isn't very healthy. That project in particular struggles with
> what to do with board support, having decided early on that board
> support generally doesn't need to be in the main repository.
>
> However, U-Boot support for the UEFI ABI is improving in leaps and
> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
> config option or two. There is a fair bit of encouragement from within
> the project to enable UEFI by default.
>
> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> has shown that implementing the core UEFI ABI doesn't require much code
> and isn't the complicated mess they everyone fears it to be.
>
> I don't see the conflict with safety critical for boot services. I can
> however see the arguement against UEFI runtime services as a poor
> implementation could result in unbounded execution times. There's been
> recent movement on the UEFI spec to make runtime services optional, and
> in U-Boot they are mostly empty stubs.
>
> > It should not expand further into OS
> > domains. Updating complete filesystems and their content is beyond its
> > duties. We have all the required, tested, matured means for the OS in
> > the OS. For firmware, it can be an option - if that firmware is UEFI
> > compliant, with all needed options.
>
> Here I agree 100%. Capsule update is a useful ABI for the OS to pass
> firmware update blobs without needing to know specifics about the
> platform, but everything from the kernel on up is out of scope.
>
> > So let's use UEFI and capsules as a one possible building block in the
> > design, but not as the cornerstone. Just like we do mandate that all
> > updates must be served and managed by our IoT cloud ;).
>
> What do the firmware stacks in your projects look like? What percentage
> are based on U-Boot? Littlekernel? Others?
>
> UEFI has the advantage that it has a defined ABI, and only a small
> amount of it needs to be implemented to execute UEFI OS loaders (ie. the
> Linux UEFI stub). For the reference platform, I think it makes sense to
> make the design decision that firmware provides UEFI, and the update
> infrastructure is based on that. However, if UEFI doesn't work for a
> particular stack/project then it can be swapped out. There will need to
> be work done on the boot sequence, but all the rest of the OS stack is
> still relevant.
>
> g.
>


-- 
Fran?ois-Fr?d?ric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190426/5a5cbbde/attachment.html>

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Francois Ozog]

- team-ledge at linaro.org as it is now a public discussion

On Fri, 26 Apr 2019 at 12:21, Grant Likely <Grant.Likely@arm.com> wrote:

> On 26/04/2019 10:49, Jan Kiszka wrote:
> > On 26.04.19 11:07, Francois Ozog wrote:
> [...]
> >> Here are the guiding principles of our efforts :
> >> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
> >> processor model update solution
> >> 1) untrusted world cannot update trusted world
> >
> > Conceptually, it can. It's a matter of validating the update by the
> > trusted world before using it. A trusted instance can allow an untrusted
> > one to write version 2, validate that before switching to it, and stick
> > with version 1 if that fails.
> >
> >> 2) what the UEFI implementation does with the capsule is platform
> >> specific
> >> 3) the update capsule payload is opaque
> >>
> >> 1) is a "philosophy" decision. When you have a root of trust down to
> >> the operating system. So in theory everything should be fine. But the
> >> attack surface is such that we can't rule out hacking (and history
> >> prove this is unfortunately a safe assumption). In addition, there may
> >> be liability aspects related to the who does the update: the hardware
> >> platform administrator may not be the legal entity than the operating
> >> system administrator. For instance:
> >> -  on Packet.net could, a customer can flash up to the BL33 untrusted
> >> firmware but that is all.
> >> - A surveillance camera can be operated by city personnel but only law
> >> enforcement agency can see raw video (un-blurred faces and licence
> >> plates). This can be implemented by a derivative of OPTEE SecureMedia
> >> Path but if you allow untrusted world to update the trusted one, city
> >> personnel can overcome the legal restriction.
> >> With 1) this means that even U-Boot code shall not be able/allowed to
> >> update S-EL3 firmware (be it Trusted Firmware A or something else),
> >> Secure EL1/0 software (OPTEE and its applications or something else).
> >> If possible, allowing the operating system administrator to
> >> selectively (BL33 is OK but not S-EL3) update firmware is at least
> >> platform dependent. Hence defeats 0)
> >>
> >> With 2) we do not impose reboot to update. Some platform may impose
> >> reboot or some designers will prefer reboot. We say that there is a
> >> chain of responsibility for updates.
> >> So it is perfectly OK to have a Linux software agent receive an update
> >> by any mean (network, USB, serial...). The agent will pack this (or
> >> those) into a capsule and push it to UEFI implementation.
> >> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
> >> pleases for the update providing it complies with 1) So the UEFI
> >> implementation can live update up to BL33 firmware.
> >> Should the update be targeted to secure world, then the UEFI
> >> implementation can pass it to S-EL3 for update (platform specific)
> >> which means the update can also be live. It is a designer decision.
> >>
> >> With 3) we have flexibility but sometimes too much flexibility is a
> >> problem. Alexander Graf suggested we can use a FIT object to pass
> >> diverse objects. It is "half" opaque but I really like the idea.
> >> The contents of individual FIT components can be blocks to be placed
> >> at a fix location in a NOR flash or a file, no importance.
> >>
> >> What do everyone think about those design principles ?
> >>
> >
> > UEFI and capsules can be fine for those platform that support it (and
> > it's still a rare feature) and for stuff like boot and peripheral
> > firmware. I don't think it's a wise, future-proof idea to use it for
> more.
> >
> > UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
> > it will evolve towards that (looking at that as both a user as well as
> > an OEM). It's not even present in quite a few of our use cases. In some
> > it will never be - think of safety-critical system: not affordable with
> > such a complex approach like UEFI.
>
> Can I challenge that view a bit? On the Tianocore side I agree that the
> ecosystem isn't very healthy. That project in particular struggles with
> what to do with board support, having decided early on that board
> support generally doesn't need to be in the main repository.
>
> However, U-Boot support for the UEFI ABI is improving in leaps and
> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
> config option or two. There is a fair bit of encouragement from within
> the project to enable UEFI by default.
>
> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> has shown that implementing the core UEFI ABI doesn't require much code
> and isn't the complicated mess they everyone fears it to be.
>
> I don't see the conflict with safety critical for boot services. I can
> however see the arguement against UEFI runtime services as a poor
> implementation could result in unbounded execution times. There's been
> recent movement on the UEFI spec to make runtime services optional, and
> in U-Boot they are mostly empty stubs.
>
> > It should not expand further into OS
> > domains. Updating complete filesystems and their content is beyond its
> > duties. We have all the required, tested, matured means for the OS in
> > the OS. For firmware, it can be an option - if that firmware is UEFI
> > compliant, with all needed options.
>
> Here I agree 100%. Capsule update is a useful ABI for the OS to pass
> firmware update blobs without needing to know specifics about the
> platform, but everything from the kernel on up is out of scope.
>
> > So let's use UEFI and capsules as a one possible building block in the
> > design, but not as the cornerstone. Just like we do mandate that all
> > updates must be served and managed by our IoT cloud ;).
>
> What do the firmware stacks in your projects look like? What percentage
> are based on U-Boot? Littlekernel? Others?
>
> UEFI has the advantage that it has a defined ABI, and only a small
> amount of it needs to be implemented to execute UEFI OS loaders (ie. the
> Linux UEFI stub). For the reference platform, I think it makes sense to
> make the design decision that firmware provides UEFI, and the update
> infrastructure is based on that. However, if UEFI doesn't work for a
> particular stack/project then it can be swapped out. There will need to
> be work done on the boot sequence, but all the rest of the OS stack is
> still relevant.
>
> g.
>


-- 
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Jan Kiszka]

On 26.04.19 12:21, Grant Likely wrote:
> On 26/04/2019 10:49, Jan Kiszka wrote:
>> On 26.04.19 11:07, Francois Ozog wrote:
> [...]
>>> Here are the guiding principles of our efforts :
>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>> processor model update solution
>>> 1) untrusted world cannot update trusted world
>>
>> Conceptually, it can. It's a matter of validating the update by the
>> trusted world before using it. A trusted instance can allow an untrusted
>> one to write version 2, validate that before switching to it, and stick
>> with version 1 if that fails.
>>
>>> 2) what the UEFI implementation does with the capsule is platform
>>> specific
>>> 3) the update capsule payload is opaque
>>>
>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>> the operating system. So in theory everything should be fine. But the
>>> attack surface is such that we can't rule out hacking (and history
>>> prove this is unfortunately a safe assumption). In addition, there may
>>> be liability aspects related to the who does the update: the hardware
>>> platform administrator may not be the legal entity than the operating
>>> system administrator. For instance:
>>> -? on Packet.net could, a customer can flash up to the BL33 untrusted
>>> firmware but that is all.
>>> - A surveillance camera can be operated by city personnel but only law
>>> enforcement agency can see raw video (un-blurred faces and licence
>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>> Path but if you allow untrusted world to update the trusted one, city
>>> personnel can overcome the legal restriction.
>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>> If possible, allowing the operating system administrator to
>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>> platform dependent. Hence defeats 0)
>>>
>>> With 2) we do not impose reboot to update. Some platform may impose
>>> reboot or some designers will prefer reboot. We say that there is a
>>> chain of responsibility for updates.
>>> So it is perfectly OK to have a Linux software agent receive an update
>>> by any mean (network, USB, serial...). The agent will pack this (or
>>> those) into a capsule and push it to UEFI implementation.
>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>> pleases for the update providing it complies with 1) So the UEFI
>>> implementation can live update up to BL33 firmware.
>>> Should the update be targeted to secure world, then the UEFI
>>> implementation can pass it to S-EL3 for update (platform specific)
>>> which means the update can also be live. It is a designer decision.
>>>
>>> With 3) we have flexibility but sometimes too much flexibility is a
>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>> diverse objects. It is "half" opaque but I really like the idea.
>>> The contents of individual FIT components can be blocks to be placed
>>> at a fix location in a NOR flash or a file, no importance.
>>>
>>> What do everyone think about those design principles ?
>>>
>>
>> UEFI and capsules can be fine for those platform that support it (and
>> it's still a rare feature) and for stuff like boot and peripheral
>> firmware. I don't think it's a wise, future-proof idea to use it for more.
>>
>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>> it will evolve towards that (looking at that as both a user as well as
>> an OEM). It's not even present in quite a few of our use cases. In some
>> it will never be - think of safety-critical system: not affordable with
>> such a complex approach like UEFI.
> 
> Can I challenge that view a bit? On the Tianocore side I agree that the
> ecosystem isn't very healthy. That project in particular struggles with
> what to do with board support, having decided early on that board
> support generally doesn't need to be in the main repository.
> 
> However, U-Boot support for the UEFI ABI is improving in leaps and
> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
> config option or two. There is a fair bit of encouragement from within
> the project to enable UEFI by default.

I don't disagree that this aspect is a step forward (though pulling in things 
redundant code via grub & Co is not really progress). But a Unix community would 
have probably designed a technically more elegant solution on a green field than 
the clumsy, legacy-based UEFI interfaces.

> 
> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> has shown that implementing the core UEFI ABI doesn't require much code
> and isn't the complicated mess they everyone fears it to be.

Depends on how much you start to rely on UEFI features.

> 
> I don't see the conflict with safety critical for boot services. I can

Everything is certifiable - with infinite time and money. So you will likely 
reduce the boot process to the very essential of your concrete system, removing 
then unneeded abstractions and stages. Or you will find ways to eliminate that 
from your argumentation, which would definitely include removing runtime services.

> however see the arguement against UEFI runtime services as a poor
> implementation could result in unbounded execution times. There's been
> recent movement on the UEFI spec to make runtime services optional, and
> in U-Boot they are mostly empty stubs.

Of course, it also depends on how much you need from UEFI to boot or to use 
certain services like capsule updates (and which would be gone when you remove 
runtime services).

> 
>> It should not expand further into OS
>> domains. Updating complete filesystems and their content is beyond its
>> duties. We have all the required, tested, matured means for the OS in
>> the OS. For firmware, it can be an option - if that firmware is UEFI
>> compliant, with all needed options.
> 
> Here I agree 100%. Capsule update is a useful ABI for the OS to pass
> firmware update blobs without needing to know specifics about the
> platform, but everything from the kernel on up is out of scope.

OK, that's good.

> 
>> So let's use UEFI and capsules as a one possible building block in the
>> design, but not as the cornerstone. Just like we do mandate that all
>> updates must be served and managed by our IoT cloud ;).
> 
> What do the firmware stacks in your projects look like? What percentage
> are based on U-Boot? Littlekernel? Others?

I don't have absolute numbers. We have a lot of "standard" x86 UEFI systems, 
many U-boot devices (of which, to my knowledge, none is on UEFI yet - no 
surprise, that feature is still too "new"), and quite a few Coreboot designs (so 
far only x86) that just need to load Linux and bypass a lot therefore. There 
will likely be more exotic things but they will likely also do not deserve 
attention.

> 
> UEFI has the advantage that it has a defined ABI, and only a small
> amount of it needs to be implemented to execute UEFI OS loaders (ie. the
> Linux UEFI stub). For the reference platform, I think it makes sense to
> make the design decision that firmware provides UEFI, and the update
> infrastructure is based on that. However, if UEFI doesn't work for a
> particular stack/project then it can be swapped out. There will need to
> be work done on the boot sequence, but all the rest of the OS stack is
> still relevant.

Yes, I would design it in a way that a perfect UEFI implementation can take a 
lot of boot-related tasks like safe boot configuration switching, watchdog 
management, firmware and peripheral updating (possibly in lock-step with the OS) 
etc. But I would always ensure that incomplete or immature UEFI implementations 
will not complicate partial or complete replacements. Because the latter will 
remain the default for quite a while, if not longer, I'm sure. UEFI should not 
become the systemd of unattended device updates (or worse, due to closed 
implementations).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Jan Kiszka]

On 26.04.19 12:21, Grant Likely wrote:
> On 26/04/2019 10:49, Jan Kiszka wrote:
>> On 26.04.19 11:07, Francois Ozog wrote:
> [...]
>>> Here are the guiding principles of our efforts :
>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>> processor model update solution
>>> 1) untrusted world cannot update trusted world
>>
>> Conceptually, it can. It's a matter of validating the update by the
>> trusted world before using it. A trusted instance can allow an untrusted
>> one to write version 2, validate that before switching to it, and stick
>> with version 1 if that fails.
>>
>>> 2) what the UEFI implementation does with the capsule is platform
>>> specific
>>> 3) the update capsule payload is opaque
>>>
>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>> the operating system. So in theory everything should be fine. But the
>>> attack surface is such that we can't rule out hacking (and history
>>> prove this is unfortunately a safe assumption). In addition, there may
>>> be liability aspects related to the who does the update: the hardware
>>> platform administrator may not be the legal entity than the operating
>>> system administrator. For instance:
>>> -  on Packet.net could, a customer can flash up to the BL33 untrusted
>>> firmware but that is all.
>>> - A surveillance camera can be operated by city personnel but only law
>>> enforcement agency can see raw video (un-blurred faces and licence
>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>> Path but if you allow untrusted world to update the trusted one, city
>>> personnel can overcome the legal restriction.
>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>> If possible, allowing the operating system administrator to
>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>> platform dependent. Hence defeats 0)
>>>
>>> With 2) we do not impose reboot to update. Some platform may impose
>>> reboot or some designers will prefer reboot. We say that there is a
>>> chain of responsibility for updates.
>>> So it is perfectly OK to have a Linux software agent receive an update
>>> by any mean (network, USB, serial...). The agent will pack this (or
>>> those) into a capsule and push it to UEFI implementation.
>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>> pleases for the update providing it complies with 1) So the UEFI
>>> implementation can live update up to BL33 firmware.
>>> Should the update be targeted to secure world, then the UEFI
>>> implementation can pass it to S-EL3 for update (platform specific)
>>> which means the update can also be live. It is a designer decision.
>>>
>>> With 3) we have flexibility but sometimes too much flexibility is a
>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>> diverse objects. It is "half" opaque but I really like the idea.
>>> The contents of individual FIT components can be blocks to be placed
>>> at a fix location in a NOR flash or a file, no importance.
>>>
>>> What do everyone think about those design principles ?
>>>
>>
>> UEFI and capsules can be fine for those platform that support it (and
>> it's still a rare feature) and for stuff like boot and peripheral
>> firmware. I don't think it's a wise, future-proof idea to use it for more.
>>
>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>> it will evolve towards that (looking at that as both a user as well as
>> an OEM). It's not even present in quite a few of our use cases. In some
>> it will never be - think of safety-critical system: not affordable with
>> such a complex approach like UEFI.
> 
> Can I challenge that view a bit? On the Tianocore side I agree that the
> ecosystem isn't very healthy. That project in particular struggles with
> what to do with board support, having decided early on that board
> support generally doesn't need to be in the main repository.
> 
> However, U-Boot support for the UEFI ABI is improving in leaps and
> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
> config option or two. There is a fair bit of encouragement from within
> the project to enable UEFI by default.

I don't disagree that this aspect is a step forward (though pulling in things 
redundant code via grub & Co is not really progress). But a Unix community would 
have probably designed a technically more elegant solution on a green field than 
the clumsy, legacy-based UEFI interfaces.

> 
> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> has shown that implementing the core UEFI ABI doesn't require much code
> and isn't the complicated mess they everyone fears it to be.

Depends on how much you start to rely on UEFI features.

> 
> I don't see the conflict with safety critical for boot services. I can

Everything is certifiable - with infinite time and money. So you will likely 
reduce the boot process to the very essential of your concrete system, removing 
then unneeded abstractions and stages. Or you will find ways to eliminate that 
from your argumentation, which would definitely include removing runtime services.

> however see the arguement against UEFI runtime services as a poor
> implementation could result in unbounded execution times. There's been
> recent movement on the UEFI spec to make runtime services optional, and
> in U-Boot they are mostly empty stubs.

Of course, it also depends on how much you need from UEFI to boot or to use 
certain services like capsule updates (and which would be gone when you remove 
runtime services).

> 
>> It should not expand further into OS
>> domains. Updating complete filesystems and their content is beyond its
>> duties. We have all the required, tested, matured means for the OS in
>> the OS. For firmware, it can be an option - if that firmware is UEFI
>> compliant, with all needed options.
> 
> Here I agree 100%. Capsule update is a useful ABI for the OS to pass
> firmware update blobs without needing to know specifics about the
> platform, but everything from the kernel on up is out of scope.

OK, that's good.

> 
>> So let's use UEFI and capsules as a one possible building block in the
>> design, but not as the cornerstone. Just like we do mandate that all
>> updates must be served and managed by our IoT cloud ;).
> 
> What do the firmware stacks in your projects look like? What percentage
> are based on U-Boot? Littlekernel? Others?

I don't have absolute numbers. We have a lot of "standard" x86 UEFI systems, 
many U-boot devices (of which, to my knowledge, none is on UEFI yet - no 
surprise, that feature is still too "new"), and quite a few Coreboot designs (so 
far only x86) that just need to load Linux and bypass a lot therefore. There 
will likely be more exotic things but they will likely also do not deserve 
attention.

> 
> UEFI has the advantage that it has a defined ABI, and only a small
> amount of it needs to be implemented to execute UEFI OS loaders (ie. the
> Linux UEFI stub). For the reference platform, I think it makes sense to
> make the design decision that firmware provides UEFI, and the update
> infrastructure is based on that. However, if UEFI doesn't work for a
> particular stack/project then it can be swapped out. There will need to
> be work done on the boot sequence, but all the rest of the OS stack is
> still relevant.

Yes, I would design it in a way that a perfect UEFI implementation can take a 
lot of boot-related tasks like safe boot configuration switching, watchdog 
management, firmware and peripheral updating (possibly in lock-step with the OS) 
etc. But I would always ensure that incomplete or immature UEFI implementations 
will not complicate partial or complete replacements. Because the latter will 
remain the default for quite a while, if not longer, I'm sure. UEFI should not 
become the systemd of unattended device updates (or worse, due to closed 
implementations).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Francois Ozog]

On Fri, 26 Apr 2019 at 11:49, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 26.04.19 11:07, Francois Ozog wrote:
> > On Fri, 26 Apr 2019 at 10:30, Christian Storm
> > <christian.storm@siemens.com> wrote:
> >>
> >> Hi,
> >>
> >>>>> Background: during the last Linaro connect in Bangkok I was told
> >>>>> that Linaro Edge (LEDGE) were working on a secure software update
> >>>>> mechanism based on UEFI capsules that would flash firmware updates
> >>>>> from a UEFI application, instead of using a Linux agent such as
> >>>>> SWUpdate.
> >>>>
> >>>> How would capsules help with writing to arbitrary storage, updating
> >>>> only files on filesystem, reducing the update size (binary diffs),
> >>>> or talking to the cloud?
> >>>
> >
> > See below
> >>
> >>> - arbitrary storage: I guess they can only write to what is supported
> >>>    by the machine's UEFI implementation.
> >>>
> >
> > Yes, see below
> >>
> >>> - updating only files on filesystem: I assume this is out of scope in
> >>>    their architecture (Francois: do you want to support file-based
> >>>    updates or only block-based ones?)
> >>
> > Both, see below
> >>
> >>> - reducing the update size (binary diffs), or talking to the cloud:
> >>>    they will do that from non-secure Linux. It would be dangerous to
> use
> >>>    a fragile network stack from an UEFI application or the secure
> world.
> >>>    In that sense, they also need a Linux agent.
> >>
> >> If I understand the idea correctly, there's then a Linux companion agent
> >> that does, e.g., the cloud communication and sets up the update payload
> >> to be consumed and applied by the UEFI firmware update application. The
> >> actual update action will take place on reboot, e.g., flashing the
> >> inactive partition in an A/B setup and thereafter booting into the newly
> >> flashed, then active partition.
> >>
> >> If so, this would prolong the time the system is unavailable due to disk
> >> flashing I/O in the UEFI firmware update application compared to
> flashing
> >> the inactive partition from within Linux and have the bootloader just
> >> switch the to be booted partitions.
> >>
> >> Generally, but in particular regarding binary diffs, a binary diff
> >> application mechanism would have to be implemented and maintained in the
> >> UEFI realm as opposed to "just" using the respective shared libraries
> >> (e.g. librsync, casync, ...) in the Linux realm. Granted, one could
> >> come up with a unified format to which the output of, e.g, librsync's
> rdiff
> >> or a casync run is converted but nonetheless, this creates some porting/
> >> implementation and maintenance effort.
> >>
> >>
> > Here are the guiding principles of our efforts :
> > 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
> > processor model update solution
> > 1) untrusted world cannot update trusted world
>
> Conceptually, it can. It's a matter of validating the update by the
> trusted
> world before using it. A trusted instance can allow an untrusted one to
> write
> version 2, validate that before switching to it, and stick with version 1
> if
> that fails.
>
> Agreed. Then is a better principle:  untrusted world cannot directly
update trusted world objects that are part of the current chain of trust
   This would allow changing B partition while A is in force.
There may be another aspect to take into account, not every use case need
the same security "level".
May be a principle to define security levels and guidelines to achieve each
level is more relevant than the "untrusted world cannot directly update
trusted world objects that are part of the current chain of trust" which
implies a certain security level goal.

> 2) what the UEFI implementation does with the capsule is platform specific
> > 3) the update capsule payload is opaque
> >
> > 1) is a "philosophy" decision. When you have a root of trust down to
> > the operating system. So in theory everything should be fine. But the
> > attack surface is such that we can't rule out hacking (and history
> > prove this is unfortunately a safe assumption). In addition, there may
> > be liability aspects related to the who does the update: the hardware
> > platform administrator may not be the legal entity than the operating
> > system administrator. For instance:
> > -  on Packet.net could, a customer can flash up to the BL33 untrusted
> > firmware but that is all.
> > - A surveillance camera can be operated by city personnel but only law
> > enforcement agency can see raw video (un-blurred faces and licence
> > plates). This can be implemented by a derivative of OPTEE SecureMedia
> > Path but if you allow untrusted world to update the trusted one, city
> > personnel can overcome the legal restriction.
> > With 1) this means that even U-Boot code shall not be able/allowed to
> > update S-EL3 firmware (be it Trusted Firmware A or something else),
> > Secure EL1/0 software (OPTEE and its applications or something else).
> > If possible, allowing the operating system administrator to
> > selectively (BL33 is OK but not S-EL3) update firmware is at least
> > platform dependent. Hence defeats 0)
> >
> > With 2) we do not impose reboot to update. Some platform may impose
> > reboot or some designers will prefer reboot. We say that there is a
> > chain of responsibility for updates.
> > So it is perfectly OK to have a Linux software agent receive an update
> > by any mean (network, USB, serial...). The agent will pack this (or
> > those) into a capsule and push it to UEFI implementation.
> > The UEFI implementation (U-Boot or Tianocore) will then do whatever it
> > pleases for the update providing it complies with 1) So the UEFI
> > implementation can live update up to BL33 firmware.
> > Should the update be targeted to secure world, then the UEFI
> > implementation can pass it to S-EL3 for update (platform specific)
> > which means the update can also be live. It is a designer decision.
> >
> > With 3) we have flexibility but sometimes too much flexibility is a
> > problem. Alexander Graf suggested we can use a FIT object to pass
> > diverse objects. It is "half" opaque but I really like the idea.
> > The contents of individual FIT components can be blocks to be placed
> > at a fix location in a NOR flash or a file, no importance.
> >
> > What do everyone think about those design principles ?
> >
>
> UEFI and capsules can be fine for those platform that support it (and it's
> still
> a rare feature) and for stuff like boot and peripheral firmware. I don't
> think
> it's a wise, future-proof idea to use it for more.
>
> Agreed. if we say that {shim, grub , kernel, initrd, commandline} is to be
named the "BL33 payload" then they are out of scope of the UEFI update
capsules, as well as any untrusted apps.= (on top of OS).
Update capsules can be used to update firmwares of any sort, keys,
certificates, secrets, blobs that are for pre-BL33 execution environment.

UEFI is not a very healthy ecosystem yet, and I'm personally skeptical it
> will
> evolve towards that (looking at that as both a user as well as an OEM).
> It's not
> even present in quite a few of our use cases. In some it will never be -
> think
> of safety-critical system: not affordable with such a complex approach
> like
> UEFI. It should not expand further into OS domains. Updating complete
> filesystems and their content is beyond its duties. We have all the
> required,
> tested, matured means for the OS in the OS. For firmware, it can be an
> option -
> if that firmware is UEFI compliant, with all needed options.
>
> So let's use UEFI and capsules as a one possible building block in the
> design,
> but not as the cornerstone. Just like we do mandate that all updates must
> be
> served and managed by our IoT cloud ;).
>
> Agreed. Out of all the edge and fog deployments some will have very
specific requirements. This effort is not to rule them out as rule out
proprietary mechanisms. It is to say that 90% of the cases can be handled
by a generic method and we should define this one.

> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>


-- 
Fran?ois-Fr?d?ric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20190426/f2c9a3d4/attachment-0001.html>

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Francois Ozog]

On Fri, 26 Apr 2019 at 11:49, Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 26.04.19 11:07, Francois Ozog wrote:
> > On Fri, 26 Apr 2019 at 10:30, Christian Storm
> > <christian.storm@siemens.com> wrote:
> >>
> >> Hi,
> >>
> >>>>> Background: during the last Linaro connect in Bangkok I was told
> >>>>> that Linaro Edge (LEDGE) were working on a secure software update
> >>>>> mechanism based on UEFI capsules that would flash firmware updates
> >>>>> from a UEFI application, instead of using a Linux agent such as
> >>>>> SWUpdate.
> >>>>
> >>>> How would capsules help with writing to arbitrary storage, updating
> >>>> only files on filesystem, reducing the update size (binary diffs),
> >>>> or talking to the cloud?
> >>>
> >
> > See below
> >>
> >>> - arbitrary storage: I guess they can only write to what is supported
> >>>    by the machine's UEFI implementation.
> >>>
> >
> > Yes, see below
> >>
> >>> - updating only files on filesystem: I assume this is out of scope in
> >>>    their architecture (Francois: do you want to support file-based
> >>>    updates or only block-based ones?)
> >>
> > Both, see below
> >>
> >>> - reducing the update size (binary diffs), or talking to the cloud:
> >>>    they will do that from non-secure Linux. It would be dangerous to
> use
> >>>    a fragile network stack from an UEFI application or the secure
> world.
> >>>    In that sense, they also need a Linux agent.
> >>
> >> If I understand the idea correctly, there's then a Linux companion agent
> >> that does, e.g., the cloud communication and sets up the update payload
> >> to be consumed and applied by the UEFI firmware update application. The
> >> actual update action will take place on reboot, e.g., flashing the
> >> inactive partition in an A/B setup and thereafter booting into the newly
> >> flashed, then active partition.
> >>
> >> If so, this would prolong the time the system is unavailable due to disk
> >> flashing I/O in the UEFI firmware update application compared to
> flashing
> >> the inactive partition from within Linux and have the bootloader just
> >> switch the to be booted partitions.
> >>
> >> Generally, but in particular regarding binary diffs, a binary diff
> >> application mechanism would have to be implemented and maintained in the
> >> UEFI realm as opposed to "just" using the respective shared libraries
> >> (e.g. librsync, casync, ...) in the Linux realm. Granted, one could
> >> come up with a unified format to which the output of, e.g, librsync's
> rdiff
> >> or a casync run is converted but nonetheless, this creates some porting/
> >> implementation and maintenance effort.
> >>
> >>
> > Here are the guiding principles of our efforts :
> > 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
> > processor model update solution
> > 1) untrusted world cannot update trusted world
>
> Conceptually, it can. It's a matter of validating the update by the
> trusted
> world before using it. A trusted instance can allow an untrusted one to
> write
> version 2, validate that before switching to it, and stick with version 1
> if
> that fails.
>
> Agreed. Then is a better principle:  untrusted world cannot directly
update trusted world objects that are part of the current chain of trust
   This would allow changing B partition while A is in force.
There may be another aspect to take into account, not every use case need
the same security "level".
May be a principle to define security levels and guidelines to achieve each
level is more relevant than the "untrusted world cannot directly update
trusted world objects that are part of the current chain of trust" which
implies a certain security level goal.

> 2) what the UEFI implementation does with the capsule is platform specific
> > 3) the update capsule payload is opaque
> >
> > 1) is a "philosophy" decision. When you have a root of trust down to
> > the operating system. So in theory everything should be fine. But the
> > attack surface is such that we can't rule out hacking (and history
> > prove this is unfortunately a safe assumption). In addition, there may
> > be liability aspects related to the who does the update: the hardware
> > platform administrator may not be the legal entity than the operating
> > system administrator. For instance:
> > -  on Packet.net could, a customer can flash up to the BL33 untrusted
> > firmware but that is all.
> > - A surveillance camera can be operated by city personnel but only law
> > enforcement agency can see raw video (un-blurred faces and licence
> > plates). This can be implemented by a derivative of OPTEE SecureMedia
> > Path but if you allow untrusted world to update the trusted one, city
> > personnel can overcome the legal restriction.
> > With 1) this means that even U-Boot code shall not be able/allowed to
> > update S-EL3 firmware (be it Trusted Firmware A or something else),
> > Secure EL1/0 software (OPTEE and its applications or something else).
> > If possible, allowing the operating system administrator to
> > selectively (BL33 is OK but not S-EL3) update firmware is at least
> > platform dependent. Hence defeats 0)
> >
> > With 2) we do not impose reboot to update. Some platform may impose
> > reboot or some designers will prefer reboot. We say that there is a
> > chain of responsibility for updates.
> > So it is perfectly OK to have a Linux software agent receive an update
> > by any mean (network, USB, serial...). The agent will pack this (or
> > those) into a capsule and push it to UEFI implementation.
> > The UEFI implementation (U-Boot or Tianocore) will then do whatever it
> > pleases for the update providing it complies with 1) So the UEFI
> > implementation can live update up to BL33 firmware.
> > Should the update be targeted to secure world, then the UEFI
> > implementation can pass it to S-EL3 for update (platform specific)
> > which means the update can also be live. It is a designer decision.
> >
> > With 3) we have flexibility but sometimes too much flexibility is a
> > problem. Alexander Graf suggested we can use a FIT object to pass
> > diverse objects. It is "half" opaque but I really like the idea.
> > The contents of individual FIT components can be blocks to be placed
> > at a fix location in a NOR flash or a file, no importance.
> >
> > What do everyone think about those design principles ?
> >
>
> UEFI and capsules can be fine for those platform that support it (and it's
> still
> a rare feature) and for stuff like boot and peripheral firmware. I don't
> think
> it's a wise, future-proof idea to use it for more.
>
> Agreed. if we say that {shim, grub , kernel, initrd, commandline} is to be
named the "BL33 payload" then they are out of scope of the UEFI update
capsules, as well as any untrusted apps.= (on top of OS).
Update capsules can be used to update firmwares of any sort, keys,
certificates, secrets, blobs that are for pre-BL33 execution environment.

UEFI is not a very healthy ecosystem yet, and I'm personally skeptical it
> will
> evolve towards that (looking at that as both a user as well as an OEM).
> It's not
> even present in quite a few of our use cases. In some it will never be -
> think
> of safety-critical system: not affordable with such a complex approach
> like
> UEFI. It should not expand further into OS domains. Updating complete
> filesystems and their content is beyond its duties. We have all the
> required,
> tested, matured means for the OS in the OS. For firmware, it can be an
> option -
> if that firmware is UEFI compliant, with all needed options.
>
> So let's use UEFI and capsules as a one possible building block in the
> design,
> but not as the cornerstone. Just like we do mandate that all updates must
> be
> served and managed by our IoT cloud ;).
>
> Agreed. Out of all the edge and fog deployments some will have very
specific requirements. This effort is not to rule them out as rule out
proprietary mechanisms. It is to say that 90% of the cases can be handled
by a generic method and we should define this one.

> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>


-- 
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Heinrich Schuchardt]

On 4/26/19 1:21 PM, Jan Kiszka wrote:
> On 26.04.19 12:21, Grant Likely wrote:
>> On 26/04/2019 10:49, Jan Kiszka wrote:
>>> On 26.04.19 11:07, Francois Ozog wrote:
>> [...]
>>>> Here are the guiding principles of our efforts :
>>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>>> processor model update solution
>>>> 1) untrusted world cannot update trusted world
>>>
>>> Conceptually, it can. It's a matter of validating the update by the
>>> trusted world before using it. A trusted instance can allow an untrusted
>>> one to write version 2, validate that before switching to it, and stick
>>> with version 1 if that fails.
>>>
>>>> 2) what the UEFI implementation does with the capsule is platform
>>>> specific
>>>> 3) the update capsule payload is opaque
>>>>
>>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>>> the operating system. So in theory everything should be fine. But the
>>>> attack surface is such that we can't rule out hacking (and history
>>>> prove this is unfortunately a safe assumption). In addition, there may
>>>> be liability aspects related to the who does the update: the hardware
>>>> platform administrator may not be the legal entity than the operating
>>>> system administrator. For instance:
>>>> -? on Packet.net could, a customer can flash up to the BL33 untrusted
>>>> firmware but that is all.
>>>> - A surveillance camera can be operated by city personnel but only law
>>>> enforcement agency can see raw video (un-blurred faces and licence
>>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>>> Path but if you allow untrusted world to update the trusted one, city
>>>> personnel can overcome the legal restriction.
>>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>>> If possible, allowing the operating system administrator to
>>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>>> platform dependent. Hence defeats 0)
>>>>
>>>> With 2) we do not impose reboot to update. Some platform may impose
>>>> reboot or some designers will prefer reboot. We say that there is a
>>>> chain of responsibility for updates.
>>>> So it is perfectly OK to have a Linux software agent receive an update
>>>> by any mean (network, USB, serial...). The agent will pack this (or
>>>> those) into a capsule and push it to UEFI implementation.
>>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>>> pleases for the update providing it complies with 1) So the UEFI
>>>> implementation can live update up to BL33 firmware.
>>>> Should the update be targeted to secure world, then the UEFI
>>>> implementation can pass it to S-EL3 for update (platform specific)
>>>> which means the update can also be live. It is a designer decision.
>>>>
>>>> With 3) we have flexibility but sometimes too much flexibility is a
>>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>>> diverse objects. It is "half" opaque but I really like the idea.
>>>> The contents of individual FIT components can be blocks to be placed
>>>> at a fix location in a NOR flash or a file, no importance.
>>>>
>>>> What do everyone think about those design principles ?
>>>>
>>>
>>> UEFI and capsules can be fine for those platform that support it (and
>>> it's still a rare feature) and for stuff like boot and peripheral
>>> firmware. I don't think it's a wise, future-proof idea to use it for
>>> more.
>>>
>>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>>> it will evolve towards that (looking at that as both a user as well as
>>> an OEM). It's not even present in quite a few of our use cases. In some
>>> it will never be - think of safety-critical system: not affordable with
>>> such a complex approach like UEFI.
>>
>> Can I challenge that view a bit? On the Tianocore side I agree that the
>> ecosystem isn't very healthy. That project in particular struggles with
>> what to do with board support, having decided early on that board
>> support generally doesn't need to be in the main repository.
>>
>> However, U-Boot support for the UEFI ABI is improving in leaps and
>> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
>> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
>> config option or two. There is a fair bit of encouragement from within
>> the project to enable UEFI by default.
>
> I don't disagree that this aspect is a step forward (though pulling in
> things redundant code via grub & Co is not really progress). But a Unix
> community would have probably designed a technically more elegant
> solution on a green field than the clumsy, legacy-based UEFI interfaces.
>
>>
>> UEFI gets a bad rap at being complicated, but I think the U-Boot work
>> has shown that implementing the core UEFI ABI doesn't require much code
>> and isn't the complicated mess they everyone fears it to be.
>
> Depends on how much you start to rely on UEFI features.

The format for a UEFI capsule is described in the
EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially
it is a file containing multiple UEFI binaries which are individually
signed and can be loaded as UEFI boottime drivers. Further payloads are
passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL.

Two ways for the delivery of a capsule are defined. Capsules can be
delivered by placing a file in the \EFI\UpdateCapsule directory or by
calling the UpdateCapsule() boot service. The UpdateCapsule() boot
service can either be implemented as available at boottime only or as a
full runtime service.

The development target that we have defined for U-Boot is to reach
conformance to the Embedded Base Boot Requirements (EBBR) specification.
EBBR 1.0 does not mandate implementing update via UEFI capsules.

In U-Boot we have severe size limitations. On many boards U-Boot has to
fit into 512 kB. So I think we should not link the capsule update
functionality into the main U-Boot binary.

The implementation of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL will be
device specific. So if you are interested in adding capsule support I
think it should be provided as a device specific UEFI driver that can be
loaded by U-Boot.

Currently loading and unloading of drivers is not fully implemented in
U-Boot. But it is on my agenda.

Best regards

Heinrich

>
>>
>> I don't see the conflict with safety critical for boot services. I can
>
> Everything is certifiable - with infinite time and money. So you will
> likely reduce the boot process to the very essential of your concrete
> system, removing then unneeded abstractions and stages. Or you will find
> ways to eliminate that from your argumentation, which would definitely
> include removing runtime services.
>
>> however see the arguement against UEFI runtime services as a poor
>> implementation could result in unbounded execution times. There's been
>> recent movement on the UEFI spec to make runtime services optional, and
>> in U-Boot they are mostly empty stubs.
>
> Of course, it also depends on how much you need from UEFI to boot or to
> use certain services like capsule updates (and which would be gone when
> you remove runtime services).
>
>>
>>> It should not expand further into OS
>>> domains. Updating complete filesystems and their content is beyond its
>>> duties. We have all the required, tested, matured means for the OS in
>>> the OS. For firmware, it can be an option - if that firmware is UEFI
>>> compliant, with all needed options.
>>
>> Here I agree 100%. Capsule update is a useful ABI for the OS to pass
>> firmware update blobs without needing to know specifics about the
>> platform, but everything from the kernel on up is out of scope.
>
> OK, that's good.
>
>>
>>> So let's use UEFI and capsules as a one possible building block in the
>>> design, but not as the cornerstone. Just like we do mandate that all
>>> updates must be served and managed by our IoT cloud ;).
>>
>> What do the firmware stacks in your projects look like? What percentage
>> are based on U-Boot? Littlekernel? Others?
>
> I don't have absolute numbers. We have a lot of "standard" x86 UEFI
> systems, many U-boot devices (of which, to my knowledge, none is on UEFI
> yet - no surprise, that feature is still too "new"), and quite a few
> Coreboot designs (so far only x86) that just need to load Linux and
> bypass a lot therefore. There will likely be more exotic things but they
> will likely also do not deserve attention.
>
>>
>> UEFI has the advantage that it has a defined ABI, and only a small
>> amount of it needs to be implemented to execute UEFI OS loaders (ie. the
>> Linux UEFI stub). For the reference platform, I think it makes sense to
>> make the design decision that firmware provides UEFI, and the update
>> infrastructure is based on that. However, if UEFI doesn't work for a
>> particular stack/project then it can be swapped out. There will need to
>> be work done on the boot sequence, but all the rest of the OS stack is
>> still relevant.
>
> Yes, I would design it in a way that a perfect UEFI implementation can
> take a lot of boot-related tasks like safe boot configuration switching,
> watchdog management, firmware and peripheral updating (possibly in
> lock-step with the OS) etc. But I would always ensure that incomplete or
> immature UEFI implementations will not complicate partial or complete
> replacements. Because the latter will remain the default for quite a
> while, if not longer, I'm sure. UEFI should not become the systemd of
> unattended device updates (or worse, due to closed implementations).
>
> Jan
>

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Heinrich Schuchardt]

On 4/26/19 1:21 PM, Jan Kiszka wrote:
> On 26.04.19 12:21, Grant Likely wrote:
>> On 26/04/2019 10:49, Jan Kiszka wrote:
>>> On 26.04.19 11:07, Francois Ozog wrote:
>> [...]
>>>> Here are the guiding principles of our efforts :
>>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>>> processor model update solution
>>>> 1) untrusted world cannot update trusted world
>>>
>>> Conceptually, it can. It's a matter of validating the update by the
>>> trusted world before using it. A trusted instance can allow an untrusted
>>> one to write version 2, validate that before switching to it, and stick
>>> with version 1 if that fails.
>>>
>>>> 2) what the UEFI implementation does with the capsule is platform
>>>> specific
>>>> 3) the update capsule payload is opaque
>>>>
>>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>>> the operating system. So in theory everything should be fine. But the
>>>> attack surface is such that we can't rule out hacking (and history
>>>> prove this is unfortunately a safe assumption). In addition, there may
>>>> be liability aspects related to the who does the update: the hardware
>>>> platform administrator may not be the legal entity than the operating
>>>> system administrator. For instance:
>>>> -  on Packet.net could, a customer can flash up to the BL33 untrusted
>>>> firmware but that is all.
>>>> - A surveillance camera can be operated by city personnel but only law
>>>> enforcement agency can see raw video (un-blurred faces and licence
>>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>>> Path but if you allow untrusted world to update the trusted one, city
>>>> personnel can overcome the legal restriction.
>>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>>> If possible, allowing the operating system administrator to
>>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>>> platform dependent. Hence defeats 0)
>>>>
>>>> With 2) we do not impose reboot to update. Some platform may impose
>>>> reboot or some designers will prefer reboot. We say that there is a
>>>> chain of responsibility for updates.
>>>> So it is perfectly OK to have a Linux software agent receive an update
>>>> by any mean (network, USB, serial...). The agent will pack this (or
>>>> those) into a capsule and push it to UEFI implementation.
>>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>>> pleases for the update providing it complies with 1) So the UEFI
>>>> implementation can live update up to BL33 firmware.
>>>> Should the update be targeted to secure world, then the UEFI
>>>> implementation can pass it to S-EL3 for update (platform specific)
>>>> which means the update can also be live. It is a designer decision.
>>>>
>>>> With 3) we have flexibility but sometimes too much flexibility is a
>>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>>> diverse objects. It is "half" opaque but I really like the idea.
>>>> The contents of individual FIT components can be blocks to be placed
>>>> at a fix location in a NOR flash or a file, no importance.
>>>>
>>>> What do everyone think about those design principles ?
>>>>
>>>
>>> UEFI and capsules can be fine for those platform that support it (and
>>> it's still a rare feature) and for stuff like boot and peripheral
>>> firmware. I don't think it's a wise, future-proof idea to use it for
>>> more.
>>>
>>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>>> it will evolve towards that (looking at that as both a user as well as
>>> an OEM). It's not even present in quite a few of our use cases. In some
>>> it will never be - think of safety-critical system: not affordable with
>>> such a complex approach like UEFI.
>>
>> Can I challenge that view a bit? On the Tianocore side I agree that the
>> ecosystem isn't very healthy. That project in particular struggles with
>> what to do with board support, having decided early on that board
>> support generally doesn't need to be in the main repository.
>>
>> However, U-Boot support for the UEFI ABI is improving in leaps and
>> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
>> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
>> config option or two. There is a fair bit of encouragement from within
>> the project to enable UEFI by default.
>
> I don't disagree that this aspect is a step forward (though pulling in
> things redundant code via grub & Co is not really progress). But a Unix
> community would have probably designed a technically more elegant
> solution on a green field than the clumsy, legacy-based UEFI interfaces.
>
>>
>> UEFI gets a bad rap at being complicated, but I think the U-Boot work
>> has shown that implementing the core UEFI ABI doesn't require much code
>> and isn't the complicated mess they everyone fears it to be.
>
> Depends on how much you start to rely on UEFI features.

The format for a UEFI capsule is described in the
EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially
it is a file containing multiple UEFI binaries which are individually
signed and can be loaded as UEFI boottime drivers. Further payloads are
passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL.

Two ways for the delivery of a capsule are defined. Capsules can be
delivered by placing a file in the \EFI\UpdateCapsule directory or by
calling the UpdateCapsule() boot service. The UpdateCapsule() boot
service can either be implemented as available at boottime only or as a
full runtime service.

The development target that we have defined for U-Boot is to reach
conformance to the Embedded Base Boot Requirements (EBBR) specification.
EBBR 1.0 does not mandate implementing update via UEFI capsules.

In U-Boot we have severe size limitations. On many boards U-Boot has to
fit into 512 kB. So I think we should not link the capsule update
functionality into the main U-Boot binary.

The implementation of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL will be
device specific. So if you are interested in adding capsule support I
think it should be provided as a device specific UEFI driver that can be
loaded by U-Boot.

Currently loading and unloading of drivers is not fully implemented in
U-Boot. But it is on my agenda.

Best regards

Heinrich

>
>>
>> I don't see the conflict with safety critical for boot services. I can
>
> Everything is certifiable - with infinite time and money. So you will
> likely reduce the boot process to the very essential of your concrete
> system, removing then unneeded abstractions and stages. Or you will find
> ways to eliminate that from your argumentation, which would definitely
> include removing runtime services.
>
>> however see the arguement against UEFI runtime services as a poor
>> implementation could result in unbounded execution times. There's been
>> recent movement on the UEFI spec to make runtime services optional, and
>> in U-Boot they are mostly empty stubs.
>
> Of course, it also depends on how much you need from UEFI to boot or to
> use certain services like capsule updates (and which would be gone when
> you remove runtime services).
>
>>
>>> It should not expand further into OS
>>> domains. Updating complete filesystems and their content is beyond its
>>> duties. We have all the required, tested, matured means for the OS in
>>> the OS. For firmware, it can be an option - if that firmware is UEFI
>>> compliant, with all needed options.
>>
>> Here I agree 100%. Capsule update is a useful ABI for the OS to pass
>> firmware update blobs without needing to know specifics about the
>> platform, but everything from the kernel on up is out of scope.
>
> OK, that's good.
>
>>
>>> So let's use UEFI and capsules as a one possible building block in the
>>> design, but not as the cornerstone. Just like we do mandate that all
>>> updates must be served and managed by our IoT cloud ;).
>>
>> What do the firmware stacks in your projects look like? What percentage
>> are based on U-Boot? Littlekernel? Others?
>
> I don't have absolute numbers. We have a lot of "standard" x86 UEFI
> systems, many U-boot devices (of which, to my knowledge, none is on UEFI
> yet - no surprise, that feature is still too "new"), and quite a few
> Coreboot designs (so far only x86) that just need to load Linux and
> bypass a lot therefore. There will likely be more exotic things but they
> will likely also do not deserve attention.
>
>>
>> UEFI has the advantage that it has a defined ABI, and only a small
>> amount of it needs to be implemented to execute UEFI OS loaders (ie. the
>> Linux UEFI stub). For the reference platform, I think it makes sense to
>> make the design decision that firmware provides UEFI, and the update
>> infrastructure is based on that. However, if UEFI doesn't work for a
>> particular stack/project then it can be swapped out. There will need to
>> be work done on the boot sequence, but all the rest of the OS stack is
>> still relevant.
>
> Yes, I would design it in a way that a perfect UEFI implementation can
> take a lot of boot-related tasks like safe boot configuration switching,
> watchdog management, firmware and peripheral updating (possibly in
> lock-step with the OS) etc. But I would always ensure that incomplete or
> immature UEFI implementations will not complicate partial or complete
> replacements. Because the latter will remain the default for quite a
> while, if not longer, I'm sure. UEFI should not become the systemd of
> unattended device updates (or worse, due to closed implementations).
>
> Jan
>

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Alexander Graf]

On 26.04.19 15:46, Heinrich Schuchardt wrote:
>
> On 4/26/19 1:21 PM, Jan Kiszka wrote:
>> On 26.04.19 12:21, Grant Likely wrote:
>>> On 26/04/2019 10:49, Jan Kiszka wrote:
>>>> On 26.04.19 11:07, Francois Ozog wrote:
>>> [...]
>>>>> Here are the guiding principles of our efforts :
>>>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>>>> processor model update solution
>>>>> 1) untrusted world cannot update trusted world
>>>> Conceptually, it can. It's a matter of validating the update by the
>>>> trusted world before using it. A trusted instance can allow an untrusted
>>>> one to write version 2, validate that before switching to it, and stick
>>>> with version 1 if that fails.
>>>>
>>>>> 2) what the UEFI implementation does with the capsule is platform
>>>>> specific
>>>>> 3) the update capsule payload is opaque
>>>>>
>>>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>>>> the operating system. So in theory everything should be fine. But the
>>>>> attack surface is such that we can't rule out hacking (and history
>>>>> prove this is unfortunately a safe assumption). In addition, there may
>>>>> be liability aspects related to the who does the update: the hardware
>>>>> platform administrator may not be the legal entity than the operating
>>>>> system administrator. For instance:
>>>>> -? on Packet.net could, a customer can flash up to the BL33 untrusted
>>>>> firmware but that is all.
>>>>> - A surveillance camera can be operated by city personnel but only law
>>>>> enforcement agency can see raw video (un-blurred faces and licence
>>>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>>>> Path but if you allow untrusted world to update the trusted one, city
>>>>> personnel can overcome the legal restriction.
>>>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>>>> If possible, allowing the operating system administrator to
>>>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>>>> platform dependent. Hence defeats 0)
>>>>>
>>>>> With 2) we do not impose reboot to update. Some platform may impose
>>>>> reboot or some designers will prefer reboot. We say that there is a
>>>>> chain of responsibility for updates.
>>>>> So it is perfectly OK to have a Linux software agent receive an update
>>>>> by any mean (network, USB, serial...). The agent will pack this (or
>>>>> those) into a capsule and push it to UEFI implementation.
>>>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>>>> pleases for the update providing it complies with 1) So the UEFI
>>>>> implementation can live update up to BL33 firmware.
>>>>> Should the update be targeted to secure world, then the UEFI
>>>>> implementation can pass it to S-EL3 for update (platform specific)
>>>>> which means the update can also be live. It is a designer decision.
>>>>>
>>>>> With 3) we have flexibility but sometimes too much flexibility is a
>>>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>>>> diverse objects. It is "half" opaque but I really like the idea.
>>>>> The contents of individual FIT components can be blocks to be placed
>>>>> at a fix location in a NOR flash or a file, no importance.
>>>>>
>>>>> What do everyone think about those design principles ?
>>>>>
>>>> UEFI and capsules can be fine for those platform that support it (and
>>>> it's still a rare feature) and for stuff like boot and peripheral
>>>> firmware. I don't think it's a wise, future-proof idea to use it for
>>>> more.
>>>>
>>>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>>>> it will evolve towards that (looking at that as both a user as well as
>>>> an OEM). It's not even present in quite a few of our use cases. In some
>>>> it will never be - think of safety-critical system: not affordable with
>>>> such a complex approach like UEFI.
>>> Can I challenge that view a bit? On the Tianocore side I agree that the
>>> ecosystem isn't very healthy. That project in particular struggles with
>>> what to do with board support, having decided early on that board
>>> support generally doesn't need to be in the main repository.
>>>
>>> However, U-Boot support for the UEFI ABI is improving in leaps and
>>> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
>>> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
>>> config option or two. There is a fair bit of encouragement from within
>>> the project to enable UEFI by default.
>> I don't disagree that this aspect is a step forward (though pulling in
>> things redundant code via grub & Co is not really progress). But a Unix
>> community would have probably designed a technically more elegant
>> solution on a green field than the clumsy, legacy-based UEFI interfaces.
>>
>>> UEFI gets a bad rap at being complicated, but I think the U-Boot work
>>> has shown that implementing the core UEFI ABI doesn't require much code
>>> and isn't the complicated mess they everyone fears it to be.
>> Depends on how much you start to rely on UEFI features.
> The format for a UEFI capsule is described in the
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially


Are you sure? I thought that protocol was about other devices in the
system, not the main firmware. It also seems to be optional - so we
could just have a board specific function to implement CapsuleUpdate,
but no cruft for all the other bits in the spec.

That's where the idea came from to just put a fit image into the capsule
body (set CapsuleGUID to a newly defined FIT-GUID). With that, we could
share a lot of code inside of U-Boot, as DT parsing is already there. We
could then have individual segments, that can either be data or command
payloads and thus a capsule update could basically just be a few data
segments with a U-Boot script.


> it is a file containing multiple UEFI binaries which are individually
> signed and can be loaded as UEFI boottime drivers. Further payloads are
> passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL.
>
> Two ways for the delivery of a capsule are defined. Capsules can be
> delivered by placing a file in the \EFI\UpdateCapsule directory or by
> calling the UpdateCapsule() boot service. The UpdateCapsule() boot
> service can either be implemented as available at boottime only or as a
> full runtime service.
>
> The development target that we have defined for U-Boot is to reach
> conformance to the Embedded Base Boot Requirements (EBBR) specification.
> EBBR 1.0 does not mandate implementing update via UEFI capsules.


Correct, this is about post-1.0 :).


> In U-Boot we have severe size limitations. On many boards U-Boot has to
> fit into 512 kB. So I think we should not link the capsule update
> functionality into the main U-Boot binary.
>
> The implementation of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL will be
> device specific. So if you are interested in adding capsule support I
> think it should be provided as a device specific UEFI driver that can be
> loaded by U-Boot.
>
> Currently loading and unloading of drivers is not fully implemented in
> U-Boot. But it is on my agenda.


One of the things I love about U-Boot is that it's monolithic :). As an
end user, it means that I get something and it just contains everything
I need. Imagine a world where you first have to load your driver to
update your firmware from some arbitrary storage. It would create a huge
mess.


Alex

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Alexander Graf]

On 26.04.19 15:46, Heinrich Schuchardt wrote:
>
> On 4/26/19 1:21 PM, Jan Kiszka wrote:
>> On 26.04.19 12:21, Grant Likely wrote:
>>> On 26/04/2019 10:49, Jan Kiszka wrote:
>>>> On 26.04.19 11:07, Francois Ozog wrote:
>>> [...]
>>>>> Here are the guiding principles of our efforts :
>>>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>>>> processor model update solution
>>>>> 1) untrusted world cannot update trusted world
>>>> Conceptually, it can. It's a matter of validating the update by the
>>>> trusted world before using it. A trusted instance can allow an untrusted
>>>> one to write version 2, validate that before switching to it, and stick
>>>> with version 1 if that fails.
>>>>
>>>>> 2) what the UEFI implementation does with the capsule is platform
>>>>> specific
>>>>> 3) the update capsule payload is opaque
>>>>>
>>>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>>>> the operating system. So in theory everything should be fine. But the
>>>>> attack surface is such that we can't rule out hacking (and history
>>>>> prove this is unfortunately a safe assumption). In addition, there may
>>>>> be liability aspects related to the who does the update: the hardware
>>>>> platform administrator may not be the legal entity than the operating
>>>>> system administrator. For instance:
>>>>> -  on Packet.net could, a customer can flash up to the BL33 untrusted
>>>>> firmware but that is all.
>>>>> - A surveillance camera can be operated by city personnel but only law
>>>>> enforcement agency can see raw video (un-blurred faces and licence
>>>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>>>> Path but if you allow untrusted world to update the trusted one, city
>>>>> personnel can overcome the legal restriction.
>>>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>>>> If possible, allowing the operating system administrator to
>>>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>>>> platform dependent. Hence defeats 0)
>>>>>
>>>>> With 2) we do not impose reboot to update. Some platform may impose
>>>>> reboot or some designers will prefer reboot. We say that there is a
>>>>> chain of responsibility for updates.
>>>>> So it is perfectly OK to have a Linux software agent receive an update
>>>>> by any mean (network, USB, serial...). The agent will pack this (or
>>>>> those) into a capsule and push it to UEFI implementation.
>>>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>>>> pleases for the update providing it complies with 1) So the UEFI
>>>>> implementation can live update up to BL33 firmware.
>>>>> Should the update be targeted to secure world, then the UEFI
>>>>> implementation can pass it to S-EL3 for update (platform specific)
>>>>> which means the update can also be live. It is a designer decision.
>>>>>
>>>>> With 3) we have flexibility but sometimes too much flexibility is a
>>>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>>>> diverse objects. It is "half" opaque but I really like the idea.
>>>>> The contents of individual FIT components can be blocks to be placed
>>>>> at a fix location in a NOR flash or a file, no importance.
>>>>>
>>>>> What do everyone think about those design principles ?
>>>>>
>>>> UEFI and capsules can be fine for those platform that support it (and
>>>> it's still a rare feature) and for stuff like boot and peripheral
>>>> firmware. I don't think it's a wise, future-proof idea to use it for
>>>> more.
>>>>
>>>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>>>> it will evolve towards that (looking at that as both a user as well as
>>>> an OEM). It's not even present in quite a few of our use cases. In some
>>>> it will never be - think of safety-critical system: not affordable with
>>>> such a complex approach like UEFI.
>>> Can I challenge that view a bit? On the Tianocore side I agree that the
>>> ecosystem isn't very healthy. That project in particular struggles with
>>> what to do with board support, having decided early on that board
>>> support generally doesn't need to be in the main repository.
>>>
>>> However, U-Boot support for the UEFI ABI is improving in leaps and
>>> bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all
>>> the Arm SBCs that they support, and enabling UEFI in U-Boot is just a
>>> config option or two. There is a fair bit of encouragement from within
>>> the project to enable UEFI by default.
>> I don't disagree that this aspect is a step forward (though pulling in
>> things redundant code via grub & Co is not really progress). But a Unix
>> community would have probably designed a technically more elegant
>> solution on a green field than the clumsy, legacy-based UEFI interfaces.
>>
>>> UEFI gets a bad rap at being complicated, but I think the U-Boot work
>>> has shown that implementing the core UEFI ABI doesn't require much code
>>> and isn't the complicated mess they everyone fears it to be.
>> Depends on how much you start to rely on UEFI features.
> The format for a UEFI capsule is described in the
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially


Are you sure? I thought that protocol was about other devices in the
system, not the main firmware. It also seems to be optional - so we
could just have a board specific function to implement CapsuleUpdate,
but no cruft for all the other bits in the spec.

That's where the idea came from to just put a fit image into the capsule
body (set CapsuleGUID to a newly defined FIT-GUID). With that, we could
share a lot of code inside of U-Boot, as DT parsing is already there. We
could then have individual segments, that can either be data or command
payloads and thus a capsule update could basically just be a few data
segments with a U-Boot script.


> it is a file containing multiple UEFI binaries which are individually
> signed and can be loaded as UEFI boottime drivers. Further payloads are
> passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL.
>
> Two ways for the delivery of a capsule are defined. Capsules can be
> delivered by placing a file in the \EFI\UpdateCapsule directory or by
> calling the UpdateCapsule() boot service. The UpdateCapsule() boot
> service can either be implemented as available at boottime only or as a
> full runtime service.
>
> The development target that we have defined for U-Boot is to reach
> conformance to the Embedded Base Boot Requirements (EBBR) specification.
> EBBR 1.0 does not mandate implementing update via UEFI capsules.


Correct, this is about post-1.0 :).


> In U-Boot we have severe size limitations. On many boards U-Boot has to
> fit into 512 kB. So I think we should not link the capsule update
> functionality into the main U-Boot binary.
>
> The implementation of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL will be
> device specific. So if you are interested in adding capsule support I
> think it should be provided as a device specific UEFI driver that can be
> loaded by U-Boot.
>
> Currently loading and unloading of drivers is not fully implemented in
> U-Boot. But it is on my agenda.


One of the things I love about U-Boot is that it's monolithic :). As an
end user, it means that I get something and it just contains everything
I need. Imagine a world where you first have to load your driver to
update your firmware from some arbitrary storage. It would create a huge
mess.


Alex

[cip-dev] EFIBootGuard for CIP and SecureBoot

[Peter Jones]

On Sat, Apr 27, 2019 at 09:56:08AM +0200, Alexander Graf wrote:
> 
> >>> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> >>> has shown that implementing the core UEFI ABI doesn't require much code
> >>> and isn't the complicated mess they everyone fears it to be.
> >> Depends on how much you start to rely on UEFI features.
> > The format for a UEFI capsule is described in the
> > EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially
> 
> Are you sure? I thought that protocol was about other devices in the
> system, not the main firmware. It also seems to be optional - so we
> could just have a board specific function to implement CapsuleUpdate,
> but no cruft for all the other bits in the spec.

There's no requirement to use that format in order to use capsule
updates, but some vendors have found it convenient.  There's also no
requirement to implement the EFI_FIRMWARE_MANAGEMENT_PROTOCOL at all -
and the only place it's distinctly useful from an application point of
view (i.e. while trying to drive a firmware update) is if you want to
independently update two of the same kind of peripheral device's
firmware from within a UEFI application.  It's not clear to me that's a
very interesting use case from an EBBR point of view - I'm haven't seen
much demand for it on server, laptop, or desktop systems either.

But it's also how option ROMs register their firmware to be updated via
UpdateCapsule().  That's interesting on machines where you regularly
expect peripherals to be in PCIe slots, but I'm still not sure it's that
useful for EBBR style devices.  I guess it could be useful in the
thunderbolt case, but I think in order to avoid thwarting DMA attack
mitigations, that would best be done from the OS just like for USB
devices.

> That's where the idea came from to just put a fit image into the capsule
> body (set CapsuleGUID to a newly defined FIT-GUID). With that, we could
> share a lot of code inside of U-Boot, as DT parsing is already there. We
> could then have individual segments, that can either be data or command
> payloads and thus a capsule update could basically just be a few data
> segments with a U-Boot script.

This makes a lot of sense to me, though there have been some pain points
about this approach in the past.  The biggest one is because the
EFI_FIRMWARE_MANAGEMENT_PROTOCOL capsule format has a header on it
that's the same as the EFI_CAPSULE_HEADER structure, which we have to
add in fwupd if we can't find it.  If we plan on recommending that
vendors implement these ad-hoc firmware blobs, we should also require
that when they do so, they already include the EFI_CAPSULE_HEADER on the
image, with a GUID that matches what's in the ESRT, and is specifically
not EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID.

> > it is a file containing multiple UEFI binaries which are individually
> > signed and can be loaded as UEFI boottime drivers. Further payloads are
> > passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL.
> >
> > Two ways for the delivery of a capsule are defined.

Three, I think?  I'm not seeing why an application can't also call
FMP->SetImage() to do this when it's present.  I'm not sure it's worth
supporting at all, though.

> > Capsules can be delivered by placing a file in the
> > \EFI\UpdateCapsule directory or by calling the UpdateCapsule() boot
> > service. The UpdateCapsule() boot service can either be implemented
> > as available at boottime only or as a full runtime service.

Right now in fwupd we support only boot-service calls to do this,
because of the history of bugs with SetVirtualAddressMap() and
ExitBootServices(), and because it's the only thing required to be
tested for Windows logo cert.  I suspect MS has made that the case
because of the exact same bugs.

The path-based mechanism makes a lot of sense with EBBR, but runtime
UpdateCapsule() is a lot more viable here than on the desktop or
servers as well.  The reason I say that is because with these devices
we're more in a situation where the hardware vendor is likely to be
producing the kernel as well, so there's a better integration testing
story here.

-- 
  Peter

[U-Boot] EFIBootGuard for CIP and SecureBoot

[Peter Jones]

On Sat, Apr 27, 2019 at 09:56:08AM +0200, Alexander Graf wrote:
> 
> >>> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> >>> has shown that implementing the core UEFI ABI doesn't require much code
> >>> and isn't the complicated mess they everyone fears it to be.
> >> Depends on how much you start to rely on UEFI features.
> > The format for a UEFI capsule is described in the
> > EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially
> 
> Are you sure? I thought that protocol was about other devices in the
> system, not the main firmware. It also seems to be optional - so we
> could just have a board specific function to implement CapsuleUpdate,
> but no cruft for all the other bits in the spec.

There's no requirement to use that format in order to use capsule
updates, but some vendors have found it convenient.  There's also no
requirement to implement the EFI_FIRMWARE_MANAGEMENT_PROTOCOL at all -
and the only place it's distinctly useful from an application point of
view (i.e. while trying to drive a firmware update) is if you want to
independently update two of the same kind of peripheral device's
firmware from within a UEFI application.  It's not clear to me that's a
very interesting use case from an EBBR point of view - I'm haven't seen
much demand for it on server, laptop, or desktop systems either.

But it's also how option ROMs register their firmware to be updated via
UpdateCapsule().  That's interesting on machines where you regularly
expect peripherals to be in PCIe slots, but I'm still not sure it's that
useful for EBBR style devices.  I guess it could be useful in the
thunderbolt case, but I think in order to avoid thwarting DMA attack
mitigations, that would best be done from the OS just like for USB
devices.

> That's where the idea came from to just put a fit image into the capsule
> body (set CapsuleGUID to a newly defined FIT-GUID). With that, we could
> share a lot of code inside of U-Boot, as DT parsing is already there. We
> could then have individual segments, that can either be data or command
> payloads and thus a capsule update could basically just be a few data
> segments with a U-Boot script.

This makes a lot of sense to me, though there have been some pain points
about this approach in the past.  The biggest one is because the
EFI_FIRMWARE_MANAGEMENT_PROTOCOL capsule format has a header on it
that's the same as the EFI_CAPSULE_HEADER structure, which we have to
add in fwupd if we can't find it.  If we plan on recommending that
vendors implement these ad-hoc firmware blobs, we should also require
that when they do so, they already include the EFI_CAPSULE_HEADER on the
image, with a GUID that matches what's in the ESRT, and is specifically
not EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID.

> > it is a file containing multiple UEFI binaries which are individually
> > signed and can be loaded as UEFI boottime drivers. Further payloads are
> > passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL.
> >
> > Two ways for the delivery of a capsule are defined.

Three, I think?  I'm not seeing why an application can't also call
FMP->SetImage() to do this when it's present.  I'm not sure it's worth
supporting at all, though.

> > Capsules can be delivered by placing a file in the
> > \EFI\UpdateCapsule directory or by calling the UpdateCapsule() boot
> > service. The UpdateCapsule() boot service can either be implemented
> > as available at boottime only or as a full runtime service.

Right now in fwupd we support only boot-service calls to do this,
because of the history of bugs with SetVirtualAddressMap() and
ExitBootServices(), and because it's the only thing required to be
tested for Windows logo cert.  I suspect MS has made that the case
because of the exact same bugs.

The path-based mechanism makes a lot of sense with EBBR, but runtime
UpdateCapsule() is a lot more viable here than on the desktop or
servers as well.  The reason I say that is because with these devices
we're more in a situation where the hardware vendor is likely to be
producing the kernel as well, so there's a better integration testing
story here.

-- 
  Peter