linux-kernel - Re: [PATCH] crypto: allow to assign gfp_t for __crypto_alloc

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: <CAKv+Gu_TDwaftr=f8yG8Vna8e+PcKGXD-uggP2oB-2Tq7DWMtA@mail.gmail.com>
Date:	Wed, 20 May 2015 17:30:14 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	"Theodore Ts'o" <tytso@....edu>,
	Steffen Klassert <steffen.klassert@...unet.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Jaegeuk Kim <jaegeuk@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	linux-ext4@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-f2fs-devel@...ts.sourceforge.net, ecryptfs@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] crypto: allow to assign gfp_t for __crypto_alloc_tfm

On 20 May 2015 at 16:59, Theodore Ts'o <tytso@....edu> wrote:
> On Wed, May 20, 2015 at 09:21:20AM +0200, Steffen Klassert wrote:
>> The current pcrypt version is used just for IPsec because it supports
>> only AEAD type algorithms and does not support request backlog. But
>> I have patches to support ablkcipher algorithms and request backlog.
>> I could provide them if there is interest in it.
>
> I don't know the crypto layer well enough, and I certainly don't know
> how to deal with things like ARM CPU's with "big-little" architectures
> to understand what we might need to do to power optimize things for
> mobile handsets.  But if someone has time to look at this, that would
> be great.
>

I'd be interested in getting involved: I'm fairly intimate with the
crypto layer and the ARM/arm64 architectures, since I wrote a big
chunk of the ARM/arm64 CPU based crypto drivers.

However, it's quite a can of worms you're opening here. Speed is
easily quantified, and it may even be feasible to introduce some kind
of boottime benchmark to select the fastest implementation available
(like already exists for xor and raid6, for instance).
@Herbert: was something like this ever proposed? And would you
consider merging it if it were implemented adequately?

Power efficiency is *much* harder, since you're not only dealing with
big.LITTLE, but also NEON versus ALU (i.e., SIMD math versus integer
math) and CPU versus hw accelerator based crypto. (We have the NEON
based bit sliced AES as an example: we know it does fundamentally more
work by calculating values that the table based AES implementation
reads from a lookup table, so while it is a lot faster on most NEON
implementations, it is most likely not as power efficient) Even if it
were possible to quantify the power efficiency in the first place,
whether the most power efficient implementation should be preferred
over the fastest one is a policy decision which does not really belong
inside the kernel.

Are there any background materials or other references you can share
that shed a bit more light on this?
--
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/