Re: Friday 13th agenda

[Chris Koch]

Continuing this conversation on the mailing list. -everybody else

> UEFi is an interface , not source code.

We are aware that UEFI is just an interface - and we've gone down that road, actually. Similar to the u-boot work, we implemented UEFI Boot Services as a Linux kernel module in this proof of concept. It's about ~4000 (unclean) lines of code in the kernel, and it successfully boots Windows (for some... for some it crashes; it is a PoC after all). This work also uncovered a minimum set of Boot Services and protocols to implement in order to boot Windows. We talk about that set just a little bit here.

This makes Linux "just" another implementation of UEFI. We did not implement Secure Boot, but I can imagine it being a good idea. We also did not implement Capsule Update support, and I feel less warm about letting that concept stay alive. (I won't keep anyone else from doing it, of course, and contributing it upstream. I just ask that there always be the option to turn it off.)

Jonathan Zhang (cc'd) from FB has been talking about proposing a "minimal subset" of Boot Services (+ protocols + tables) that OSes should support, in order to limit the amount of stuff we'd have to reimplement, essentially making others optional. You may want to collaborate on this.

On Mon, Mar 9, 2020 at 9:42 AM Francois Ozog <franco...@linaro.org> wrote:

Le lun. 9 mars 2020 à 17:32, Gan Shun Lim <gan...@google.com> a écrit :

As a counterpoint, +Ryan O'Leary has done preliminary work on removing
the entirety of UEFI on an ARM system and just directly booting via
Linuxboot.

UEFi is an interface , not source code. In that context, to be EBBR compliant you need boot firmware (U-Boot in our case) to present an UEFI interface to OS. You probably think UEFI is equivalent to EDK2 while EDK2 is only one open source project that implements UEFI interface. As a result of our work you have an extended UEFI support with U-Boot (RAnddom number generator, SecureBoot, update capsule ...). We implement update capsule to that we can transparently benefit from platform specific anti ticking anti rollback.

I mentioned Xen: xen would be booted directly by trusted firmware A and then provide a UEFI interface to the loaded OSes (paravirtualized optimized U-Boot with UEFI).

If we assume TF A loads LinuxBoot. Would it be valid to have LinuxBoot provide UEFI interface (not talking about running EDK2 here) to the loaded OS for SecureBoot and update capsule handling ?

ARM systems do not actually have strict requirements on
UEFI (especially PEI), unlike Intel systems. I would like to not see
the UEFI interface become a requirement for booting on ARM, when today
it is perfectly possible to do so without. However I would be
interested in hearing more.

On Mon, Mar 9, 2020 at 2:49 AM Francois Ozog <franco...@linaro.org> wrote:
>
> Hi,
>
> As this Friday is Friday 13th, I felt it was perfect timing to throw me into
> trouble:
>
> at Linaro we are making huge efforts to implement Arm "Embedded
> Base Boot Requirements" specification (which essentially means UEFI
> interface subset compliance) in a number of code bases such as U-Boot
> and most certainly Xen. We are also spending a lot of energy in working
> around Device Tree standardization, lifecycle, evolution and overlays.
>
> I would be happy to briefly share intent of those activities to get your
> point of views.
>
> Cordially
>
> François-Frédéric



--
Gan

--

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

[Ron Minnich]

As Chris mentions, we're well aware that UEFI is an interface, and we've done work to support it.

But it's not an interface everyone wants. In many cases, it does not provide anything of value (see: chromebooks, which stopped using UEFI 10 years ago, and have been just fine).

So, while there will be a need, in some cases, for linuxboot to support UEFI; in many cases, UEFI will not be needed, and is not wanted. We need to keep that in mind.

ron

[Francois Ozog]

On Tue, 10 Mar 2020 at 03:13, Ron Minnich <rmin...@google.com> wrote:

As Chris mentions, we're well aware that UEFI is an interface, and we've done work to support it.

But it's not an interface everyone wants. In many cases, it does not provide anything of value (see: chromebooks, which stopped using UEFI 10 years ago, and have been just fine).

I agree. I expect to have: 

- full custom (proprietary code or not)

- VerifiedBoot

- EBBR: selected UEFI features (paragraph 2.6 plus other ones) with more precise "bounds" and additional explicit behaviror (anti-bricking...)

- "Full" UEFI:  I can't say what this exactly means, just that it has a lot of features, with the mandatory ones from paragraph 2.6

So, while there will be a need, in some cases, for linuxboot to support UEFI; in many cases, UEFI will not be needed, and is not wanted. We need to keep that in mind.

We share this view. 

[Francois Ozog]

On Tue, 10 Mar 2020 at 16:58, Jonathan Zhang (Infra) <jonz...@fb.com> wrote:

Hi Francois, I would like to hear more, in particular:

1. UEFI as a spec, defines mandatory interfaces and optional interfaces (such as secure boot and capsule update). The mandatory interface is rightly about firmware/OS interface, and is described in UEFI spec 2.8 section 2.6 table 13. That being said, table 13 asks for too much. Chris and team experimented booting windows from Linux, and found what’s really needed by windows is a small subset of table 13. What’s your take on table 13? How much is implemented in u-boot (and xen) for table 13?

EBBR is based on 2.7. The subset is still in discussion.  Let's say we are pragmatic people that want minimal constraints with maximal benefit for OS providers. Our reference target workloads for booting are Linux and Android. VB provides a nice standard for booting Android. We just need a Linux equivalent.

Table 13:

EFI_SYSTEM_TABLE:  OK
EFI_BOOT_SERVICES: <selected set>
EFI_RUNTIME_SERVICES: we don't like this much except update capsule (get/set variable done through update capsule - we are targeting industrial systems, not developer desktops)
EFI_LOADED_IMAGE_PROTOCOL: needed for SecureBoot
EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL: OK
EFI_DEVICE_PATH_PROTOCOL : OK
EFI_DECOMPRESS_PROTOCOL: we measured that load performance is quite influenced by flash read perf. decompressing may be a solution for low atency boot if cpu ok.
EFI_DEVICE_PATH_UTILITIES_PROTOCOL: OK

Additional information:

EFI_LOAD_FILE2_PROTOCOL: needed for initrd signature check. for direct secure boot flow without shim+grub.

EFI_RNG_PROTOCOL: needed for KASLR

EFI_BOOT_SERVICES.SetWatchdogTimer(): needed for proper A/B partition handling. parameters need to be adjusted to low entry 250Mhz CPUs. more explicit details needed for consistent implementation

2. Secure boot and/or capsule update are not necessary or the right system design for all the cases. To support them, the UEFI secure variable runtime services are needed. How do you deal with the complexity introduced? What’s your experience dealing such with u-boot/xen upstream community?

An Arm "Secure Partition" code in TrustZone was used to host StandaloneMM in EDK2. We imported the SP for use in U-Boot (no EDK2 code) and have been upstreaming our work. A number of things are already merged in U-Boot. We had to ensure the SP can coexist with OPTEE. So we upstreamed support for that in both TF-A and OPTEE. Should you want to support SecureBoot in LinuxBoot the work can easily be imported I think.

The key question is "why the hell would you like UEFI SecureBoot instead of proprietary way to securely boot?". The answer lies in the supply chain and aggregation at product level of multiple signature schemes with multiple tools. I think all the auto makers are like Bosch who created an automotive OTA SIG in the context of IIC: they want the pain to be removed. UEFI SecureBoot is a key pain reliever for those guys and many industrial product builders. A telecom vendor made it clear in an IIC meeting: this is not sustainable.

SIgning tool is now somewhat standalone in EDK2 repo but we think we need to propose a more independent organization to EDK2 community.

 

Thanks,

Jonathan

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

[Ron Minnich]

Francois, I find this very interesting!

[Francois Ozog]

Le mer. 11 mars 2020 à 00:02, Jonathan Zhang (Infra) <jonz...@fb.com> a écrit :

 

 

From: Francois Ozog <franco...@linaro.org>
Date: Tuesday, March 10, 2020 at 10:26 AM
To: "Jonathan Zhang (Infra)" <jonz...@fb.com>
Cc: Ron Minnich <rmin...@google.com>, Chris Koch <chr...@google.com>, linuxboot <linu...@googlegroups.com>, Jonathan Zhang <jon.zhixi...@gmail.com>, Gan Shun Lim <gan...@google.com>, Ryan O'Leary <ryano...@google.com>
Subject: Re: Friday 13th agenda

 

 

 

On Tue, 10 Mar 2020 at 16:58, Jonathan Zhang (Infra) <jonz...@fb.com> wrote:

Hi Francois, I would like to hear more, in particular:

a.    UEFI as a spec, defines mandatory interfaces and optional interfaces (such as secure boot and capsule update). The mandatory interface is rightly about firmware/OS interface, and is described in UEFI spec 2.8 section 2.6 table 13. That being said, table 13 asks for too much. Chris and team experimented booting windows from Linux, and found what’s really needed by windows is a small subset of table 13. What’s your take on table 13? How much is implemented in u-boot (and xen) for table 13?

EBBR is based on 2.7. The subset is still in discussion.  Let's say we are pragmatic people that want minimal constraints with maximal benefit for OS providers. Our reference target workloads for booting are Linux and Android. VB provides a nice standard for booting Android. We just need a Linux equivalent.

Table 13:

EFI_SYSTEM_TABLE:  OK
EFI_BOOT_SERVICES: <selected set>
EFI_RUNTIME_SERVICES: we don't like this much except update capsule (get/set variable done through update capsule - we are targeting industrial systems, not developer desktops)
EFI_LOADED_IMAGE_PROTOCOL: needed for SecureBoot
EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL: OK
EFI_DEVICE_PATH_PROTOCOL : OK
EFI_DECOMPRESS_PROTOCOL: we measured that load performance is quite influenced by flash read perf. decompressing may be a solution for low atency boot if cpu ok.
EFI_DEVICE_PATH_UTILITIES_PROTOCOL: OK

 

Additional information:

EFI_LOAD_FILE2_PROTOCOL: needed for initrd signature check. for direct secure boot flow without shim+grub.

EFI_RNG_PROTOCOL: needed for KASLR

EFI_BOOT_SERVICES.SetWatchdogTimer(): needed for proper A/B partition handling. parameters need to be adjusted to low entry 250Mhz CPUs. more explicit details needed for consistent implementation

Sounds like we both agree that table 13 asks for too much, and it does not align with the expectations from OS and hypervisor. There are some protocols needed for secure boot and capsule update. But since secure boot and capsule update themselves are optional, those protocols should be optional as well.

By the way, what is VB (verified boot?)?

Yes. Sorry....

Also do you need to do any Linux kernel work to make this working? Eg. have you discovered any gap in Linux (UEFI subsystem)?

we did found that initrd kernel command line parameter in efi stub was not consistent across architectures. We upstreamed patches for uboot and kernel (5.7 merge is the target I think). edk2 changes are pending.

a.        

b.   Secure boot and/or capsule update are not necessary or the right system design for all the cases. To support them, the UEFI secure variable runtime services are needed. How do you deal with the complexity introduced? What’s your experience dealing such with u-boot/xen upstream community?

An Arm "Secure Partition" code in TrustZone was used to host StandaloneMM in EDK2. We imported the SP for use in U-Boot (no EDK2 code) and have been upstreaming our work. A number of things are already merged in U-Boot. We had to ensure the SP can coexist with OPTEE. So we upstreamed support for that in both TF-A and OPTEE. Should you want to support SecureBoot in LinuxBoot the work can easily be imported I think.

The key question is "why the hell would you like UEFI SecureBoot instead of proprietary way to securely boot?". The answer lies in the supply chain and aggregation at product level of multiple signature schemes with multiple tools. I think all the auto makers are like Bosch who created an automotive OTA SIG in the context of IIC: they want the pain to be removed. UEFI SecureBoot is a key pain reliever for those guys and many industrial product builders. A telecom vendor made it clear in an IIC meeting: this is not sustainable.

SIgning tool is now somewhat standalone in EDK2 repo but we think we need to propose a more independent organization to EDK2 community.

Got it. Those industries are aligning behind UEFI secure boot. OCP security project, however, has not asked for UEFI secure boot.

do you have an idea why? There is also the signing authority issue... we can’t rely on a pre-defined USA controlled authority: General Electric and Siemens respective cloud infrastructure can host the required PKI for their customers (I mean both PKIaaS or Bosch/GE PKI).

a.        

Error! Filename not specified.

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

 

 

--

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