linux-kernel - Re: 2.6.23-rc4-mm1

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]

Message-ID: <alpine.LFD.0.999.0709020746250.20781@enigma.security.iitk.ac.in>
Date:	Sun, 2 Sep 2007 08:22:42 +0530 (IST)
From:	Satyam Sharma <satyam@...radead.org>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: 2.6.23-rc4-mm1

On Sun, 2 Sep 2007, Herbert Xu wrote:
> 
> On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote:
> > 
> > Tangential, but I've often wondered what are the upsides of keeping
> > CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every
> > single item in crypto/ ends up "select"ing it (directly or transitively)
> > so it makes all sense to just do away with it and keep it == CONFIG_CRYPTO
> > in the Makefile, thusly:
> 
> NACK.  ALGAPI exists so that it can be built as a module, as
> opposed to CRYPTO which is always built-in.

I had already noticed that, and was even *expecting* you to reply with
*exactly* this ;-)

[ BTW CRYPTO is _not_ always built-in -- but only when CONFIG_CRYPTO=y ]

Anyway, the natural follow-up to your argument is -- why is the other
stuff in CRYPTO always built-in too ?

Take the crypto_alloc_xxx() callchain for example (I chose it because
it is the _first_ call any cryptoapi user ever has to make, and hence
it's the one that deals with module-loading stuff).

So what finally got exported out of crypto/ to the rest of the kernel
was just the crypto_alloc_xxx() wrapper. That resolves to a call to
crypto_alloc_base() in crypto/api.c, which first loads the specific
low-level algo modules, and then proceeds to crypto_init_ops(), which
itself may, say, resolve to a crypto_init_digest_ops() -- the only
interface exported from digest.c.

The point is, because the module-loading (if necessary) already takes
place before the call to digest.c is made, there is _no_ reason why
even digest.c can't be made modular -- or _any_ of the other CRYPTO
stuff (with the exception of api.c itself, of course) that "always
gets built-in" as you mentioned above.

And so caring about the optimization of making ALGAPI modular rather
than simply built-in with rest of "core" crypto stuff such as digest.c
(which could _also_ have been made modular by the same logic but wasn't)
sounds like a bogus argument to me. [ BTW did you notice that the
__crypto_alloc_tfm() has been EXPORT_SYMBOL'ed _only_ because of one
solitary modular-callsite in algapi.c ? ]

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/