---
tags: freebsd, devsummit, 2019, boot, uefi
---

# fail-safe boot code

- [LIVE STREAM](rtmp://bsdcan-vsn.secdn.net/bsdcan-live/play/mp4:DMS1130)
- https://wiki.freebsd.org/DevSummit/201905/FailsafeBootcode

## legacy boot

Agenda items:
- Should we move gptzfsboot from freebsd-boot to inside freebsd-zfs @offset (like the MBR way)
- Can we create a 2nd offset to store a backup gptzfsboot?
- make a version of PMBR (ZFSPMBR) that knows these offsets and can failsafe GPT boot a ZFS pool (based on how the old MBR version works)
- Or do we create two freebsd-boot partitions and teach PMBR about the GPT flags (bootme, bootonce, bootfailed)
- the gptboot protocol for these flags is tricky, and PMBR is likely too small to be able to implement it.
- gpt.o from gptboot is 2830 bytes today, and PMBR total has to be < 468ish bytes.
- How best to make a zpool bootcode command for updating the primary and backup gptzfsboot, or the EFI code if it exists
- estimate we're about ~5 years away from MBR being the minority
- could we get rid of freebsd-boot? YES & NO
- should have just enough smarts to know which bootcode we should use and nextboot flags
- move bootcode into different offsets into zfs label
- could we use parts of nvlist (YES WE CAN)
- secureboot:
- what about storing hashes of EFI data in TPM
- should provide a hook in post-boot to re-seal new config
- TPMs have both monotonic counters & NVRAM, could sign manifests to allow e.g. boot once at this counter, and then never again
- Juniper and Semihalf have committed a bunch support for secure boot in UEFI and maintaining the chain of trust into loader.efi to give it a mechanism to trust its files.
-
## UEFI

- Add support for a fallback loader.efi for UEFI boot that goes beyond UEFI Boot Manager Protocol (done)
- determines what device it was loaded from
- reads EFI|FreeBSD|loader env ??
- how is hand-over between UEFI and ZFS managed? e.g. zfsbootcfg basically propagating last-known-good into zpool bootfs property
- ZFS dataset selection in boot menu (NextBoot functionality)
- use UEFI media path to specify boot device
- [ ] provide a way to override what loader.efi would pick by default
- [ ] needs a loader.efi manpage
- [ ] loader.conf also needs a facelift (unlikely to happen though)
- what about ARM* boards that don' t have NVRAM? should be able to use existing FAT code
- [ ] what about a zfs snapshot or dataset as fallback emergency - similar to delphix AWS AMI booting from rollback?
- why can't we use the existing efibootmgr "standard"? supermicro and others interfere with setting these variables, therefore unreliable
- [ ] tsoom has enabled creating EFI partition directly during zpool creation in illumos - would be nice to pull ths in
- [ ] consider creating swap partitions via zpool as well
- [ ] bonus points for specifying boot code to cater for resilvering a data vdev that is *not* the boot zpool
- Leverage EFI NVRAM BootNext variable as part of loader update mechanism
- Userland update mechanism. What is the expected way for a user to update their EFI bootcode.

For legacy bootcode we have in zfs label ~ 3,5MiB "spare" which means you *could* have a 100% zfs-owned disk. Illumos etc have their own GPT labelling for this, modified GPT.

- do we do it as part of install world (with knobs)
- do we add a new installboot target
- Is it just a script?
- How much can we leverage for imaging
- Should we switch to ZFS managed EFI partition for full disk ZFS installs?