From: "Daniel P. Berrange" <berrange@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-devel@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v1 08/15] qcow: make encrypt_sectors encrypt in place
Date: Tue, 24 Jan 2017 12:21:00 +0000 [thread overview]
Message-ID: <20170124122100.GK14563@redhat.com> (raw)
In-Reply-To: <5d05da0d-e0f5-5fa6-6bd2-5cecc1834124@redhat.com>
On Mon, Jan 16, 2017 at 09:25:55PM +0100, Max Reitz wrote:
> On 03.01.2017 19:27, Daniel P. Berrange wrote:
> > Instead of requiring separate input/output buffers for
> > encrypting data, change encrypt_sectors() to assume
> > use of a single buffer, encrypting in place. One current
> > caller all uses the same buffer for input/output already
>
> -all?
>
> > and the other two callers are easily converted todo so.
>
> s/todo/to do/
>
> >
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
> > block/qcow.c | 36 +++++++++++-------------------------
> > 1 file changed, 11 insertions(+), 25 deletions(-)
> >
> > diff --git a/block/qcow.c b/block/qcow.c
> > index 8133fda..bc9fa2f 100644
> > --- a/block/qcow.c
> > +++ b/block/qcow.c
> > @@ -310,11 +310,10 @@ static int qcow_set_key(BlockDriverState *bs, const char *key)
> > }
> >
> > /* The crypt function is compatible with the linux cryptoloop
> > - algorithm for < 4 GB images. NOTE: out_buf == in_buf is
> > - supported */
> > + algorithm for < 4 GB images. */
> > static int encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
> > - uint8_t *out_buf, const uint8_t *in_buf,
> > - int nb_sectors, bool enc, Error **errp)
> > + uint8_t *buf, int nb_sectors, bool enc,
> > + Error **errp)
> > {
> > union {
> > uint64_t ll[2];
> > @@ -333,14 +332,12 @@ static int encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
> > }
> > if (enc) {
> > ret = qcrypto_cipher_encrypt(s->cipher,
> > - in_buf,
> > - out_buf,
> > + buf, buf,
> > 512,
> > errp);
> > } else {
> > ret = qcrypto_cipher_decrypt(s->cipher,
> > - in_buf,
> > - out_buf,
> > + buf, buf,
> > 512,
> > errp);
> > }
> > @@ -348,8 +345,7 @@ static int encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
> > return -1;
> > }
> > sector_num++;
> > - in_buf += 512;
> > - out_buf += 512;
> > + buf += 512;
> > }
> > return 0;
> > }
> > @@ -469,13 +465,12 @@ static uint64_t get_cluster_offset(BlockDriverState *bs,
> > uint64_t start_sect;
> > assert(s->cipher);
> > start_sect = (offset & ~(s->cluster_size - 1)) >> 9;
> > - memset(s->cluster_data + 512, 0x00, 512);
> > + memset(s->cluster_data, 0x00, 512);
> > for(i = 0; i < s->cluster_sectors; i++) {
> > if (i < n_start || i >= n_end) {
> > Error *err = NULL;
> > if (encrypt_sectors(s, start_sect + i,
> > - s->cluster_data,
> > - s->cluster_data + 512, 1,
> > + s->cluster_data, 1,
> > true, &err) < 0) {
> > error_free(err);
> > errno = EIO;
>
> After the first iteration of the surrounding for () loop,
> s->cluster_data is unlikely to still be filled with zeros -- but I
> suspect the code intended to always write encrypted zeros.
Yep, we must push the memset down a level.
> > @@ -653,7 +648,7 @@ static coroutine_fn int qcow_co_readv(BlockDriverState *bs, int64_t sector_num,
> > }
> > if (bs->encrypted) {
> > assert(s->cipher);
> > - if (encrypt_sectors(s, sector_num, buf, buf,
> > + if (encrypt_sectors(s, sector_num, buf,
> > n, false, &err) < 0) {
> > goto fail;
> > }
> > @@ -688,9 +683,7 @@ static coroutine_fn int qcow_co_writev(BlockDriverState *bs, int64_t sector_num,
> > BDRVQcowState *s = bs->opaque;
> > int index_in_cluster;
> > uint64_t cluster_offset;
> > - const uint8_t *src_buf;
> > int ret = 0, n;
> > - uint8_t *cluster_data = NULL;
> > struct iovec hd_iov;
> > QEMUIOVector hd_qiov;
> > uint8_t *buf;
> > @@ -728,21 +721,15 @@ static coroutine_fn int qcow_co_writev(BlockDriverState *bs, int64_t sector_num,
> > if (bs->encrypted) {
> > Error *err = NULL;
> > assert(s->cipher);
> > - if (!cluster_data) {
> > - cluster_data = g_malloc0(s->cluster_size);
> > - }
> > - if (encrypt_sectors(s, sector_num, cluster_data, buf,
> > + if (encrypt_sectors(s, sector_num, buf,
>
> If qiov->niov == 1, buf is not copied from the I/O vector but just the
> I/O vector base itself. Then, this will modify the data pointed to by
> that vector. I don't think that is a good idea.
Opps, yes, that is a bad idea. I'll force copying when bs->encrypted == true,
regardless of qiov->niov value.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
next prev parent reply other threads:[~2017-01-24 12:21 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-03 18:27 [Qemu-devel] [PATCH v1 00/15] Convert QCow[2] to QCryptoBlock & add LUKS support Daniel P. Berrange
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 01/15] block: expose crypto option names / defs to other drivers Daniel P. Berrange
2017-01-03 19:46 ` Eric Blake
2017-01-16 19:42 ` Max Reitz
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 02/15] block: add ability to set a prefix for opt names Daniel P. Berrange
2017-01-16 19:31 ` Max Reitz
2017-01-24 12:15 ` Daniel P. Berrange
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 03/15] qcow: document another weakness of qcow AES encryption Daniel P. Berrange
2017-01-16 19:37 ` Max Reitz
2017-01-24 12:11 ` Daniel P. Berrange
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 04/15] qcow: require image size to be > 1 for new images Daniel P. Berrange
2017-01-16 19:41 ` Max Reitz
2017-01-24 12:14 ` Daniel P. Berrange
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 05/15] iotests: skip 042 with qcow which dosn't support zero sized images Daniel P. Berrange
2017-01-16 19:42 ` Max Reitz
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 06/15] iotests: skip 048 with qcow which doesn't support resize Daniel P. Berrange
2017-01-16 19:48 ` Max Reitz
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 07/15] iotests: fix 097 when run with qcow Daniel P. Berrange
2017-01-16 20:04 ` Max Reitz
2017-01-17 9:59 ` Daniel P. Berrange
2017-01-18 12:44 ` Max Reitz
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 08/15] qcow: make encrypt_sectors encrypt in place Daniel P. Berrange
2017-01-16 20:25 ` Max Reitz
2017-01-24 12:21 ` Daniel P. Berrange [this message]
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 09/15] qcow: convert QCow to use QCryptoBlock for encryption Daniel P. Berrange
2017-01-16 21:16 ` Max Reitz
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 10/15] qcow2: make qcow2_encrypt_sectors encrypt in place Daniel P. Berrange
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 11/15] qcow2: convert QCow2 to use QCryptoBlock for encryption Daniel P. Berrange
2017-01-18 18:13 ` Max Reitz
2017-01-19 9:39 ` Daniel P. Berrange
2017-01-21 19:07 ` Max Reitz
2017-01-24 12:33 ` Daniel P. Berrange
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 12/15] qcow2: add support for LUKS encryption format Daniel P. Berrange
2017-01-21 18:57 ` Max Reitz
2017-01-24 13:58 ` Daniel P. Berrange
2017-01-25 15:45 ` Max Reitz
2017-01-03 18:27 ` [Qemu-devel] [PATCH v1 13/15] iotests: enable tests 134 and 158 to work with qcow (v1) Daniel P. Berrange
2017-01-21 19:12 ` Max Reitz
2017-01-03 18:28 ` [Qemu-devel] [PATCH v1 14/15] block: rip out all traces of password prompting Daniel P. Berrange
2017-01-21 19:17 ` Max Reitz
2017-01-03 18:28 ` [Qemu-devel] [PATCH v1 15/15] block: remove all encryption handling APIs Daniel P. Berrange
2017-01-21 19:22 ` Max Reitz
2017-01-24 12:49 ` Daniel P. Berrange
2017-01-25 15:58 ` [Qemu-devel] [PATCH v1 00/15] Convert QCow[2] to QCryptoBlock & add LUKS support Max Reitz
2017-01-25 16:29 ` Daniel P. Berrange
2017-01-25 16:41 ` Max Reitz
2017-01-25 17:18 ` Daniel P. Berrange
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=20170124122100.GK14563@redhat.com \
--to=berrange@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).