On 11/23/16 21:01, Michael Zimmermann wrote:
> Laszlo,
>
> can you explain the problems with putting GPL code in the fdf?
No. I'm not a lawyer. I just repeated what I heard / read elsewhere, and
provided a link. Personally I wouldn't try distributing such
combinations, just to be on the safe side. For work, I would contact RH
Legal if I wanted to to this, and follow their instructions.
> 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?
No clue. :)
Thanks
Laszlo
> 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
