Re: Patch: cprng_fast performance - please review.

Thor Lancelot Simon <[email protected]> Fri, 18 Apr 2014 13:39:18 -0400
Newsgroups gmane.os.netbsd.devel.crypto,gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
On Fri, Apr 18, 2014 at 10:27:45PM +0900, Izumi Tsutsui wrote:
> 
> Note the caller of this hc128_init() is:
> 
> > > +static void
> > > +cprng_fast_randrekey(cprng_fast_ctx_t *ctx)
> > > +{
> > > +	uint8_t key[16], iv[16];
> > > +	hc128_state_t tempstate;
> > > +	int s;
> > > +
> > > +	int have_initial = rnd_initial_entropy;
> > > +
> > > +	cprng_strong(kern_cprng, key, sizeof(key), FASYNC);
> > > +	cprng_strong(kern_cprng, iv, sizeof(iv), FASYNC);
> > > +	/* Rekey the hc128 state - expensive, don't do this at splhigh.  */
> > > +	hc128_init(&ctx->hc128, key, iv);
> 
> The "hc128_state_t" is declared as:
> 
> > > +typedef struct
> > > +{
> > > +	uint32_t p[512];
> > > +	uint32_t q[512];
> > > +	uint16_t i;
> > > +} hc128_state_t;
> 
> so it already consumes >4KB stack.
> I'm afraid "9KB stack on rekeying" is fatal on most ports.

How do you count to 9K?  I see:

	2K for p
	2K for q
	1280 bytes for w

I don't see another copy of p and q on the stack here.  Did I miss one?
The hc_128_state_t embedded in the cprng_fast_ctx is not on the stack,
it was allocated with percpu_alloc.

Thor