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.

Overhauled preferred device detection

In D10447#252525, @imp wrote:

I forwarded ported this, but we're missing functionality that's been added in the past year.
See https://reviews.freebsd.org/D12161 for my forward port.
Functionality added in the year that's not in this forward port (or this current review):
o fallback to any device, that's not present.

Rebased to HEAD after committing portions of it as independent patches.

Okay, I've broken this one up into a number of smaller ones. I will wait for the last of them to go in, then I'll rebase and we can go from there.

I am not a committer. Feel free to put it in.

I will pull out some components of the patch and make some smaller ones.

Rebased to HEAD

Rebased to HEAD

In D10447#245058, @imp wrote:

This review is a little out of date and is much more ambitious than what I've just done in https://reviews.freebsd.org/D11820 . which also sets down this path, but not as completely. I fear that will make this a little harder, but maybe not by too much.

In D9680#239393, @imp wrote:

Why not 50MB instead of 512kb? That's stupidly small and precludes any and all future use of UEFI programs as well as boot block bloat. bz2 compressed, the size difference is trivial.

Rebased to head, addressed reviewer comments