zfs: add wolfzfs port demo.

[philljj]

Description

Add zfs/ project dir for wolfzfs (wolfcrypt OpenZFS integration) demonstration.

See readme in zfs/ dir.

Requires:

• zfs: support wolfzfs patch. wolfssl#10397

[Copilot]

Pull request overview

Adds a new zfs/ demo project showing how to integrate OpenZFS (Linux crypto path) with wolfCrypt/wolfSSL in both userspace (libwolfssl.so) and kernelspace (libwolfssl.ko), along with build/test helper scripts and a large OpenZFS patch.

Changes:

• Added build scripts for wolfSSL userspace .so, wolfSSL kernel module .ko, and patched OpenZFS (“wolfZFS”).
• Added test runner scripts for OpenZFS crypto and sanity test suites.
• Added documentation plus an OpenZFS patch (cd06f79e2_wolfzfs.patch) implementing the wolfCrypt integration.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
zfs/README.md	Documents prerequisites, kernel build, wolfSSL build, patch/apply steps, and test execution.
zfs/patches/cd06f79e2_wolfzfs.patch	Large OpenZFS patch replacing ZFS native crypto with wolfCrypt calls.
zfs/scripts/zfs/build_wolfzfs	Builds/installs patched OpenZFS against a wolfSSL source tree.
zfs/scripts/wolfssl/build_wolfssl_so	Builds/installs userspace libwolfssl.so with wolfZFS options.
zfs/scripts/wolfssl/build_wolfssl_ko	Builds/installs kernel libwolfssl.ko against a configured kernel tree.
zfs/scripts/test_zfs/run_crypto	Convenience wrapper to run OpenZFS crypto tests.
zfs/scripts/test_zfs/run_sanity	Convenience wrapper to run OpenZFS sanity tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sameehj]

1. SHA‑256 HMAC template reuse is broken
   module/icp/io/sha2_mod.c only handles sha512.wc_sha512 in both sha2_mac_init and sha2_mac_atomic's "reuse context template" path. The SHA‑256 case falls through with a stale bitwise memcpy of wc_Sha256 (no wc_Sha256Copy, no zero, no re‑init). The instant wc_Sha256 contains any internal pointer (devCtx, async, heap hint), this is a use‑after‑free / aliasing bug. Branch on hc_mech_type and call wc_Sha256Copy / wc_Sha512Copy symmetrically.

2. Resource leaks on init failure paths
   aes_init_keysched: if wc_AesCcmSetKey / wc_AesGcmSetKey fails after a successful wc_AesInit, the Aes is never freed.
   ccm_init_ctx: after the memcpy of Aes, a vmem_alloc(ccm_auth, ...) failure returns without wc_AesFree.
   gcm_init_ctx: if the AAD wc_AesGcm{Encrypt,Decrypt}Update fails, gcm_wc_aes is leaked.
   Call ccm_clear_ctx / gcm_clear_ctx / wc_AesFree on every error path.

3. aes_impl_set silently rewrites user input
   const char * wolfcrypt = "wolfcrypt";
   val = wolfcrypt;
   The zfs_aes_impl module parameter is a documented user tunable. Either accept input and remap with a cmn_err(CE_NOTE, ...), or reject unknown values with EINVAL. Don't lie to the user.

[philljj]

1. SHA‑256 HMAC template reuse is broken

I don't think this is correct, because module/icp/io/sha2_mod.c only allows SHA512 in ZFS's original implementation, e.g.:

static int                                                                      
sha2_mac_init(crypto_ctx_t *ctx, crypto_mechanism_t *mechanism,                 
    crypto_key_t *key, crypto_spi_ctx_template_t ctx_template)                  
{                                                                               
         ...                                                                                
        /*                                                                      
         * Set the digest length and block size to values appropriate to the    
         * mechanism                                                            
         */                                                                     
        switch (mechanism->cm_type) {                                           
        case SHA512_HMAC_MECH_INFO_TYPE:                                        
                sha_digest_len = SHA512_DIGEST_LENGTH;                          
                sha_hmac_block_size = SHA512_HMAC_BLOCK_SIZE;                   
                break;                                                          
        default:                                                                
                return (CRYPTO_MECHANISM_INVALID);                              
        }

2. Resource leaks on init failure paths

I'll clean this up.

3. aes_impl_set silently rewrites user input

This is intentional. We're removing the other aes_impl providers, leaving only wolfcrypt. I don't want to break or rewrite higher level test tools/harnesses that call aes_impl_set().

To make this clearer I removed references to other aes_impl providers in tests/zfs-tests/cmd/crypto_test.c in the updated patch.

[philljj]

2. Resource leaks on init failure paths

After carefully reviewing this, I could not find any leaks. E.g. aes_free_keysched() is called and covers aes_init_keysched() error paths, and same with gcm_clear_ctx() and ccm_clear_ctx() are called from crypto_free_mode_ctx(), and indirectly from aes_free_context(). I also previously looped sanity test for hours without seeing memory leaks.

However there is a potential dangling pointer bug in the OpenZFS native code for aes_common_init_ctx() (https://github.com/openzfs/zfs/blob/master/module/icp/io/aes.c#L442). Depending on the return path, aes_ctx->ac_keysched can be left dangling, though fortunately it doesn't get double freed. I'll fix that in my updated patch just to be more sane.

I also made the aes_common_init_ctx() err handling route through out: in aes_encrypt_atomic() and aes_decrypt_atomic(), so the cleanup on initialization error is more sane/clear.