In D31725#720207, @rew wrote:

Sounds like a bug in the upstream module. I’d prefer to see that fixed rather than using autofs to work around the zfs_key pam module bug. Or see if it’s feasible to implement a pure autofs solution (i.e., autofs loads and unloads the key for a given dataset). If neither of the above options are possible, I’m more inclined to oppose this change until a more streamlined solution can be found.

In D31725#719491, @rew wrote:

In D31725#719489, @eric_metricspace.net wrote:

As I explained in the description, this is intended to be used in conjunction with PAM to load a user's auth token as a key, allowing their encrypted home directory to be loaded when they log in, and unloaded once they've fully logged out. This in turn is a means to implement a common requirement on high-security systems.

According to the OpenZFS commit, the zfs_key pam module already unmounts the dataset and unloads the key when a session is closed.

For reference: https://github.com/openzfs/zfs/commit/221e67040fc47c15b3da2afb09bb48f1e9700fb9

In D31725#719350, @rew wrote:

Does it make sense to have autofs unload zfs keys if it doesn't even know how to load them?

In D31725#718850, @delphij wrote:

In D31725#718616, @eric_metricspace.net wrote:

In D31725#718415, @delphij wrote:

In general I don't think it's a good idea to add an option to opt-in unload of crypto keys: it should always be done unless explicitly opted out (or can't be opted out), so I'd recommend either removing the option and default to be safe, or make it an opt-out option (when specified, do not unload crypto key).

I'm not sure it's a good idea to abruptly change behavior in this way. I think it would be a better idea to introduce the ability as opt-in, and then change it to opt-out after announcing in advance.

I'm not very convinced that this is a behavior change (please do correct me if I was wrong). Here is my thought: the change seems to affect ZFS case only, and for ZFS the regular usage is that they are mounted by zfs mount -a, and my understanding is that this change is intended to be used with the PAM module to provide more automation to the load/unload key process.

If the assumption above was right, since there isn't current working way of loading ZFS encrypted dataset with this new workflow, we are not changing any existing behavior.

Abandoning, due to the existence of the upstream module in cddl

In D31725#718415, @delphij wrote:

In general I don't think it's a good idea to add an option to opt-in unload of crypto keys: it should always be done unless explicitly opted out (or can't be opted out), so I'd recommend either removing the option and default to be safe, or make it an opt-out option (when specified, do not unload crypto key).

Remaining work to be done: pass in EFI map, pass in GELI keys to keybuf, try compiling with clang.

Added ability to pass in EFI framebuffer info, so efifb works.

Switched to gcc9, tested successfully with EFI.

I noticed there was a recent release, so I updated

OK, I reverted the rawdata change.

Fixed signing of local cert, and added default DN generation

Added machine vs. local keys, fixed errors in the scripts, added checking for key expiry, fixed some other issues.

Note: I want to let this sit for a while, and I'd prefer to commit this along with other components of the trust framework.

Note, the man page for trust-config is moved to D16576

An alternative I'm considering: have a seldom-used master key named something like "machine", "master", "root", etc. which is the local trust root key. Have "local" be an intermediate keypair, signed by this master key. The master key acts only as a key-signing certificate; it cannot sign code or issue general signatures. The local key can issue more general signatures.

Background on this (and the other related change): I ran into both issues implementing signelf. They caused anomalous bugs, and I tracked them down and fixed them. So they're definitely issues, and the fixes definitely work.

Cut down to just the KMS API

Some part of this ought to be committed, as it enables TPM support in EFI. It's worth discussing exactly which parts are necessary.

This is no longer necessary.

An alternate approach to GELI was merged.

Alternate approach to GELI was merged. This is no longer needed.

I get compile errors trying to build the latest

Some thoughts here:

Rebased from HEAD

Rebase from master and tried on real hardware

Rebase to HEAD

Rebase to HEAD

Confirmed working on UFS, ZFS, and real hardware.

In D12732#313181, @tsoome wrote:

Still looking quite nice, but there is a bit of competition still, have you checked on https://reviews.freebsd.org/D13784 and how much those 2 updates are conflicting and in which order should we implement them to cause the least amount of issues on integration?

Rebase from HEAD

Rebase from HEAD

Rebase from HEAD

Accidental early rebase

Rebase to HEAD

This review actually needs more work. Turns out there's more places where things need to be added.

I'd like to get an author list for this work (and any related coming patches), as well as for the NetBSD system if possible for the bibliography.

Just as a note, I'm going to be editing a paper on a larger FreeBSD trust system for submission to BSDCan. I plan on incorporating this work into the overall design.

This is now deployed on a laptop with a multi-device, all-GELI ZFS pool. It boots with loader.efi depolyed to the ESP (a no-boot1 configuration).

Fix error that prevented ZFS preferred pool detection

Fixed efi_zfs_is_preferred so ZFS preferred volumes are correctly detected again.

The current state of things combines all the GELI precursors and the dual-purpose loader patch, then applies the GELI driver. This is placed here for testing.

Updated to reflect move to /stand

Update to reflect move to /stand

(Sorry for the extreme delay on this one)

Simplified search procedure.

I'm taking the broader architecture discussion here to -arch

The idea here is to implement what will eventually be a last-resort fallback mechanism (in the case of a blank install, or someone's EFI vars getting wiped, or something) as a means of starting the transition away from boot1. The legacy search behavior *should* be subsumed into the find_currdev_all path, but I'm unwilling to remove the legacy path completely at this point.

Rebased to HEAD

Rebased to HEAD.

OK, I know how to deal with the partition info from disks. I'm going to add a field to the pdinfo_list which contains the partition type, and I'll pluck it out of the devpaths when we register the partitions. The partition relationships can be obtained from the pdinfo list already.

Turns out this one is nowhere near complete. Need to add more stuff.

In D10512#264865, @jmaloney_ixsystems.com wrote:

In D10512#263482, @eric_metricspace.net wrote:

This one breaks up much easier, since it's mostly new code. Be aware, however, that the changes will introduce dead code until the GELI driver itself goes in.

Hi Eric. I would like to merge in this work as is into TrueOS if it still works. Are there any merges besides the 4 commits from 10-17-17 that are needed for us to merge as is? Is there a separate commit for the "GELI driver"?

This one breaks up much easier, since it's mostly new code. Be aware, however, that the changes will introduce dead code until the GELI driver itself goes in.

This one is finally on deck. I am currently running a build/test cycle after merging from HEAD following the commit of boot1_refactor. I don't anticipate breakage, but it's best to be sure. Allan should run his tests once I get through mine, since he found some issues I didn't.

Is this applied against some branch? I'm getting complaints about sys/boot/ficl.mk not being there

In D10447#262876, @imp wrote:

In D10447#262569, @eric_metricspace.net wrote:

Addressed review comments

Thanks for the updated. I'll pull this into the work I've done (I did that with a previous revision as well)

I'll look closely to see if there's anything else that's a show stopper. My quick spot check just shows niggles that can be handled after the commit and/or cleaned up prior to the commit. I'll get this in front of the boot1/loader changes I'm planning for efi boot manager. Though I'm wondering more and more why we even have boot1.... But that question isn't quite ripe to explore.

• Looking at the symbols defined / referenced in boot1 there's the full ficl/forth interpreter as well... (I have this code rebased, with some of the removals reinserted).. will need to check further... -

[edited: this was due to the refactor I've done, fixed]

That's how the EFI boot stuff originally functioned. At some point, boot1.efi got added, but in the very beginning, you just installed loader.efi to the ESP.

Note: this needs to get a test before it's merged, because I did modify the code. But a basic smoke-test ought to do it.

Addressed review comments

Do you want me to fix these, or do you want me to just sit tight?

Merged from current and updated. No conflicts, so I think the tests are still good.

Confirmed this works in QEMU

In D10447#260527, @imp wrote:

We can't land this first and then do my stuff. That would break already committed work in boot1's copy of efi_main.c.

This commit is also kinda too big to land all at once still, but I'll pull in as much as I can as I merge the efi_main's together to make the changes more bite-sized and bisectable should there be issues. There's been much grumbling of late about huge commits landing that break things that are impossible to bisect, so I'll have to break this up to ensure I won't be fielding complaints like that.

In D10447#260523, @imp wrote:

I'll take another look at it this week. I have on my plate unifying the efi_main routines that we have in the tree and I have for my uefi boot manager work since they are somewhat similar. Once that's complete, I think the biggest obstacle to getting this into the tree will be behind us since that's the biggest source of conflicts at the moment.

Also, just deployed to my laptop (multi-disk ZFS pool), and obviously it works.

Fixed issues with setting image_handle->DeviceHandle incorrectly. Correct behavior confirmed on all my QEMU tests.

Finally got time to do QEMU tests on this. Found some issues with setting the DeviceHandle on the loaded image. I fixed it for UFS detection. I also seem to have introduced a regression in ZFS preferred device detection, which I'm working to fix.

Merged from HEAD, corrected a trivial merge conflict

Also, someone please do a check for stray debug printfs. I am notoriously bad at spotting those.

Fixed issues with preferred device detection. This includes detailed analysis of the code via debug messages to make sure it's doing the right thing. Preferred devices should now be correctly detected.

I'm unsure as to what needs to happen now. Do I need to do anything to my patches yet?

If I'm not mistaken, this should work as a precursor to my GELI patch series. I will apply this, then attempt a build with boot1_refactor also applied. That should tell us whether it does the job.