Bug 1997888

Here's the ticket for this in the Fedora Cloud WG tracker: https://pagure.io/cloud-sig/issue/345

Based on my chat with virt developers, using UEFI + CSM[*] as the default in OSP (and perhaps other layered products) is very unlikely (i.e not be possible) — as OVMF doesn't enable CSM, and it's not in a good shape (i.e. a maintenance burden).

That said, CSM for VMs is not as important as it is for physical machines — for VMs you can "swap" the firmware relatively easily.

(Also, for those OSes that cannot boot with UEFI, there is SeaBIOS.)

[*] "The Compatibility Support Module (CSM) is a component of the UEFI firmware that provides legacy BIOS compatibility by emulating a BIOS environment, allowing legacy operating systems and some option ROMs that do not support UEFI to still be used."

(In reply to Kashyap Chamarthy from comment #2)
> Based on my chat with virt developers, using UEFI + CSM[*] as the default in
> OSP (and perhaps other layered products) is very unlikely (i.e not be
> possible) — as OVMF doesn't enable CSM, and it's not in a good shape (i.e. a
> maintenance burden).
> 

My understanding is that OVMF can be built with CoreBoot+SeaBIOS for CSM support. And as far as I know, this is required to boot Windows Server < 2012 in UEFI mode, as well as several other alternative OSes with UEFI.

> That said, CSM for VMs is not as important as it is for physical machines —
> for VMs you can "swap" the firmware relatively easily.
> 

This is *not* easy, mostly because pretty much everything built on libvirt doesn't offer a way to switch without blowing away the whole VM and starting over. This is especially problematic if VMs are provisioned the "traditional way" (with install media). As far as I know, OpenStack doesn't even expose the knob. 

> (Also, for those OSes that cannot boot with UEFI, there is SeaBIOS.)
> 
> [*] "The Compatibility Support Module (CSM) is a component of the UEFI
> firmware that provides legacy BIOS compatibility by emulating a BIOS
> environment, allowing legacy operating systems and some option ROMs that do
> not support UEFI to still be used."

The idea is that users shouldn't have to think about this. Things should *just work* without effort, preferring UEFI automatically and permitting the same kind of seamless compatibility that hardware platforms have.

(In reply to Neal Gompa from comment #3)
> (In reply to Kashyap Chamarthy from comment #2)
> > Based on my chat with virt developers, using UEFI + CSM[*] as the default in
> > OSP (and perhaps other layered products) is very unlikely (i.e not be
> > possible) — as OVMF doesn't enable CSM, and it's not in a good shape (i.e. a
> > maintenance burden).
> > 
> 
> My understanding is that OVMF can be built with CoreBoot+SeaBIOS for CSM
> support. And as far as I know, this is required to boot Windows Server <
> 2012 in UEFI mode, as well as several other alternative OSes with UEFI.

@Gerd: Do you have any comments here?  I don't know enough about OVMF
internals to be able to tell whether what the above comment from Neal
is asking w.r.t CSM and OVMF is actually viable.

And any other comments on this whole proposal of making guests UEFI
by default are also welcome.

[...]

(In reply to Neal Gompa from comment #3)
> (In reply to Kashyap Chamarthy from comment #2)
> > Based on my chat with virt developers, using UEFI + CSM[*] as the default in
> > OSP (and perhaps other layered products) is very unlikely (i.e not be
> > possible) — as OVMF doesn't enable CSM, and it's not in a good shape (i.e. a
> > maintenance burden).
> 
> My understanding is that OVMF can be built with CoreBoot+SeaBIOS for CSM
> support. And as far as I know, this is required to boot Windows Server <
> 2012 in UEFI mode, as well as several other alternative OSes with UEFI.

I'm not too familiar with RHOSP, but according to

https://access.redhat.com/articles/973163

Windows Server 2012 is the oldest version that's supported as a guest
OS on RHEL 8 based versions, so this shouldn't be a concern.

Either way, I would be surprised if a UEFI-capable OS would require
CSM support to be present in order to boot in UEFI mode. Do you have
any pointers to documentation for this behavior?

> > That said, CSM for VMs is not as important as it is for physical machines —
> > for VMs you can "swap" the firmware relatively easily.
> 
> This is *not* easy, mostly because pretty much everything built on libvirt
> doesn't offer a way to switch without blowing away the whole VM and starting
> over. This is especially problematic if VMs are provisioned the "traditional
> way" (with install media). As far as I know, OpenStack doesn't even expose
> the knob. 

This is not specific to libvirt, or virtualization: even on physical
machines, whether UEFI or BIOS is used for booting is a decision that
you're likely going to make once, at install time, and not revisit
afterwards.

Converting an existing OS installation from BIOS to UEFI is
error-prone and brings very little benefit. So if you have an
existing VM which uses SeaBIOS, you can keep using SeaBIOS; if you're
installing a new VM and your OS is UEFI-capable, you can use EDKII
without any need for CSM support to be enabled. If you're installing
a new VM and the OS is *not* UEFI-capable, you can just use SeaBIOS
instead of EDKII with CSM.

> > (Also, for those OSes that cannot boot with UEFI, there is SeaBIOS.)
> > 
> > [*] "The Compatibility Support Module (CSM) is a component of the UEFI
> > firmware that provides legacy BIOS compatibility by emulating a BIOS
> > environment, allowing legacy operating systems and some option ROMs that do
> > not support UEFI to still be used."
> 
> The idea is that users shouldn't have to think about this. Things should
> *just work* without effort, preferring UEFI automatically and permitting the
> same kind of seamless compatibility that hardware platforms have.

This can be achieved with the help of libosinfo: AFAIK, osinfo-db
records both whether each OS supports the q35 machine type and
whether it supports UEFI boot, so the management application can
simply query that information and choose between EDKII or SeaBIOS
based on it.

If for whatever reason the information is not actually available
through libosinfo, then the solution is to add it, not to enable CSM
support in EDKII :)

> > My understanding is that OVMF can be built with CoreBoot+SeaBIOS for CSM
> > support.

Yes, SeaBIOS can be built as CSM for OVMF (no coreboot needed here).

No, it is still not going to happen.

First it got hacked together a while back, but is not really supported and
maintained upstream.  It never saw serious QE with all those possible corner
cases tested out.  It'll add new concepts which we don't have right now, for
example when it comes to boot ordering.  With ovmf+csm "boot from cdrom" isn't
one option any more, it is actually two: "boot from cdrom in uefi mode" and
"boot from cdrom in bios mode" and we can't express that anywhere in the virt
stack.  Opening that can of worms is asking for a support nightmare.

Second CSM is incompatible with some UEFI features, with secure boot being
the most prominent for example.

Third Intel is working on sunsetting CSM support, so introducing that now
doesn't look like a good plan.

> Either way, I would be surprised if a UEFI-capable OS would require
> CSM support to be present in order to boot in UEFI mode. Do you have
> any pointers to documentation for this behavior?

Older windows versions expect a vgabios being present even when booting
in uefi mode.  Go google for "vbeshim" if you really want know the ugly
details (I'd suggest you don't).  It is the only case I'm aware of though.

> This is not specific to libvirt, or virtualization: even on physical
> machines, whether UEFI or BIOS is used for booting is a decision that
> you're likely going to make once, at install time, and not revisit
> afterwards.

Well, with cloud images which are designed to boot in both UEFI and
BIOS mode this wouldn't be much of a problem.  But these images don't
need a CSM in the first place.

> Converting an existing OS installation from BIOS to UEFI is
> error-prone and brings very little benefit.

Well, also possible, but only if you care about that at install time.
Basically use the same idea hybrid cloud images are using for traditional
interactive anaconda installs.

But, yes, typically it would be a PITA with no real benefit.

> > The idea is that users shouldn't have to think about this. Things should
> > *just work* without effort, preferring UEFI automatically and permitting the
> > same kind of seamless compatibility that hardware platforms have.

You'll see less and less hardware platforms with CSM support.
Windows 11 hardware requirements (uefi with secure boot enabled
by default, which implies CSM disabled by default or not present)
will only accelerate that process.  Yes, it'll most likely not be
a real hard requirement, only a "windows 11 logo" requirement,
but that'll be enough to make hardware OEMs shift.

> This can be achieved with the help of libosinfo: AFAIK, osinfo-db
> records both whether each OS supports the q35 machine type and
> whether it supports UEFI boot, so the management application can
> simply query that information and choose between EDKII or SeaBIOS
> based on it.

I think you'll have a hard time to find an supported OS (as in: still
gets security updates) which does not support UEFI.  With the exception
to the rule being cloud images.  Not sure osinfo-db tracks cloud image
information separately.

Gerd, and Andrea: Thanks for the detailed inputs.


Notes from the Nova bug triage call:
  - We can't yet make UEFI (OVMF) the default in Nova — it requires 
    making Q35 the default upstream: this is not the case yet.  (Note,
    though: downstream, OSP-17 _does_ default to Q35.)

  - Also, even if we go the route of making UEFI the default for VM
    images, this should not be done in Nova.

    Instead, it's recommended (thanks, Sean Mooney) to do this in Glance
    as an import plugin — which inspects the guest image and detect
    whether it supports UEFI, and set the Glance image metadata property
    (`hw_firmware_type=uefi`) accordingly.
  
  - And not least of all; an admin who wants to make sure, they always
    have the option of uploading only those template images into Glance
    that can support UEFI.  And as Gerd notes in comment#6, it's rare to
    find any OS that still gets security updates but does not yet 
    support UEFI.

>   - We can't yet make UEFI (OVMF) the default in Nova — it requires 
>     making Q35 the default upstream: this is not the case yet.  (Note,
>     though: downstream, OSP-17 _does_ default to Q35.)

Note that upstream ovmf supports the pc machine type too, although not
all features are supported then (most significant: secure boot).

Fedora ships two ovmf binaries, one with secure boot support and one
without secure boot support.  The latter works with the pc machine type
too.

For RHEL we've decided to ship only one ovmf binary to keep the test
and support matrix small.  This is where the (downstream) dependency
on q35 comes from.

(In reply to Kashyap Chamarthy from comment #7)

>     Instead, it's recommended (thanks, Sean Mooney) to do this in Glance
>     as an import plugin — which inspects the guest image and detect
>     whether it supports UEFI, and set the Glance image metadata property
>     (`hw_firmware_type=uefi`) accordingly.
>   


@Greg: Do you think this is something we want to do in OSPxx?

(In reply to Gerd Hoffmann from comment #8)
> >   - We can't yet make UEFI (OVMF) the default in Nova — it requires 
> >     making Q35 the default upstream: this is not the case yet.  (Note,
> >     though: downstream, OSP-17 _does_ default to Q35.)
> 
> Note that upstream ovmf supports the pc machine type too, although not
> all features are supported then (most significant: secure boot).
> 
> Fedora ships two ovmf binaries, one with secure boot support and one
> without secure boot support.  The latter works with the pc machine type
> too.

Yeah; good point.  I recall packaging the firmware descriptor files for 
Fedora[1].  The 60-edk2-ovmf-ia32.json file contains the OVMF binary that 
supports both machine types

    [...]
    "targets": [
        {
            "architecture": "i386",
            "machines": [
                "pc-i440fx-*",
                "pc-q35-*"
            ]
        }
    [...]

[1] https://src.fedoraproject.org/rpms/edk2/c/674b3c8a27a8

> For RHEL we've decided to ship only one ovmf binary to keep the test
> and support matrix small.  This is where the (downstream) dependency
> on q35 comes from.

Indeed; I was speaking about the downstream-only restriction.  Thanks
for the clarification.