icp: rip out the Solaris loadable module architecture

After progressively folding away null cases, it turns out there's
/literally/ nothing there, even if some things are part of the
Solaris SPARC DDI/DKI or the seventeen module types (some doubled for
32-bit userland), or the entire modctl syscall definition.
Nothing.

Initialisation is handled in illumos-crypto.c,
which calls all the initialisers directly

Ref: openzfs#12895
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

include/sys/crypto/icp.h

@@ -29,9 +29,6 @@
 int aes_mod_init(void);
 int aes_mod_fini(void);
 
-int edonr_mod_init(void);
-int edonr_mod_fini(void);
-
 int sha1_mod_init(void);
 int sha1_mod_fini(void);
 

lib/libicp/Makefile.am

@@ -53,12 +53,10 @@ KERNEL_C = \
 	algs/skein/skein_iv.c \
 	illumos-crypto.c \
 	io/aes.c \
-	io/edonr_mod.c \
 	io/sha1_mod.c \
 	io/sha2_mod.c \
 	io/skein_mod.c \
 	os/modhash.c \
-	os/modconf.c \
 	core/kcf_sched.c \
 	core/kcf_prov_lib.c \
 	core/kcf_callprov.c \

module/icp/Makefile.in

@@ -26,12 +26,10 @@ $(MODULE)-objs += core/kcf_mech_tabs.o
 $(MODULE)-objs += core/kcf_prov_lib.o
 $(MODULE)-objs += spi/kcf_spi.o
 $(MODULE)-objs += io/aes.o
-$(MODULE)-objs += io/edonr_mod.o
 $(MODULE)-objs += io/sha1_mod.o
 $(MODULE)-objs += io/sha2_mod.o
 $(MODULE)-objs += io/skein_mod.o
 $(MODULE)-objs += os/modhash.o
-$(MODULE)-objs += os/modconf.o
 $(MODULE)-objs += algs/modes/cbc.o
 $(MODULE)-objs += algs/modes/ccm.o
 $(MODULE)-objs += algs/modes/ctr.o

module/icp/algs/edonr/edonr.c

@@ -29,6 +29,12 @@
  * Portions copyright (c) 2013, Saso Kiselkov, All rights reserved
  */
 
+/*
+ * Unlike sha2 or skein, we won't expose edonr via the Kernel Cryptographic
+ * Framework (KCF), because Edon-R is *NOT* suitable for general-purpose
+ * cryptographic use. Users of Edon-R must interface directly to this module.
+ */
+
 #include <sys/strings.h>
 #include <sys/edonr.h>
 #include <sys/debug.h>

module/icp/core/kcf_mech_tabs.c

@@ -775,12 +775,6 @@ kcf_get_mech_entry(crypto_mech_type_t mech_type, kcf_mech_entry_t **mep)
  * If there are no hardware or software providers for the mechanism,
  * but there is an unloaded software provider, this routine will attempt
  * to load it.
- *
- * If the MOD_NOAUTOUNLOAD flag is not set, a software provider is
- * in constant danger of being unloaded.  For consumers that call
- * crypto_mech2id() only once, the provider will not be reloaded
- * if it becomes unloaded.  If a provider gets loaded elsewhere
- * without the MOD_NOAUTOUNLOAD flag being set, we set it now.
  */
 crypto_mech_type_t
 crypto_mech2id_common(const char *mechname, boolean_t load_module)

module/icp/illumos-crypto.c

@@ -61,16 +61,15 @@
  * the future it may make sense to have encryption algorithms that are
  * loadable into the ICP at runtime via separate kernel modules.
  * However, considering that this code will probably not see much use
- * outside of zfs and zfs encryption only requires aes and sha256
+ * outside of zfs and zfs encryption only requires a select few
  * algorithms it seemed like more trouble than it was worth to port over
  * Illumos's kernel module structure to a Linux kernel module. In
  * addition, The Illumos code related to keeping track of kernel modules
- * is very much tied to the Illumos OS and proved difficult to port to
- * Linux. Therefore, the structure of the ICP was simplified to work
- * statically and several pieces of code responsible for keeping track
- * of Illumos kernel modules were removed and simplified. All module
- * initialization and destruction is now called in this file during
- * Linux kernel module loading and unloading.
+ * is very much tied to the Illumos OS and proved difficult to port.
+ * Therefore, the structure of the ICP was simplified to work
+ * statically and all the Illumos kernel module loading subsystem was removed.
+ * All module initialization and destruction is now called in this file
+ * during kernel module loading and unloading.
  *
  * 4) Adding destructors: The Illumos Crypto Layer is built into
  * the Illumos kernel and is not meant to be unloaded. Some destructors
@@ -112,7 +111,6 @@ icp_fini(void)
 	skein_mod_fini();
 	sha2_mod_fini();
 	sha1_mod_fini();
-	edonr_mod_fini();
 	aes_mod_fini();
 	kcf_sched_destroy();
 	kcf_prov_tab_destroy();
@@ -141,7 +139,6 @@ icp_init(void)
 
 	/* initialize algorithms */
 	aes_mod_init();
-	edonr_mod_init();
 	sha1_mod_init();
 	sha2_mod_init();
 	skein_mod_init();