From owner-svn-doc-all@freebsd.org Fri Jul 1 14:29:09 2016
Return-Path:
The &os; 11.0-RELEASE cycle started late May, one month
- behind the orignal schedule. The schedule slip was primarily
+ behind the original schedule. The schedule slip was primarily
to accommodate for packaging the &os; base system with the
pkg(8) utility. However, as work on this progressed,
it became apparent that there were too many outstanding
@@ -326,4 +326,129 @@
report issues.
+
+ The EFI bootloader has undergone considerable refactoring to
+ make more use of the EFI API. The filesystem code in
+ boot1 has been eliminated, and a single codebase for
+ filesystems now serves both boot1 and
+ loader. This codebase is organized around the EFI
+ driver model and it should be possible to export any
+ filesystem implementation as a standalone EFI driver without
+ too much effort. Both boot1 and loader have been refactored
+ to talk through the EFI_SIMPLE_FILE_SYSTEM interface.
+ In loader, this is accomplished with a dummy
+ filesystem driver that is just a translation layer between the
+ loader filesystem interface and
+ EFI_SIMPLE_FILE_SYSTEM. A reverse translation layer
+ allows the existing filesystem drivers to function as EFI
+ drivers. The EFI refactoring by itself exists in
+ this branch. Additionally, GELI support has been added using the EFI
+ refactoring. This allows booting from a GELI-encrypted
+ filesystem. Note that the EFI system partition, which
+ contains boot1, must be a plaintext msdosfs
+ partition. This patch adds an intake buffer to the crypto
+ framework, which allows injection of keys directly into a
+ loaded kernel, without the need to pass them through
+ arguments or environment variables. This patch only uses the
+ intake buffer for EFI GELI support as legacy BIOS GELI support
+ still uses environment variables. EFI GELI support depends on the
+ efize branch. These patches have been tested and used and should be able
+ to handle use by early adopters. Note that the
+ LOADER_PATH variable has been changed to
+ /boot/loader.tst, to facilitate safe testing. As this is an encrypted filesystem patch, an error can
+ potentially leave data inaccessible. It is
+ strongly recommended to use the following procedure
+ for testing: Back up your data! Do not forget to back up your data! Install an EFI shell on the ESP. Install the patched boot1 on the ESP to
+ something like /boot/efi/BOOTX64.TST. Install the patched loader to /boot/loader.tst
+ on your machine. Create a GELI partition outside of the normal boot
+ partition. First, try booting /boot/efi/BOOTX64.TST and
+ make sure it properly handles the encrypted partition. Copy a boot environment, including the patched loader, to
+ the encrypted partition. Use the loader prompt to load a kernel from the encrypted
+ partition. Try switching over to an encrypted main partition once
+ everything else has worked.
+
+
+
+