From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id AEE5E81E9E for ; Wed, 23 Nov 2016 12:01:19 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id m203so3000147wma.3 for ; Wed, 23 Nov 2016 12:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uPl6HV8SqHiphi0B0Yr+7I8wy1G8pgvbFHKpU+SEPXc=; b=M01cO3theX5MeOKvmfy2sgpvMWlmvwxlKnKqNqqUZ+R+Oj+5HZgRduLGmcN7m0KRck gLwPrvzkrJaJVn0PQd7HiZbzA4V/JdP7D0May2zUcO5ie0Kl6NLfS502q4HFz39RstPS yNjPp6F3KD0GWVjwfq1XoAJV3/WwLEPjDYqPTaVnhwUgkWqS3Ltq8Fiqu9iJN9PoLb6k aNtC/oQMHoddG7vanSQYv6kxQSKBzk/BDoFMpG1GdQY89XNcwDLDu7KWvpKRLuqrrMKj Lc/Qv1Sd5iJGyukZ4MPfkjEN43wybji6H+wHtm8RDbhV/Su95WSI7/plR+O9bm9B/eRC N8CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uPl6HV8SqHiphi0B0Yr+7I8wy1G8pgvbFHKpU+SEPXc=; b=TFwyeZ2t8Ij8aloQPCIdfgNycs6MNDXz3n9Wyr8njj2rEAAj9x89hOIEiz+PyAydNG Up8DseTsqEr2u5/Hn13L3o/23dUzhTD23KliSwQ54ahakjdwndASLMtOckTVpQ1k9yui TzpMbMMvNhM4+3nyqmXf0pnqSlB4zWFoBNWm47SMbWwqScs5vWNqiVZQpy88GY76lDDm aFxIZfGhgT05mf9y3zk14TMT0TaRH8NtA1dST5WKC3GAU6IJaVBE0Ii7kh2XikGxngLP G3KXqxrYyfwvTOEMO0o00RK3IuGY44fRxEvpN6w+AQJrwWzT2FJtiwrGL2ZrZD1BzShh rhtA== X-Gm-Message-State: AKaTC038ebycO2SzjjkxbkAWFj/Fm3gxLjLauDARGGFH29P/YLOmUATpncIeyFRrl15GA8D3odK48zty7fiILA== X-Received: by 10.28.111.70 with SMTP id k67mr8809379wmc.32.1479931278054; Wed, 23 Nov 2016 12:01:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.140.134 with HTTP; Wed, 23 Nov 2016 12:01:17 -0800 (PST) In-Reply-To: References: <2ee033d3-bf24-6710-3f72-14bd0e6dfed9@akeo.ie> <98271ced-83d5-d4e9-6b8d-416265054906@rodsbooks.com> From: Michael Zimmermann Date: Wed, 23 Nov 2016 21:01:17 +0100 Message-ID: To: Laszlo Ersek Cc: Rod Smith , "edk2-devel@lists.01.org" , Marcin Wojtas , Pete Batard , Rebecca Cran Subject: Re: EXT FS support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 20:01:20 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 nee= d >>> to have GRUB running or anything. You can just use the "load" command i= n >>> 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 examp= le, I recommend looking at > > EdkShellBinPkg/FullShell/FullShell.inf > > and the following portions from OvmfPkg/OvmfPkgX64.fdf: > > INF RuleOverride =3D BINARY EdkShellBinPkg/FullShell/FullShell.inf > ... > > [Rule.Common.UEFI_DRIVER.BINARY] > FILE DRIVER =3D $(NAMED_GUID) { > DXE_DEPEX DXE_DEPEX Optional |.depex > PE32 PE32 |.efi > UI STRING=3D"$(MODULE_NAME)" Optional > VERSION STRING=3D"$(INF_VERSION)" Optional BUILD_NUM=3D$(BUILD_NUMB= ER) > } > [Rule.Common.UEFI_APPLICATION.BINARY] > FILE APPLICATION =3D $(NAMED_GUID) { > PE32 PE32 |.efi > UI STRING=3D"$(MODULE_NAME)" Optional > VERSION STRING=3D"$(INF_VERSION)" Optional BUILD_NUM=3D$(BUILD_NUMB= ER) > } > >> >> 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 binar= y that combined edk2's OpenSSL-based Secure Boot stack and GPL drivers migh= t 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-us= er's side, it doesn't require constant fiddling): copy the stand-alone, GPL= -licensed UEFI_DRIVER binary to a small, separate VFAT filesystem, then cre= ate a Driver#### option that points to it. > > (At least with edk2 and OVMF, the driver options are dispatched between B= eforeConsole and AfterConsole, and OVMF's AfterConsole calls EfiBootManager= ConnectAll(). The result is that filesystems recognized by the drivers load= ed from the small VFAT partition would all be bound, and would become avail= able for booting off of.) > > This VFAT + Driver#### setup could even be done by customized OS installe= rs, without user interaction. > > Now I understand that the point might be to eliminate a VFAT partition al= together, but after the initial driver installation, it could become read-o= nly from the OS runtime POV as well, and the real boot loader stuff could r= eside on ext2. > > Separately, a small note on ext4 (because you mention it above). I seem t= o recall a filesystem expert colleague of mine advise *against* using journ= aled filesystems for booting with e.g. grub2. The argument goes (if I recal= l 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 loc= ation, so a boot loader that doesn't know about the journal will read consi= stent data. However, if you crash *without* data loss, then part of the dat= a 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 applicatio= ns (although firmware that supports SysPrep#### would arguably get Driver##= ## right as well). > > Invoking the same logic / app from a regular boot option, and exiting wit= h 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, pla= tform firmware > // supports boot manager menu, and if firmware is configured to boot = in an > // interactive mode, the boot manager will stop processing the BootOr= der 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/VBox= FsDxe/ >> >> 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 U= EFI application. > > Furthermore, arm and arm64 kernels parse the "initrd=3D..." 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 simpl= est (maybe only?) use case is to provide just a filename (no pathname separ= ators) with "initrd=3D", and then the file will be loaded from the same dir= ectory as the kernel, IIRC. > > This enables a development style where one > - sets up one boot option, pointing to the kernel image (with the EFI stu= b) as the binary to launch, > - stores "initrd=3D..." 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 (un= der 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