Laszlo,
can you explain the problems with putting GPL code in the fdf?
afaik every efi file is like a small self-contained application and
shouldn't the UEFI API's be excluded from derived work like the linux
kernel's system call table?
Thanks
Michael
On Wed, Nov 23, 2016 at 8:50 PM, Laszlo Ersek <ler...@redhat.com> wrote:
> 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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
