On Mon, Oct 02, 2017 at 09:14:36AM +0200, Geert Uytterhoeven wrote:

Now this has hit mainline, the "BIG_KEYS" Kconfig symbol appeared on my
radar. Is there any reason this cannot be tristate?

The help text says:

    This option provides support for holding large keys within the kernel
    (for example Kerberos ticket caches).  The data may be stored out to
    swapspace by tmpfs.

    If you are unsure as to whether this is required, answer N.

So to save kernel size, I wan't to save N, but for a distro kernel that might
have Kerberos users, you currently need to say Y, while M would be nicer.

The symbol seems to just control the build of security/keys/big_key.c,
which could use module_init() in the modular case.
I'm not sending a patch to change BIG_KEYS from bool to tristate, as this is
crypto, and I don't understand the full implications.

It's possible to have a key type in a module.  In fact, some of the existing key
types such as key_type_rxrpc can already be modular.  But I don't think it
really works as intended currently because there is no autoloading of key type
modules.  That is, if big_key was a module and you tried to add a key of type
"big_key", the big_key module would *not* be automatically loaded, so the call
would return -ENODEV.  This could be fixed, I believe.

(I also still need to convince myself that there aren't any race conditions in
key type unregistering.  It's a little weird how it changes the key type to the
".dead" key type, rather than pinning the key type in memory while it's still
used.)

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html