linux-kernel - Re: [PATCH 0/2] Add struct crypto_alg->cra_check_optimized for crc32c

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: <20110313090158.GA12473@gondor.apana.org.au>
Date:	Sun, 13 Mar 2011 17:01:58 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-crypto <linux-crypto@...r.kernel.org>,
	James Bottomley <James.Bottomley@...e.de>,
	Christoph Hellwig <hch@....de>,
	Randy Dunlap <rdunlap@...otime.net>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH 0/2] Add struct crypto_alg->cra_check_optimized for
	crc32c_intel

On Thu, Mar 10, 2011 at 02:05:17AM -0800, Nicholas A. Bellinger wrote:
>
> We are still expecting the libcrypto consumer (iscsi_target_mod.ko) to
> call the arch independent crypto_alloc_hash("crc32c", ...) in order to
> have libcrypto backend logic perform a request_module() upon
> architecture dependent offload modules (like crc32c_intel.ko) that
> libcrypto consumers are not (and should not) be calling directly via
> crypto_alloc_host("crc32c_intel", ...), correct..?

Right.

> Where I am getting confused is wrt to a new crypto_alg_mod_lookup() ->
> request_module() call for a struct shash_alg that has not yet be loaded
> via arch/x86/crypto/crc32c-intel.c:crc32c_intel_mod_init() ->
> crypto_register_shash().

If you look at crypto_alg_mod_lookup, basically there are two paths.
Either we already have a registered algorithm of the requested name,
or we don't.

In the first case, we won't invoke request_module and in the second
case we will.

So what I'm suggesting is that in the first case we also invoke
request_module conditionally.  Now exactly what that condition is
is the tricky bit.

The easiest is to flip a bit in the algorithm we just found.  This
isn't optimal as it'll mean that for each unregistered algorithm
we'll end up modprobing twice, but that shouldn't be too bad I
think.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/