Re: Patch: cprng_fast performance - please review.

[Thor Lancelot Simon <tls%panix.com@localhost>]

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