netdev - Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

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, 18 Oct 2016 16:16:34 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Cc:     herbert@...dor.apana.org.au, j@...fi, luto@...capital.net
Subject: Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request
 structures per CPU

On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote:
> 
> +	aead_req = *this_cpu_ptr(ccmp->reqs);
> +	if (!aead_req) {
> +		aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
> +		if (!aead_req)
> +			return -ENOMEM;
> +		*this_cpu_ptr(ccmp->reqs) = aead_req;
> +		aead_request_set_tfm(aead_req, ccmp->tfm);
> +	}

Hmm. Is it really worth having a per-CPU variable for each possible
key? You could have a large number of those (typically three when
you're a client on an AP, and 1 + 1 for each client when you're the
AP).

Would it be so bad to have to set the TFM every time (if that's even
possible), and just have a single per-CPU cache?

johannes