Project

General

Profile

Bug #11277

Loader cannot boot from root pool with encryption enabled

Added by Andy Fiddaman 4 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
bootloader
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Bite-size
Tags:

Description

The new ZFS encryption feature is enabled at the pool level but applied at the dataset level.
If the root pool has the feature enabled, loader cannot boot from it.

FreeBSD recently added https://svnweb.freebsd.org/base/head/stand/libsa/zfs/zfsimpl.c?r1=349217&r2=349216&pathrev=349217 to address this, we should do the same for at least the encryption feature.

From the FreeBSD ticket:

The loader obviously will not be able to boot if the boot dataset is encrypted, but
should not care if some other dataset in the root pool is encrypted.

History

#1

Updated by Andy Fiddaman 4 months ago

  • Subject changed from Loader cannot boot from root pool with encryption enabled. to Loader cannot boot from root pool with encryption enabled
#2

Updated by Andy Fiddaman 4 months ago

The symptom of this is that gptzfsboot does not produce any output and just exits.
Fixing gptzfsboot in the boot sector gets further but then /boot/loader is unable to handle the pool:

ZFS: unsupported feature: com.datto:encryption
ZFS: pool rpool is not supported
BIOS 639kB/3078904kB available memory

illumos/x86 ZFS enabled bootstrap loader, Revision 1.1
ZFS: can't find pool by guid
ZFS: can't find pool by guid
loading CORE EXT words
loading SEARCH & SEARCH-EXT words
loading Johns-Hopkins locals
loading MARKER
loading ficl O-O extensions
loading ficl utility classes
loading ficl string class

start not found

Type '?' for a list of commands, 'help' for more detailed help.
#3

Updated by Dan McDonald 4 months ago

#4

Updated by Andy Fiddaman 4 months ago

Tested on OmniOS - used to fix a non-booting VM after creating a test encrypted dataset - `rpool/enc`

bloody# dd if=/dev/urandom of=/e.key bs=32 count=1
1+0 records in
1+0 records out
32 bytes transferred in 0.000049 secs (639KB/sec)

bloody# zfs create -o encryption=on -o keyformat=raw -o keylocation=file:///e.key rpool/enc

bloody# df -h
Filesystem             Size   Used  Available Capacity  Mounted on
rpool/ROOT/2019062601-onu
                       289G  12.0G       213G     6%    /
rpool/enc              289G   320K       213G     1%    /rpool/enc

bloody# zfs get all rpool/enc | egrep 'encr|key'
rpool/enc  encryption            aes-256-ccm            -
rpool/enc  keylocation           file:///e.key          local
rpool/enc  keyformat             raw                    -
rpool/enc  encryptionroot        rpool/enc              -
rpool/enc  keystatus             available              -

Before this change, the resulting system was no longer bootable and, after, it is.
I have not done the same test with the other new features, but I would expect that creating a bookmark would also have rendered the original system unbootable and that should be fixed with this change.

#5

Updated by Andy Fiddaman 4 months ago

  • Status changed from In Progress to Pending RTI
  • % Done changed from 0 to 100
#6

Updated by Electric Monk 4 months ago

  • Status changed from Pending RTI to Closed

git commit 42b4b09e4b7ff97dc2592e69bbc2aff411cb9e55

commit  42b4b09e4b7ff97dc2592e69bbc2aff411cb9e55
Author: Andy Fiddaman <omnios@citrus-it.co.uk>
Date:   2019-06-28T11:04:38.000Z

    11277 Loader cannot boot from root pool with encryption enabled
    Reviewed by: Dan McDonald <danmcd@joyent.com>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Reviewed by: Gergő Mihály Doma <domag02@gmail.com>
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Approved by: Hans Rosenfeld <hans.rosenfeld@joyent.com>

Also available in: Atom PDF