Better handling for future crypto parameters

[robn]

Motivation and Context

While testing #14249, I found a couple of places where OpenZFS doesn't cope well when presented with a dataset or stream that uses an unknown crypto suite. While its too late for those already deployed, we can at least make it that newer ZFS installs are able to fail gracefully rather than crash or do something weird.

Description

This introduces a new ioctl return, ZFS_ERR_CRYPTO_NOTSUP, and returns it when either we try to load an encryption key for a dataset that uses an unknown crypto suite (encryption property value) or receive a raw backup stream that uses an unknown encryption key. zfs send and zfs load-key have been updated to produce a nicer error message in those cases.

This is technically a very small ABI change, in that the ZFS_IOC_RECV_NEW and ZFS_IOC_LOAD_KEY can return a previously-unseen error code. Older versions of the ZFS-provided tools will handle these fine in their fallback error handlers, and I can't imagine any other users of those ioctls not having a similar fallback. If it was a problem, EINVAL or ENOTSUP are both plausible alternatives though they do muddy the meaning of those a little.

How Has This Been Tested?

Tested by hand by creating a dataset with -o encryption=chacha20-poly1305 (#14249) and a backup stream from it, and then loading it / receiving it into a ZFS build at master (620a977) and with this PR.

Before:

root@fitlet:~# zfs load-key sandisk
Key load error: Incorrect key provided for 'sandisk'.

root@fitlet:~# zfs recv -v sandisk/recv@snap < snap-from-chapoly.zfs
cannot receive new filesystem stream: invalid backup stream

root@fitlet:~# zdb -K $(cat /tmp/zfskey) -O sandisk foo
crypt < ZIO_CRYPT_FUNCTIONS (0x9 < 0x9)
ASSERT at module/os/linux/zfs/zio_crypt.c:568:zio_crypt_key_unwrap()
Aborted

Before (with --enable-debug):

root@fitlet:~# zfs load-key sandisk

Message from syslogd@fitlet at Mar  4 20:25:08 ...
 kernel:[1281777.454629] VERIFY3(crypt < ZIO_CRYPT_FUNCTIONS) failed (9 < 9)

Message from syslogd@fitlet at Mar  4 20:25:08 ...
 kernel:[1281777.454642] PANIC at zio_crypt.c:568:zio_crypt_key_unwrap()

After:

root@fitlet:~# zfs load-key sandisk
Key load error: 'sandisk' uses an unsupported encryption suite.

root@fitlet:~# zfs recv sandisk/recv@snap < snap-from-chapoly.zfs 
cannot receive new filesystem stream: stream uses crypto parameters not compatible with this pool

root@fitlet:~# zdb -K $(cat /tmp/zfskey) -O sandisk foo
zdb: couldn't load encryption key for sandisk: crypto params not supported

No additions to the test suite. I'm not really sure how to do this other than either checking in or cooking a dataset or backup stream under the hood, and that seems like it could be pretty brittle.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[ryao]

Since all of these commits collectively relate to ZFS_ERR_CRYPTO_NOTSUP, I think they should be squashed into a single commit. I realize the irony of saying this, given that I have been doing plenty of small commits lately, but keeping those separate at least serves a documentation purpose. Here, the documentation that we would get from separate commits is self explanatory based on where the changes are being made, so there is no reason for these changes to be kept in separate commits.