ICP module breaks in-tree kernel+zfs builds

[sempervictus]

Using current master with #4329 and a few other ZVOL related changes, i'm unable to build in-tree per the instructions as i get invalid initializer errors from icp/io/aes.c:

  fs/zfs/icp/io/aes.c:135:2: error: invalid initializer
  aes_encrypt_init,
  ^~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:135:2: note: (near initialization for ‘aes_cipher_ops.<anonymous>’)
fs/zfs/icp/io/aes.c:136:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_encrypt,
  ^~~~~~~~~~~
fs/zfs/icp/io/aes.c:136:2: note: (near initialization for ‘aes_cipher_ops.decrypt_atomic’)
fs/zfs/icp/io/aes.c:138:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_encrypt_final,
  ^~~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:138:2: note: (near initialization for ‘aes_cipher_ops.decrypt_update’)
fs/zfs/icp/io/aes.c:139:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_encrypt_atomic,
  ^~~~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:139:2: note: (near initialization for ‘aes_cipher_ops.encrypt_final’)
fs/zfs/icp/io/aes.c:140:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_decrypt_init,
  ^~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:140:2: note: (near initialization for ‘aes_cipher_ops.encrypt_atomic’)
fs/zfs/icp/io/aes.c:142:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_decrypt_update,
  ^~~~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:142:2: note: (near initialization for ‘aes_cipher_ops.decrypt_init’)
fs/zfs/icp/io/aes.c:143:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_decrypt_final,
  ^~~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:143:2: note: (near initialization for ‘aes_cipher_ops.encrypt_init’)
fs/zfs/icp/io/aes.c:144:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_decrypt_atomic
  ^~~~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:144:2: note: (near initialization for ‘aes_cipher_ops.decrypt_final’)
In file included from ./include/uapi/linux/posix_types.h:4:0,
                 from ./include/uapi/linux/types.h:13,
                 from ./include/linux/types.h:5,
                 from ./include/spl/sys/types.h:28,
                 from ./include/zfs/sys/zfs_context.h:37,
                 from fs/zfs/icp/io/aes.c:29:
./include/linux/stddef.h:7:14: error: invalid initializer
 #define NULL ((void *)0)
              ^
fs/zfs/icp/io/aes.c:155:2: note: in expansion of macro ‘NULL’
  NULL,
  ^~~~
./include/linux/stddef.h:7:14: note: (near initialization for ‘aes_mac_ops.<anonymous>’)
 #define NULL ((void *)0)
              ^
fs/zfs/icp/io/aes.c:155:2: note: in expansion of macro ‘NULL’
  NULL,
  ^~~~
fs/zfs/icp/io/aes.c:159:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_mac_atomic,
  ^~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:159:2: note: (near initialization for ‘aes_mac_ops.mac_final’)
fs/zfs/icp/io/aes.c:160:2: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  aes_mac_verify_atomic
  ^~~~~~~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:160:2: note: (near initialization for ‘aes_mac_ops.mac_update’)
fs/zfs/icp/io/aes.c:169:2: error: invalid initializer
  aes_create_ctx_template,
  ^~~~~~~~~~~~~~~~~~~~~~~
fs/zfs/icp/io/aes.c:169:2: note: (near initialization for ‘aes_ctx_ops.<anonymous>’)

The code responsible is already in master, and is likely related to what @behlendorf fixed in openzfs/spl#597. I'll take a quick look to see if i can fix these issues, and while the pointers piece i can probably fix this evening, the NULL macro definition seems strange... isn't that already available, or does the CDDL licensing constraint affect what can be referenced by the module's compilation process?

[sempervictus]

Ping @tcaputi: happen to have a fix for these errors lying under the desk somewhere? :) I imagine you've spent more time in this module than anyone else, and that you may have a need/desire to be able to build monolithic/hardened kernels to reduce attack surface on the in-memory keystore.

[tcaputi]

@sempervictus I'm sorry to say I've never seen that before and in fact I just pushed a small update this morning to #4329 and the kernel built-in test came back just fine. I'm not really sure what the issue could be...

[sempervictus]

@tcaputi: The offending code isn't in your PR, but is required by it. However, i figure the grsec build exposes this as an error whereas vanilla likely throws a warning.

[raphaelcohn]

Just hit this today on Linux 4.4.35 using grsec. I'm not going to be able to fix this, sadly, but @sempervictus and @tcaputi I'd be try to apply a fork, patch or PR to test it.

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.