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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)