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 <vsement...@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
signature.asc
Description: OpenPGP digital signature