netdev - RE: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver

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:	Tue, 8 Oct 2013 14:01:36 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Johannes Berg" <johannes@...solutions.net>,
	"Ard Biesheuvel" <ard.biesheuvel@...aro.org>
Cc:	<linux-wireless@...r.kernel.org>, <netdev@...r.kernel.org>,
	<patches@...aro.org>, <linville@...driver.com>
Subject: RE: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver

> Hmm, thanks I guess. I'll need to review this in more detail, but I have
> a question first:
> 
> > +	/* allocate the variable sized aead_request on the stack */
> > +	int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
> > +			     sizeof(struct aead_request));
> > +	struct aead_request req[1 + l];
> 
> This looks a bit odd, why round up first and then add one? Why even
> bother using a struct array rather than some local struct like

Is it even a good idea to be allocating variable sized items
on the kernel stack?

There has to be enough stack available for the maximum number
of entries - so there is little point in dynamically sizing it.

	David