SeaBIOS as EFI application

[Thorsten Glaser]

Hi,

with a signed shim by mjg59, it’s now possible to forcibly run unsigned EFI
applications on all EFI x86 systems. Even without it, on non-RestrictedBoot
platforms, unsigned EFI applications can be run. The question is…

… whether someone is working on having a SeaBIOS variant that itself
is an EFI application, so that things like MS-DOS and MirBSD can be
booted on an EFI computer (other than Macintosh, I’ve yet to see one,
but that can probably change)?

Pretty please ;-)

Thanks in advance,
//mirabilos (please Cc me, not on the list)

[Peter Stuge]

Thorsten Glaser wrote:
> … whether someone is working on having a SeaBIOS variant that itself
> is an EFI application, so that things like MS-DOS and MirBSD can be
> booted on an EFI computer (other than Macintosh, I’ve yet to see one,
> but that can probably change)?

Thanks for voluntering to do it. ;)

Key word (well, acronym): CSM

//Peter

[Thorsten Glaser]

Peter Stuge <peter <at> stuge.se> writes:
> Thanks for voluntering to do it. ;)

I’m writing bootloaders for BIOS, not for EFI¹.
Which is why I’m asking in the first place ☺

But I might spring a few Euros for it. Probably
not as much as the developer time would be worth
it since I’ve got no company backing, but maybe
that can sweeten the deal.
> Key word (well, acronym): CSM

That one’s not in my² list… which one?

① In fact, I’m mostly clueless about EFI and
  don’t regret that fact.

② https://www.mirbsd.org/wtf.htm

bye,
//mirabilos

[Peter Stuge]

Thorsten Glaser wrote:
> > Thanks for voluntering to do it. ;)
>
> I’m writing bootloaders for BIOS, not for EFI¹.
> Which is why I’m asking in the first place

Noone else is working on it. Significant contributions to SeaBIOS
come from the virtualization community, where EFI is not very
pervasive.
> > Key word (well, acronym): CSM
>
> That one’s not in my² list… which one?

http://www.google.com/search?q=efi+csm

first hit

http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

mentions "In 2008, more x86-64 systems have adopted UEFI. While many
of these systems still allow booting only the BIOS-based OSes via the
Compatibility Support Module (CSM) (thus does not appear to the user
that the system is UEFI-based)"

//Peter

[Thorsten Glaser]

Peter Stuge <peter <at> stuge.se> writes:
> mentions "In 2008, more x86-64 systems have adopted UEFI. While many
> of these systems still allow booting only the BIOS-based OSes via the
> Compatibility Support Module (CSM) (thus does not appear to the user
> that the system is UEFI-based)"

Ah okay. But what if the firmware doesn’t contain it, or it’s broken,
or disables it when Restricted Boot is enabled?

For that case, I’d prefer a somewhat same BIOS implementation (and
from talking with some people at several events and trying it, I
know SeaBIOS probably is one, for as much as you can use the words
sane and BIOS in the same sentence) on top of regular EFI, which can
then be loaded by the firmware or, if in Restricted Boot mode, by
OpenSuSE’s signed version of shim in its Physical Access Override
mode. And then, I can ship these two files with MirBSD.

bye,
//mirabilos

[Gerd Hoffmann]

On 11/07/12 15:15, Peter Stuge wrote:
> Thorsten Glaser wrote:
> > > Thanks for voluntering to do it. ;)
> >
> > I’m writing bootloaders for BIOS, not for EFI¹.
> > Which is why I’m asking in the first place
>
> Noone else is working on it. Significant contributions to SeaBIOS
> come from the virtualization community, where EFI is not very
> pervasive.

Well, efi support _is_ a hot topic in the virtualization community too.

But on a virtual machine it is dead simple to switch the firmware, so we
can load either seabios or ovmf[1] as needed.  There is little need to
stack seabios as csm onto ovmf to build a single firmware image which
then can handle both efi and bios guests.

cheers,
  Gerd

[1] http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF

[Paolo Bonzini]

Il 08/11/2012 22:17, Gerd Hoffmann ha scritto:
> On 11/07/12 15:15, Peter Stuge wrote:
> > Thorsten Glaser wrote:
> > > > Thanks for voluntering to do it. ;)
> > >
> > > I’m writing bootloaders for BIOS, not for EFI¹.
> > > Which is why I’m asking in the first place
> >
> > Noone else is working on it. Significant contributions to SeaBIOS
> > come from the virtualization community, where EFI is not very
> > pervasive.
>
> Well, efi support _is_ a hot topic in the virtualization community too.

See http://www.linux-kvm.org/page/OVMF too.

Paolo

[Thorsten Glaser]

Paolo Bonzini <pbonzini <at> redhat.com> writes:
> See http://www.linux-kvm.org/page/OVMF too.

“The UEFI applications before the last layer correctly use the OVMF GOP 
(graphics output protocol), which drives the emulated Cirrus 5446 video card. 
Unfortunately, the last layer (WinPE) has a hard dependency on VGA BIOS 
interrupt 0x10, which is not provided by any OVMF CSM (compatibility support 
module) as of now.”

This (in the “Windows Server 2008 R2 SP1” section) is another reason why 
people need a SeaBIOS for EFI ;-)

bye,
//mirabilos

[Paolo Bonzini]

Il 09/11/2012 12:01, Thorsten Glaser ha scritto:
> Paolo Bonzini <pbonzini <at> redhat.com> writes:
> > See http://www.linux-kvm.org/page/OVMF too.
>
> “The UEFI applications before the last layer correctly use the OVMF GOP 
> (graphics output protocol), which drives the emulated Cirrus 5446 video card. 
> Unfortunately, the last layer (WinPE) has a hard dependency on VGA BIOS 
> interrupt 0x10, which is not provided by any OVMF CSM (compatibility support 
> module) as of now.”
>
> This (in the “Windows Server 2008 R2 SP1” section) is another reason why 
> people need a SeaBIOS for EFI ;-)

You really only need to run the POST routine of the VGA option ROM.
Problem is simply that as things stand, UEFI only does that if you have
a CSM like SeaBIOS could be.

Paolo

[Kenneth J. Davis]

On Nov 7, 2012 8:50 AM, "Thorsten Glaser"  wrote:
> Hi,
>
> with a signed shim by mjg59, it’s now possible to forcibly run unsigned

EFI
> applications on all EFI x86 systems. Even without it, on

non-RestrictedBoot
> platforms, unsigned EFI applications can be run. The question is…
>
> … whether someone is working on having a SeaBIOS variant that itself
> is an EFI application, so that things like MS-DOS and MirBSD can be
> booted on an EFI computer (other than Macintosh, I’ve yet to see one,
> but that can probably change)?
>
> Pretty please ;-)
>
> Thanks in advance,
> //mirabilos (please Cc me, not on the list)
> --

I am not currently working on it, but have began learning about the SeaBIOS
and the shim loader to support booting FreeDOS and running many DOS
applications.   I would like to assist anyone who is working on an open
source (i.e. SeaBIOS based) BIOS compatibility layer to load on a UEFI
system lacking such support.   Or if such project already exists please
direct me to it.

Thank you,
Kenneth J Davis

[Kevin O'Connor]

On Wed, Nov 07, 2012 at 01:36:59PM +0000, Thorsten Glaser wrote:
> Hi,
>
> with a signed shim by mjg59, it’s now possible to forcibly run unsigned EFI
> applications on all EFI x86 systems. Even without it, on non-RestrictedBoot
> platforms, unsigned EFI applications can be run. The question is…
>
> … whether someone is working on having a SeaBIOS variant that itself
> is an EFI application, so that things like MS-DOS and MirBSD can be
> booted on an EFI computer (other than Macintosh, I’ve yet to see one,
> but that can probably change)?

This has come up a few times before.  I've briefly looked at sizing
what it would take a couple of times in the past.

Unfortunately, the UEFI spec is amazingly complicated.  Really really
complicated.  It makes the ACPI spec seem simple.  So, when I looked
at it I came away with the impression that any type of implementation
would become a mind-numbing slog.

There were a couple of angles I looked at.

1 - Using SeaBIOS as a CSM.  The CSM spec is amazingly complex as
well.  Instead of just defining how to jump between EFI and legacy
mode, the spec details dozens of calls where any given real-world
action would require multiple complex handoffs.  Worse - I don't see
the spec detailing how legacy hardware drivers should work.  As near
as I can tell, the system would need separate disk drivers (eg, IDE,
AHCI, USB MSC, etc.) in both legacy and efi mode.  How this is
supposed to work in practice is a mystery to me.  (Imagine the
complexity of initializing the efi usb drivers, detecting a USB drive
using the efi usb drivers, determining it requires a legacy boot,
initiating the CSM, which then must initialize its own usb driver,
find the drive again, etc.)

2 - Implementing in SeaBIOS a subset of the EFI OS interface so that
SeaBIOS could boot common EFI OSes.  Unfortunately, the EFI spec is
really really complex.  For example, it includes a dynamic runtime
linker, its own interpretive language, runtime paging support, dozens
of hardware protocols, multiple intermediate interface layers, etc.
It's not clear to me how much of this a real-world OS would use, so
this may still be a viable path.  However, even trying to unravel the
EFI spec to determine what parts are linked is a mind-numbing
experience - the spec is 2200 pages!

To be clear though, neither of the above paths would enable you to
boot something like DOS on an existing UEFI system.  It may be
possible to put a wrapper around SeaBIOS so that the shim you
mentioned could deploy SeaBIOS into memory and have it attempt its
init and boot phases.  It may work, but it may be too fragile - things
like shadow ram control and the complexity of double initializing the
vga option rom could be problematic.

-Kevin

[Thorsten Glaser]

Kevin O'Connor dixit:
> Unfortunately, the UEFI spec is amazingly complicated.  Really really
> complicated.  It makes the ACPI spec seem simple.  So, when I looked

OUCH!
> 1 - Using SeaBIOS as a CSM.  The CSM spec is amazingly complex as
> 2 - Implementing in SeaBIOS a subset of the EFI OS interface so that

Both aren’t really what I want.
> To be clear though, neither of the above paths would enable you to
> boot something like DOS on an existing UEFI system.  It may be

Yeah. I was more thinking of having SeaBIOS be an EFI “OS”,
just like the MirBSD bootloader is a Multiboot compliant “OS
kernel”, and then take over the system and load the real OS,
providing BIOS calls to it.

bye,
//mirabilos

[Jordan Justen]

On Sat, Nov 10, 2012 at 8:25 AM, Thorsten Glaser  wrote:
> Kevin O'Connor dixit:
> > 1 - Using SeaBIOS as a CSM.  The CSM spec is amazingly complex as
> > 2 - Implementing in SeaBIOS a subset of the EFI OS interface so that
>
> Both aren’t really what I want.

It sounds like you definitely don't want 2, but you do want something
similar to 1. In a UEFI+CSM system, the CSM essentially provides the
environment that legacy BIOS based software can use.
> > To be clear though, neither of the above paths would enable you to
> > boot something like DOS on an existing UEFI system.  It may be
>
> Yeah. I was more thinking of having SeaBIOS be an EFI “OS”,
> just like the MirBSD bootloader is a Multiboot compliant “OS
> kernel”, and then take over the system and load the real OS,
> providing BIOS calls to it.

How do you generically deal with chipset memory protection in
0xc0000-0x100000? (Ie, shadow ram that Kevin mentioned.)

You may find that you need a 'chipset driver' to allow you to write
these regions. UEFI has the LegacyRegion protocol for this for CSM
systems, for example. But, in a non-CSM UEFI system, there is no need
for the LegacyRegion protocol.

It could be that in a post-CSM UEFI world that these regions will
generally just be set to RAM mode, but I wouldn't bet on it. It
certainly seems unlikely that you could rely on this for all UEFI
systems.

In OVMF we currently leave those regions in ROM mode.

-Jordan