This commit implements the Chacha20-Poly1305 AEAD from RFC 8439 as a new
algorithm option for encrypted datasets.
AES (and particularly the default AES-GCM mode used in OpenZFS) is known
to be very slow on systems without hardware assistance. There are many
such machines out there could make good use of OpenZFS, especially
low-cost machines and small boards that would otherwise make very nice
storage machines. The Raspberry Pi series of machines are a good
example.
The best option for these systems is an encryption option that performs
well in software. Chacha20-Poly1305 is the current "standard" option for
this in many contexts, and is a good choice for OpenZFS.
The core Chacha20 and Poly1305 implementations are taken from Loup
Valliant's Monocypher. These were chosen because they are compact, easy
to read, easy to use and the author has written extensively about its
development, all of which give me confidence that there are unlikely to
be any surprises.
I've added a KCF-style module to the ICP to implement the AEAD. This
implements just enough for OpenZFS, and is not suitable as a
general-purpose KCF for Illumos (though it could be the starting point
for one).
For FreeBSD, which does not use the ICP, I've instead hooked it up to
FreeBSD's builtin crypto stack.
The rest is adding an enabling property value and a feature flag and and
hooking it up to all the right touch points, and documentation updates.
The existing tests that cycle through the possible encryption options
have been extended to add one more.
I've added a test to ensure that raw receives of chacha20-poly1305
datasets do the right thing based on the state of the feature flag on
the receiving side.
There's also a test unit that runs the test vectors in RFC 8439 against
Chacha20, Poly1305 and the AEAD in the ICP that combines them. This is
most useful as a sanity check during future work to add alternate
(accelerated) implementations.
Finally, manual interop testing has been done to confirm that pools and
streams can be moved between Linux and FreeBSD correctly.
Light and uncontrolled performance testing on a Raspberry Pi 4B
(Broadcom BCM2711, no hardware AES) writing to a chacha20-poly1305
dataset was ~2.4x faster than aes-256-gcm on the same hardware. On a
Fitlet2 (Celeron J3455, AES-NI but no AVX (#10846)) it was ~1.3x faster.
Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <robn@despairlabs.com>
Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Closes#16209
sha2_mech_type_t serves double-duty, as the list of MAC providers and
also the algo type for direct callers to SHA2Init. Until we disentangle
that, reorganise it to make the separation more clear. While we're
there, remove the digest mechs we don't use.
Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Closes#16209
Still retaining the struture, for now.
Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Closes#16209
It's the only one actually used
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes#12901
In FreeBSD the struct uio was just a typedef to uio_t. In order to
extend this struct, outside of the definition for the struct uio, the
struct uio has been embedded inside of a uio_t struct.
Also renamed all the uio_* interfaces to be zfs_uio_* to make it clear
this is a ZFS interface.
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Brian Atkinson <batkinson@lanl.gov>
Closes#11438
A port of the Illumos Crypto Framework to a Linux kernel module (found
in module/icp). This is needed to do the actual encryption work. We cannot
use the Linux kernel's built in crypto api because it is only exported to
GPL-licensed modules. Having the ICP also means the crypto code can run on
any of the other kernels under OpenZFS. I ended up porting over most of the
internals of the framework, which means that porting over other API calls (if
we need them) should be fairly easy. Specifically, I have ported over the API
functions related to encryption, digests, macs, and crypto templates. The ICP
is able to use assembly-accelerated encryption on amd64 machines and AES-NI
instructions on Intel chips that support it. There are place-holder
directories for similar assembly optimizations for other architectures
(although they have not been written).
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Signed-off-by: Tony Hutter <hutter2@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #4329
Rob Norris
Rob Norris
Tino Reichardt
наб
Brian Atkinson
Tom Caputi