Optimize geli's algorithm to taste devices at boot

[pascal_freebsd.drecker.com]

Summary

Hi,

I'm heavily using geli to encrypt many disks in advanced ZFS setups. As a hardware change could also change the device numbers I always use labels to identify disks or partitions.

At boot geli tastes the devices (e.g. da0p3) before any label (e.g. gpt/os-0-zroot). If a system has 20 or more disks it is very painful to startup the machine because you have to press many times (e.g. 20x3=60) "enter" to skip the wrong passphrase questions.

Simple example with only 2 disks:

Enter passphrase for da0p3: GEOM_ELI: Wrong key for da0p3. Tries left: 2.
Enter passphrase for da0p3: GEOM_ELI: Wrong key for da0p3. Tries left: 1.
Enter passphrase for da0p3: GEOM_ELI: Wrong key for da0p3. No tries left.
Enter passphrase for da1p3: GEOM_ELI: Wrong key for da1p3. Tries left: 2.
Enter passphrase for da1p3: GEOM_ELI: Wrong key for da1p3. Tries left: 1.
Enter passphrase for da1p3: GEOM_ELI: Wrong key for da1p3. No tries left.
Enter passphrase for gpt/os-0-zroot:

With the patch it is possible to tell geli which providers should be tasted and nothing has to be skipped manually.

Result at boot:

Enter passphrase for gpt/os-0-zroot:

I use this patch on more than 40 boxes since the release of FreeBSD 10.0. However I do not use every label type which is supported by the patch.

Regards,
Pascal

[pjd]

Hi Pascal.

I know the patch makes your life easier, but in my opinion this should be fixed differently. All my other GEOM classes are able to store underlying provider's name in their metadata (check for example -h option to gmirror), which is then used to locate the right provider during tasting. I'd like this problem to be fixed the same way in GELI, so you could tell GELI that your underlying provider is gpt/foo. Unfortunately it is a bit hard to do currently, as the GELI metadata already take almost 512 bytes, so in order to do that you would need to implement storing additional metadata in second to last sector of the provider.

[pascal_freebsd.drecker.com]

Hi Pawel,

thanks for your comment.

You’re right that my solution is more a workaround than a real solution. I like your way although we will need another sector.

It’s clear that we could not use the second to last sector for already running systems. For new installations it should not be great problem or I’m wrong?

My first idea was to use a unused byte or bit to mark the existence of the second sector. Now I think that this is not a good solution. If this disk is used in an older system geli will not know about the second sector and will report a wrong size to the underlying provider. I’m right?

So I think it is the best to increment the version number of the “geli sector” if a second sector is used.

As I like to see this feature in FreeBSD 11. How can I help?

My C coding skills are very good. Unfortunately I know nearly nothing about the internals of your GEOM classes. But I am eager to learn!