All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Eric Blake <eblake@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	Denis Lunev <den@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH v2 2/4] block/qcow2: refactor qcow2_co_preadv_part
Date: Wed, 14 Aug 2019 17:58:53 +0200	[thread overview]
Message-ID: <93b77cd4-0a26-ae51-865e-ab26e6ed4c5f@redhat.com> (raw)
In-Reply-To: <c439dd02-33fd-8b94-406d-dd14d5c10cde@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1628 bytes --]

On 14.08.19 17:15, Eric Blake wrote:
> On 8/14/19 4:11 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 14.08.2019 0:31, Max Reitz wrote:
>>> On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
>>>> Further patch will run partial requests of iterations of
>>>> qcow2_co_preadv in parallel for performance reasons. To prepare for
>>>> this, separate part which may be parallelized into separate function
>>>> (qcow2_co_preadv_task).
>>>>
>>>> While being here, also separate encrypted clusters reading to own
>>>> function, like it is done for compressed reading.
>>>>
>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>>> ---
> 
>>>> +     * but we must not do decryption in guest buffers for security
>>>> +     * reasons.
>>>
>>> "for security reasons" is a bit handwave-y, no?
>>
>> Hmm, let's think of it a bit.
>>
>> WRITE
>>
>> 1. We can't do any operations on write buffers, as guest may use them for
>> something else and not prepared for their change. [thx to Den, pointed to this fact]
>>
>> READ
>>
>> Hmm, here otherwise, guest should not expect something meaningful in buffers until the
>> end of read operation, so theoretically we may decrypt directly in guest buffer.. What is
>> bad with it?
> 
> The badness is that the guest can theoretically reverse-engineer the
> encryption keys if they are savvy enough to grab the contents of the
> buffer before and after.  The guest must NEVER be able to see the
> encrypted bits, which means decryption requires a bounce buffer.

Our encryption does not protect against a known-plaintext attack?

Max


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

  reply	other threads:[~2019-08-14 15:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 14:18 [Qemu-devel] [PATCH v2 0/4] qcow2: async handling of fragmented io Vladimir Sementsov-Ogievskiy
2019-07-30 14:18 ` [Qemu-devel] [PATCH v2 1/4] block: introduce aio task pool Vladimir Sementsov-Ogievskiy
2019-08-13 20:47   ` Max Reitz
2019-08-14  8:18     ` Vladimir Sementsov-Ogievskiy
2019-07-30 14:18 ` [Qemu-devel] [PATCH v2 2/4] block/qcow2: refactor qcow2_co_preadv_part Vladimir Sementsov-Ogievskiy
2019-08-13 21:31   ` Max Reitz
2019-08-14  9:11     ` Vladimir Sementsov-Ogievskiy
2019-08-14 15:03       ` Max Reitz
2019-08-14 15:15       ` Eric Blake
2019-08-14 15:58         ` Max Reitz [this message]
2019-07-30 14:18 ` [Qemu-devel] [PATCH v2 3/4] block/qcow2: refactor qcow2_co_pwritev_part Vladimir Sementsov-Ogievskiy
2019-08-14 15:55   ` Max Reitz
2019-08-14 16:23   ` Max Reitz
2019-07-30 14:18 ` [Qemu-devel] [PATCH v2 4/4] block/qcow2: introduce parallel subrequest handling in read and write Vladimir Sementsov-Ogievskiy
2019-08-14 16:24   ` Max Reitz

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=93b77cd4-0a26-ae51-865e-ab26e6ed4c5f@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.