Re: EXT FS support

[Laszlo Ersek <lersek@redhat.com>]

On 11/22/16 22:31, Rod Smith wrote:
> On 11/22/2016 01:25 PM, Pete Batard wrote:
>> On 2016.11.22 17:16, Marcin Wojtas wrote:
>>> There's no GRUB, platform simply boots to the Shell.
>>
>> I think there may be some confusion.
>>
>> All the drivers we linked you to are pure UEFI drivers. It doesn't
>> matter if they were a port from GRUB or something else, the code was
>> converted to work as a standalone UEFI driver. Especially you don't need
>> to have GRUB running or anything. You can just use the "load" command in
>> the shell to load the driver, and then access the file system.
>>
>> I believe you should be able to download any of the ext binary drivers
>> mentioned and use them in your shell right away to access your file
>> system from it.
> 
> Yes, but it sounds like Marcin may want to embed the ext4fs driver in a
> custom EFI build. AFAIK, none of the drivers in question were designed
> with that in mind; however, the VirtualBox project has incorporated
> ISO-9660 and HFS+ drivers, both of which are built on the same framework
> (rEFIt's) as rEFInd's drivers, into its own firmware. Thus, Marcin might
> be able to look at the VirtualBox code and use whatever techniques or
> glue it uses to incorporate something else. (I can't point to specific
> files, though.) The rEFInd drivers might be easiest to build in this
> way, but that's just a guess.

Any valid EFI binary can be built into edk2 platforms easily. As an example, I recommend looking at

  EdkShellBinPkg/FullShell/FullShell.inf

and the following portions from OvmfPkg/OvmfPkgX64.fdf:

INF  RuleOverride = BINARY EdkShellBinPkg/FullShell/FullShell.inf
...

[Rule.Common.UEFI_DRIVER.BINARY]
  FILE DRIVER = $(NAMED_GUID) {
    DXE_DEPEX DXE_DEPEX Optional      |.depex
    PE32      PE32                    |.efi
    UI        STRING="$(MODULE_NAME)" Optional
    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
  }
[Rule.Common.UEFI_APPLICATION.BINARY]
  FILE APPLICATION = $(NAMED_GUID) {
    PE32      PE32                    |.efi
    UI        STRING="$(MODULE_NAME)" Optional
    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
  }

> 
> Note, however, that all of the drivers referenced so far in this thread
> are licensed under the GPL. Thus, building an EFI in this way would
> cause the EFI as a whole to be GPL-licensed.

Yes.

Also, as far as I'm aware, OpenSSL and GPL don't mix, so a firmware binary that combined edk2's OpenSSL-based Secure Boot stack and GPL drivers might be undistributable. (It would be fine for in-house use.)

https://people.gnome.org/~markmc/openssl-and-the-gpl.html

There's another option (and while it requires initial setup on the end-user's side, it doesn't require constant fiddling): copy the stand-alone, GPL-licensed UEFI_DRIVER binary to a small, separate VFAT filesystem, then create a Driver#### option that points to it.

(At least with edk2 and OVMF, the driver options are dispatched between BeforeConsole and AfterConsole, and OVMF's AfterConsole calls EfiBootManagerConnectAll(). The result is that filesystems recognized by the drivers loaded from the small VFAT partition would all be bound, and would become available for booting off of.)

This VFAT + Driver#### setup could even be done by customized OS installers, without user interaction.

Now I understand that the point might be to eliminate a VFAT partition altogether, but after the initial driver installation, it could become read-only from the OS runtime POV as well, and the real boot loader stuff could reside on ext2.

Separately, a small note on ext4 (because you mention it above). I seem to recall a filesystem expert colleague of mine advise *against* using journaled filesystems for booting with e.g. grub2. The argument goes (if I recall right), XFS is considered to be in clean state if the data has made it to the final location *or* the persistent journal. When you cleanly unmount (or remount r/o) and shut down, the journal will be flushed to the final location, so a boot loader that doesn't know about the journal will read consistent data. However, if you crash *without* data loss, then part of the data might be in the journal only, and only clients that can read the journal will see consistent data.

> This might or might not be
> an issue, depending on what the point of the exercise is.
> 
> Of course, a standalone driver might be perfectly acceptable, too. I've
> seen options in some EFIs to load drivers at start time, but I've never
> gotten them to work. (I haven't tried very hard.) If nothing else, a
> small driver-loading program could be written and set as the first boot
> option.

Newer firmware might also support SysPrep#### options for such applications (although firmware that supports SysPrep#### would arguably get Driver#### right as well).

Invoking the same logic / app from a regular boot option, and exiting with success, might or might not chain to the next boot option automatically. For example, in "MdeModulePkg/Universal/BdsDxe/BdsEntry.c", edk2 has 

    //
    // If the boot via Boot#### returns with a status of EFI_SUCCESS, platform firmware
    // supports boot manager menu, and if firmware is configured to boot in an
    // interactive mode, the boot manager will stop processing the BootOrder variable and
    // present a boot manager menu to the user.
    //

I guess invariably exiting with failure could ensure chaining.

> 
> Marcin wrote:
> 
>> I also found this:
>> https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/FileSystems/VBoxFsDxe/
> 
> FWIW, that's a fork of the rEFInd code. I'd not seen it before now; the
> Clover developers haven't bothered to upstream their changes. (I
> maintain rEFInd.)
> 
> It's still not clear to me why you want this driver, Marcin. If you want
> to load a Linux kernel directly, without using GRUB, rEFInd, or some
> other tool, you can simply put the kernel(s) on a FAT filesystem.

Yes, if the kernel was built with the EFI stub, it can be launched as a UEFI application.

Furthermore, arm and arm64 kernels parse the "initrd=..." command line parameter in the EFI stub, and can load the initrd from the same filesystem (using the UEFI drivers) where the kernel image was loaded from. The simplest (maybe only?) use case is to provide just a filename (no pathname separators) with "initrd=", and then the file will be loaded from the same directory as the kernel, IIRC.

This enables a development style where one
- sets up one boot option, pointing to the kernel image (with the EFI stub) as the binary to launch,
- stores "initrd=..." in the boot option's LoadOptions field,
- boots the system, modifies and rebuilds the kernel,
- installs the kernel and the initrd in the exact same spot as before (under the same pathnames on the ESP),
- reboots.

> This
> is a common approach among Arch Linux users; they mount the ESP at /boot
> and it works pretty well. Some distributions assume that /boot supports
> links or other features that aren't available with FAT, though, so maybe
> this wouldn't work as well for you, but it's worth considering.
> 

Thanks
Laszlo