From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B250E81D36 for ; Mon, 28 Nov 2016 13:15:09 -0800 (PST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP; 28 Nov 2016 13:15:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,565,1473145200"; d="scan'208";a="906464355" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 28 Nov 2016 13:15:08 -0800 Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.12]) by FMSMSX106.amr.corp.intel.com ([169.254.5.166]) with mapi id 14.03.0248.002; Mon, 28 Nov 2016 13:15:08 -0800 From: "Carsey, Jaben" To: Laszlo Ersek , Rod Smith CC: Michael Zimmermann , "edk2-devel@ml01.01.org" , "Carsey, Jaben" Thread-Topic: [edk2] EXT FS support Thread-Index: AQHSRNSx6Xtw9CiB4Uu9kf405IQ5saDltNKAgAAGLgCAAAT8gIAABNcAgAATG4CAADP4gIABdiwAgAdtAQA= Date: Mon, 28 Nov 2016 21:15:07 +0000 Message-ID: References: <2ee033d3-bf24-6710-3f72-14bd0e6dfed9@akeo.ie> <98271ced-83d5-d4e9-6b8d-416265054906@rodsbooks.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDAxNGYzYmMtOWQ0Ny00MzJjLWI0NmQtYzg2ZmJmN2JjZjhlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImZkRjBzNnFqOGtcL3FBWmU2TEJtd01FRUlReXlpNG85Nm4zOUhQZFBkOFQ0PSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.1.200.107] MIME-Version: 1.0 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: Mon, 28 Nov 2016 21:15:09 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Wednesday, November 23, 2016 11:50 AM > To: Rod Smith > Cc: Michael Zimmermann ; edk2- > devel@ml01.01.org > Subject: Re: [edk2] EXT FS support > Importance: High >=20 > 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 ne= ed > >> 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 framewor= k > > (rEFIt's) as rEFInd's drivers, into its own firmware. Thus, Marcin migh= t > > 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. >=20 > Any valid EFI binary can be built into edk2 platforms easily. As an examp= le, I > recommend looking at >=20 > EdkShellBinPkg/FullShell/FullShell.inf I would recommend ShellBinPkg over the EdkShellBinPkg. One is the UEFI She= ll Spec compliant, the other is not. >=20 > and the following portions from OvmfPkg/OvmfPkgX64.fdf: >=20 > INF RuleOverride =3D BINARY EdkShellBinPkg/FullShell/FullShell.inf > ... >=20 > [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_NUMBER) > } > [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_NUMBER) > } >=20 > > > > 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. >=20 > Yes. >=20 > 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 > might be undistributable. (It would be fine for in-house use.) >=20 > https://people.gnome.org/~markmc/openssl-and-the-gpl.html >=20 > 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-li= censed > UEFI_DRIVER binary to a small, separate VFAT filesystem, then create a > Driver#### option that points to it. >=20 > (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 woul= d > become available for booting off of.) >=20 > This VFAT + Driver#### setup could even be done by customized OS > installers, without user interaction. >=20 > Now I understand that the point might be to eliminate a VFAT partition > altogether, but after the initial driver installation, it could become re= ad-only > from the OS runtime POV as well, and the real boot loader stuff could res= ide > on ext2. >=20 > 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 recall r= ight), > XFS is considered to be in clean state if the data has made it to the fin= al > location *or* the persistent journal. When you cleanly unmount (or remoun= t > 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 con= sistent > data. >=20 > > 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. >=20 > Newer firmware might also support SysPrep#### options for such > applications (although firmware that supports SysPrep#### would arguably > get Driver#### right as well). >=20 > 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 >=20 > // > // 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. > // >=20 > I guess invariably exiting with failure could ensure chaining. >=20 > > > > Marcin wrote: > > > >> I also found this: > >> > https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/FileSystems/VBo > xFsDxe/ > > > > 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 wan= t > > 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. >=20 > Yes, if the kernel was built with the EFI stub, it can be launched as a U= EFI > application. >=20 > Furthermore, arm and arm64 kernels parse the "initrd=3D..." command line > parameter in the EFI stub, and can load the initrd from the same filesyst= em > (using the UEFI drivers) where the kernel image was loaded from. The > simplest (maybe only?) use case is to provide just a filename (no pathnam= e > separators) with "initrd=3D", and then the file will be loaded from the s= ame > directory as the kernel, IIRC. >=20 > 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. >=20 > > 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 mayb= e > > this wouldn't work as well for you, but it's worth considering. > > >=20 > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel