Linuxboot feature readiness review

[Jonathan Zhang]

Hi Colleagues,

Kudos to this community! Great progress has been made to make Linuxboot feature 

rich (here Linuxboot is a broader term including coreboot, Linuxboot, heads/systemboot, 

NERF etc.). I propose us doing a production readiness review to reach consensus.

Following is an attempt for your feedback (is the list complete? Is the assessment 

accurate?):

* Hardware error detection/handling, power management. Needed by hyperscaler 

deployment. The heavy lifting of RAS and power management features are done by 

SMM. We need to have alternatives to get away from SMM completely.

One way is to move such logic to kernel. On the other hand, PRM is one of Intel 

proposed methods to replace SMM [1].

* TPM, measured boot. Needed by hyperscaler deployment. Work is on-going. We 

need enough measurements in all components of the Linuxboot stack.

* BMC coordination. Needed by hyperscaler deployment. Needs to report boot status 

and do other needed handshaking with BMC. Since different hypderscalers use different 

BMC FW (such as openBMC vs. uBMC) and different communication methods (such as 

IPMI, SEL, redfish), host FW side needs to be inclusive and configurable. 

* OptionRom. Needed by industry adoption. PCIe card vendors provide their device 

firmware through OptionRom. Linuxboot invokes it in user space. Is it feature complete?

* Host FW upgrade. Needed by industry adoption. UEFI enables host firmware upgrade 

at OS runtime through UEFI capsule update which is a runtime service. Hyperscaler does

host FW upgrade through BMC only. For general user community, probably it is okay 

to do in-band host firmware upgrade through kernel.

* Secure boot. Needed by industry adoption. Can coreboot securely load payloads? 

Can Linuxboot be set up to boot OS by calling kexec_file_load()? Also need support 

for secure boot related provisioning, manufacturing process.  UEFI answers such needs 

with secure variable mgmt., and various modes (such as setup mode, audit mode).

What is our design? What's the difference from user's perspective?

* Configuration mgmt. Needed by industry adoption. Boot configurations need to be 

managed in both boot time and runtime. The variable storage needs to be fault tolerant. 

User may not want variable storage to be updated during host firmware upgrade process.

* CMD line interface. Needed by Industry adoption. Do we support similar functionalities 

enabled by UEFI shell commands, albeit through Linux shell commands?

* GUI. Needed by industry adoption. Is there a framework to enable GUI, similar like UEFI’s HII

(Human Interface Infrastructure) framework?

[1] https://f990335bdbb4aebc3131-b23f11c2c6da826ceb51b46551bfafdc.ssl.cf2.rackcdn.com/images/18c3956f953ee6d971b06fa813d91ebece2a8fa5.pdf

PS. Thanks for the feedbacks from Ron and FB team.

Thanks,

Jonathan

[ron minnich]

On Tue, Jan 29, 2019 at 8:46 PM Jonathan Zhang
<jon.zhixi...@gmail.com> wrote:

> * Hardware error detection/handling, power management. Needed by hyperscaler
> deployment. The heavy lifting of RAS and power management features are done by
> SMM. We need to have alternatives to get away from SMM completely.
> One way is to move such logic to kernel. On the other hand, PRM is one of Intel
> proposed methods to replace SMM [1].

I strongly agree we need to get away from SMM. PRM is interesting but
I am concerned
about the language.

Key word here being "proposed." I don't think we should rely on this
happening. I hope it does.

>
> * TPM, measured boot. Needed by hyperscaler deployment. Work is on-going. We
> need enough measurements in all components of the Linuxboot stack.

I still believe chromebooks are something we can learn from. But HEADS
has also paved a
nice path we should also study.

>
> * BMC coordination. Needed by hyperscaler deployment. Needs to report boot status
> and do other needed handshaking with BMC. Since different hypderscalers use different
> BMC FW (such as openBMC vs. uBMC) and different communication methods (such as
> IPMI, SEL, redfish), host FW side needs to be inclusive and configurable.

yes.

>
> * OptionRom. Needed by industry adoption. PCIe card vendors provide their device
> firmware through OptionRom. Linuxboot invokes it in user space. Is it feature complete?

It needs to be. Option ROMS are unacceptable in Ring 0.

>
> * Host FW upgrade. Needed by industry adoption. UEFI enables host firmware upgrade
> at OS runtime through UEFI capsule update which is a runtime service. Hyperscaler does
> host FW upgrade through BMC only. For general user community, probably it is okay
> to do in-band host firmware upgrade through kernel.

I agree. Chromebooks show this works.

>
> * Secure boot. Needed by industry adoption. Can coreboot securely load payloads?

secure boot is fine, but the UEFI way of doing it is not fine. We
don't want to go that route.
There are big problems at so many levels with the UEFI approach.

> Can Linuxboot be set up to boot OS by calling kexec_file_load()? Also need support
> for secure boot related provisioning, manufacturing process. UEFI answers such needs
> with secure variable mgmt., and various modes (such as setup mode, audit mode).
> What is our design? What's the difference from user's perspective?

these are good questions.

>
> * Configuration mgmt. Needed by industry adoption. Boot configurations need to be
> managed in both boot time and runtime. The variable storage needs to be fault tolerant.
> User may not want variable storage to be updated during host firmware upgrade process.

yeah.

>
> * CMD line interface. Needed by Industry adoption. Do we support similar functionalities
> enabled by UEFI shell commands, albeit through Linux shell commands?

it's almost impossible to write a shell worse than the UEFI shell, and
I tried. And it runs in Ring 0. And it's written in C.
I think we can convince people they are better off with a Go-based
shell running in Ring 3. I hope so.

>
> * GUI. Needed by industry adoption. Is there a framework to enable GUI, similar like UEFI’s HII
> (Human Interface Infrastructure) framework?

we just be able to do better :-)

good questions.

ron

[Jonathan Zhang]

Thanks Ron for the feedback. Please see inline comments.

On the other hand, I have a suggestion to the community. There are
many myth, misunderstandings
for Linuxboot; I myself certainly was in such situation and still have
many areas to learn from this
community. The cookbook and Documentation are very effective efforts
to promote understanding,
targeting developers.
I suggest us working together to develop similar material for feature
level white paper style contents,
targeting user community. Focusing on a specific feature, such content
would analyze requirements,
list industry trends/approaches, explain coreboot philosophy/design,
current status and future plan, etc.
This will be a community effort, and I will do my best to contribute.

Best Regards,
Jonathan

On Sat, Feb 16, 2019 at 3:35 PM ron minnich <rmin...@gmail.com> wrote:
>
> On Tue, Jan 29, 2019 at 8:46 PM Jonathan Zhang
> <jon.zhixi...@gmail.com> wrote:
>
> > * Hardware error detection/handling, power management. Needed by hyperscaler
> > deployment. The heavy lifting of RAS and power management features are done by
> > SMM. We need to have alternatives to get away from SMM completely.
> > One way is to move such logic to kernel. On the other hand, PRM is one of Intel
> > proposed methods to replace SMM [1].
>
> I strongly agree we need to get away from SMM. PRM is interesting but
> I am concerned
> about the language.
>
> Key word here being "proposed." I don't think we should rely on this
> happening. I hope it does.

In upcoming OCP meeting, there will be a strong Intel technical
representation. Let's
figure out the status and dive into details with Intel (and MSFT).

>
> >
> > * TPM, measured boot. Needed by hyperscaler deployment. Work is on-going. We
> > need enough measurements in all components of the Linuxboot stack.
>
> I still believe chromebooks are something we can learn from. But HEADS
> has also paved a
> nice path we should also study.

Sorry for my ignorance. I need to find out what chromebook and HEADS
do differently,
in terms of measured boot, secure boot.

> >
> > * BMC coordination. Needed by hyperscaler deployment. Needs to report boot status
> > and do other needed handshaking with BMC. Since different hypderscalers use different
> > BMC FW (such as openBMC vs. uBMC) and different communication methods (such as
> > IPMI, SEL, redfish), host FW side needs to be inclusive and configurable.
>
> yes.
>
> >
> > * OptionRom. Needed by industry adoption. PCIe card vendors provide their device
> > firmware through OptionRom. Linuxboot invokes it in user space. Is it feature complete?
>
> It needs to be. Option ROMS are unacceptable in Ring 0.
>
> >
> > * Host FW upgrade. Needed by industry adoption. UEFI enables host firmware upgrade
> > at OS runtime through UEFI capsule update which is a runtime service. Hyperscaler does
> > host FW upgrade through BMC only. For general user community, probably it is okay
> > to do in-band host firmware upgrade through kernel.
>
> I agree. Chromebooks show this works.
>
>
> >
> > * Secure boot. Needed by industry adoption. Can coreboot securely load payloads?
>
> secure boot is fine, but the UEFI way of doing it is not fine. We
> don't want to go that route.
> There are big problems at so many levels with the UEFI approach.

Sorry for my ignorance. I would like to understand what is the
linuxboot approach, and what
are the big problems with the UEFI approach (I have a list in my mind,
but I want to vest
them).

[Ron Minnich]

I like your ideas of white papers, docs, and so on.

The UEFI Secure Boot problems are well documented at this point and I
don't think we need to put any time into that discussion.

Let's just keep pushing on what makes linuxboot a good way to go.

thanks

On Tue, Feb 26, 2019 at 9:46 PM Jonathan Zhang

> --
> You received this message because you are subscribed to the Google Groups "linuxboot" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linuxboot+...@googlegroups.com.
> To post to this group, send email to linu...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/linuxboot/CAHGDa7BB01haThLLJSzUBySt4b52LDLSSwzBZj2P%3DHLzY11n2Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.