[SeaBIOS] SeaBIOS as EFI application

[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