public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Xiongfeng Wang <wangxiongfeng2@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>, Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	dm-devel@redhat.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: Re: [PATCH 0/5] crypto: add IV generation templates
Date: Fri, 20 Jul 2018 12:45:09 +0100	[thread overview]
Message-ID: <20180720114509.GA10784@sirena.org.uk> (raw)
In-Reply-To: <CAKv+Gu_mb26HRi==5oeQyZ7ZOgifg7RUNt2c2V=tTqvFrMYq5g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

On Fri, Jul 20, 2018 at 10:02:21AM +0900, Ard Biesheuvel wrote:
> On 20 July 2018 at 00:50, Mark Brown <broonie@kernel.org> wrote:

> > Existing hardware can definitely do the IV generation and I believe that
> > it can chain multiple sectors together though I'd need to confirm this,
> > as mentioned elsewhere in the thread the ccree driver is for one of
> > the relevant devices.  I've poked some relevant people.

> As far as I can infer from the ccree driver source, IV generation and
> en/decryption are separate operations, and given that each sector
> requires both operations to be applied in sequence, letting the crypto
> layer handle an entire bio does not have any benefit *at the moment*.

Interesting...  they were reporting some benefits from that with their
out of tree driver prior to upstreaming (and there are other
implementations out there, that's the only one I definitely know about).
I have to confess I didn't look at their in tree driver, looking briefly
now it looks awfully like the hardware should be able to chain IV
generation together with encryption without bothering the CPU which
would be good enough.

> In fact, it seems to me that the ability to use protected AES keys is
> much more appealing than any performance argument (including 'it may
> be slower but at least it does not load the CPU'), so some background
> on how such a change would enable this use case would be beneficial as
> well to getting this adopted.

Right, that's another benefit which was on the radar for followup work.

> So my recommendation would be to focus on moving the IV generation
> into the crypto layer, but conservatively, and not confuse people by
> making additional changes that could theoretically improve
> performance, but only on hardware that does not exist.

It certainly seems like splitting things up will at least allow things
to progress.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-07-20 11:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18  7:30 [PATCH 0/5] crypto: add IV generation templates Xiongfeng Wang
2018-07-18  7:30 ` [PATCH 1/5] crypto: api - introduce API to (un)register a array of templates Xiongfeng Wang
2018-07-18  7:30 ` [PATCH 2/5] crypto: ccm - use template array registering API to simplify the code Xiongfeng Wang
2018-07-18  7:30 ` [PATCH 3/5] crypto: gcm " Xiongfeng Wang
2018-07-18  7:30 ` [PATCH 4/5] crypto: Add IV generation templates Xiongfeng Wang
2018-07-18  8:16   ` Milan Broz
2018-07-18  8:48     ` Xiongfeng Wang
2018-07-18 13:11     ` Mike Snitzer
2018-07-18 16:46     ` Mark Brown
2018-07-18 17:17       ` Milan Broz
2018-07-18 17:47         ` Mark Brown
2018-07-19  1:46         ` Xiongfeng Wang
2018-07-19  8:50           ` Arnd Bergmann
2018-07-19  8:54             ` Herbert Xu
2018-07-19 13:30             ` Mark Brown
2018-07-19 18:14   ` kbuild test robot
2018-07-18  7:30 ` [PATCH 5/5] dm-crypt: modify dm-crypt to rely on " Xiongfeng Wang
2018-07-18 10:59 ` [PATCH 0/5] crypto: add " Arnd Bergmann
2018-07-18 15:34   ` Ard Biesheuvel
2018-07-19 10:55     ` Xiongfeng Wang
2018-07-19 14:08       ` Ard Biesheuvel
2018-07-19 15:50         ` Mark Brown
2018-07-20  1:02           ` Ard Biesheuvel
2018-07-20 11:45             ` Mark Brown [this message]
2018-07-20 12:23               ` Ard Biesheuvel
2018-07-20 12:32                 ` Mark Brown
2018-07-22 13:39               ` Gilad Ben-Yossef
2018-07-23  0:13                 ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180720114509.GA10784@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=agk@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=dm-devel@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snitzer@redhat.com \
    --cc=wangxiongfeng2@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox