ZFS GPT labels for GELI encrypted root

Ok -- but what about decrypting a geli encrypted storage device from rc.conf?

This is the relevant lines from /etc/rc.conf:
geli_devices="gpt/beastie-storage0 gpt/beastie-storage1"
geli_gpt_beastie-storage0_flags="-k /boot/beastie-storage_encryption.key"
geli_gpt_beastie-storage1_flags="-k /boot/beastie-storage_encryption.key"
Click to expand...

This is shown during boot:
/etc/rc.conf: geli_gpt_beasti-storage0_flags=-k /boot/beastie-storage_encryption.key: not found
/etc/rc.conf: geli_gpt_beasti-storage1_flags=-k /boot/beastie-storage_encryption.key: not found
Click to expand...

Am I missing something here or isn't there geli support in the later stage of the boot process either?
 
nimo said:
Am I missing something here or isn't there geli support in the later stage of the boot process either?
Click to expand...
There is definitively geli support in the later stage of the boot process, by device names ("daX", "adaX", "ndaX", etc.) or labels ("gpt/<label>", "mirror/<label>", "label/<label>"), see example down below.

I assume /boot/beastie-storage_encryption.key does exist and is valid, where is /boot located? Is it on the same filesystem as /etc/rc.conf, or is it mounted separately?

Example:
Code: 
 # grep geli /etc/rc.conf
geli_devices="gpt/ufs0 gpt/ufs1"
geli_gpt_ufs0_flags="-p -k /boot/geli.key"
geli_gpt_ufs1_flags="-p -k /boot/geli.key"

 # dmesg | grep GEOM_ELI
GEOM_ELI: Device gpt/ufs0.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: accelerated software
GEOM_ELI: Device gpt/ufs1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: accelerated software

 # geli status
        Name  Status  Components
gpt/ufs0.eli  ACTIVE  gpt/ufs0
gpt/ufs1.eli  ACTIVE  gpt/ufs1
 
gpart show -lp
=> 40 7814037088 ada0 GPT (3.6T)
40 2008 - free - (1.0M)
2048 33554432 ada0p1 swap0 (16G)
33556480 629145600 ada0p2 beastie-sysroot0 (300G)
662702080 7109345280 ada0p3 beastie-storage0 (3.3T)
7772047360 41989768 - free - (20G)

=> 40 250069600 ada3 GPT (119G)
40 532480 ada3p1 (null) (260M)
532520 1024 ada3p3 (null) (512K)
533544 984 - free - (492K)
534528 2097152 ada3p2 boot0 (1.0G)
2631680 247437960 - free - (118G)

=> 40 7814037088 ada2 GPT (3.6T)
40 2008 - free - (1.0M)
2048 33554432 ada2p1 swap1 (16G)
33556480 629145600 ada2p2 beastie-sysroot1 (300G)
662702080 7109345280 ada2p3 beastie-storage1 (3.3T)
7772047360 41989768 - free - (20G)

=> 40 61314992 da0 GPT (29G)
40 532480 da0p1 (null) (260M)
532520 2008 - free - (1.0M)
534528 2097152 da0p2 boot-sd (1.0G)
2631680 58683352 - free - (28G)

=> 40 7814037088 ada1 GPT (3.6T)
40 2008 - free - (1.0M)
2048 33554432 ada1p1 swap2 (16G)
33556480 629145600 ada1p2 beastie-sysroot2 (300G)
662702080 7109345280 ada1p3 beastie-storage2 (3.3T)
7772047360 41989768 - free - (20G)
Click to expand...

/boot is a mirror zpool bootpool on da0p2 and ada3p2.
/etc/rc.conf is on zpool beastie-sysroot on ada0p2 and ada2p2
 
I don't understand why users still use a separate boot partition.

I would have created a geli encrypted complete Root-on-ZFS (including /boot), stored the geli key in one of that file systems directories, and configured to attach the other geli providers from its /etc/rc.conf.

How does the boot process of your setup look like with a separate boot, separate root file system (encrypted/not encrypted)?

The loader boots the kernel from /boot on da0p2 (is "da0" a USB device?) and ada3p2 and then what does happen exactly?

Is then root "beastie-sysroot" (geli provider attached perhaps, then) mounted from ada0p2 and ada2p2?
 
T-Daemon said:
The loader boots the kernel from /boot on da0p2 (is "da0" a USB device?) and ada3p2 and then what does happen exactly?
Click to expand...
Then in decrypts root-on-zfs -- no problems here. The configuration for this part is in /boot/loader.conf

Problem is just automating the gel decryption of the storage zpool.

On a similar second system I have been using this rc-script for doing that: https://github.com/clinta/geliUnlocker because there I have been storing the key remotely -- but in this case I was thinking to simplify and putting the key on /boot-partition and using provided rc-script instead for this special one.
 
I still don't understand your exact setup. Is the system you have problems with in the immediate vicinity or on a remote location?

To the issue: apparently the zpool storing /boot is not imported fast enough to be read the geli .key file from (beastie-sysroot) /etc/rc.conf. I haven't tried if UFS /boot would solve the problem.

One option I can think of is to attach the geli(8) provider through a rc(8) script, after the /boot directory storing zpool is imported.

On a similar setup you have, in a virtual machine: /etc/rc.conf (beastie-sysroot, in your case)
Code: 
gelidisks_enable="YES"

/usr/local/etc/rc.d/gelidisks:
sh: 
#!/bin/sh

# PROVIDE: gelidisks
# REQUIRE: zpool

. /etc/rc.subr

name="gelidisks"
desc="Attach additional geli(8) provider automatically, import storage pool"
rcvar="gelidisks_enable"
start_cmd="gelidisks_start"

: ${gelidisks_enable="NO"}

gelidisks_start()
{
    geli attach -p -k /boot/geli.key gpt/zstorage0 gpt/zstorage1 gpt/zstorage2
    zpool  import  zstorage
}

load_rc_config $name
run_rc_command "$1"
chmod 555 /usr/local/etc/rc.d/gelidisks

The script’s line # REQUIRE: zpool ensures the "gelidisks" script runs after /etc/rc.d/zpool, which imports the zpool that contains /boot.

On the test VM, after the loader has booted the kernel from un-encrypteed zpool /boot, root-mount-from encrypted root zpool, asking passphrase midboot, and attaching additional provider automatically, importing pool through rc(8) script "gelidisks":
Code: 
 # dmesg | grep -A 2 zstorage
GEOM_ELI: Device gpt/zstorage0.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: accelerated software
GEOM_ELI: Device gpt/zstorage1.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: accelerated software
GEOM_ELI: Device gpt/zstorage2.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: accelerated software

 # geli status
             Name  Status  Components
       ada1p4.eli  ACTIVE  ada1p4
       ada2p4.eli  ACTIVE  ada2p4
       ada3p4.eli  ACTIVE  ada3p4
gpt/zstorage0.eli  ACTIVE  gpt/zstorage0
gpt/zstorage1.eli  ACTIVE  gpt/zstorage1
gpt/zstorage2.eli  ACTIVE  gpt/zstorage2

# zpool list -v zstorage
NAME                    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zstorage               1.64T   468K  1.64T        -         -     0%     0%  1.00x    ONLINE  -
  mirror-0             1.64T   468K  1.64T        -         -     0%  0.00%      -    ONLINE
    gpt/zstorage0.eli  1.64T      -      -        -         -      -      -      -    ONLINE
    gpt/zstorage1.eli  1.64T      -      -        -         -      -      -      -    ONLINE
    gpt/zstorage2.eli  1.64T      -      -        -         -      -      -      -    ONLINE
 
You must log in or register to reply here.
Back
Top