From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
qemu block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>,
Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] encrypt in threads
Date: Fri, 30 Nov 2018 09:48:47 +0000 [thread overview]
Message-ID: <20181130094847.GB8101@redhat.com> (raw)
In-Reply-To: <22fee90b-8144-212e-ad19-94480491f05b@virtuozzo.com>
On Thu, Nov 29, 2018 at 06:28:44PM +0000, Vladimir Sementsov-Ogievskiy wrote:
>
> On 27.11.2018 16:08, Daniel P. Berrangé wrote:
> > On Thu, Nov 22, 2018 at 01:01:20PM +0000, Vladimir Sementsov-Ogievskiy wrote:
> >> 21.11.2018 20:30, Vladimir Sementsov-Ogievskiy wrote:
> >>> Hi Daniel!
> >>>
> >>> After moving compression to threads in Qcow2 it's an obvious next step to
> >>> "threadyfy" encryption in Qcow2 too.
> >>>
> >>> But it turned out to be not as simple as I assumed. If I call qcrypto_block_encrypt
> >>> in parallel threads with the same first argument (block), it just produce wrong
> >>> things (pattern verification fails in iotests)..
> >>>
> >>> So, can you advise the way to parallelize encryption/decryption?
> >>>
> >> Hmm, just creating QCryptoBlock per each thread helped. Is it correct thing to do?
> > That's rather a heavy weight approach and would cause pain when we want
> > to support future options such as keyslot updates, and in the future,
> > LUKSv2 with master key changes.
> >
> > Probably what's needed is change to QCryptoBlock struct so that there
> > can be multiple QCryptoCipher instances allocated - one per thread.
> >
> > We might also need to introduce some locking around usage of the
> > QCryptoIVGen object, since that has a QCryptoCipher handle too.
>
>
> Can we also create QCryptoIVGen per thread, as QCryptoCipher? Or it
> should be one? If one, why my implementation with QCryptoBlock per
> thread works (at least it passes iotests, hmm)
The only IV generator that uses ciphers is the "essiv" one. Even that
one uses the cipher in ECB mode, so there is no initialization vector
required for its internal cipher. This means there's no critical
shared state that would be overwritten by threads. Thus using a
separate QCryptoCipher per thread for the essiv IV gen is overkill.
None the less I think we should protect the IV generator calls with
a mutex just to be safe. I don't think the mutex would have a notable
impact on performance of the iv generator.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2018-11-30 9:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 17:30 [Qemu-devel] encrypt in threads Vladimir Sementsov-Ogievskiy
2018-11-22 13:01 ` Vladimir Sementsov-Ogievskiy
2018-11-27 16:08 ` Daniel P. Berrangé
2018-11-29 18:28 ` Vladimir Sementsov-Ogievskiy
2018-11-30 9:48 ` Daniel P. Berrangé [this message]
2018-11-30 10:04 ` Vladimir Sementsov-Ogievskiy
2018-11-30 10:19 ` Daniel P. Berrangé
2018-11-27 16:05 ` Daniel P. Berrangé
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=20181130094847.GB8101@redhat.com \
--to=berrange@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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;
as well as URLs for NNTP newsgroup(s).