lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 2 Oct 2017 10:01:11 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
        kernel-hardening@...ts.openwall.com,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Kirill Marinushkin <k.marinushkin@...il.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Ilhan Gurel <ilhan.gurel@...il.com>, security@...nel.org,
        stable <stable@...r.kernel.org>
Subject: Re: Modular BIG_KEYS (was: Re: [PATCH v4] security/keys: rewrite all
 of big_key crypto)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ