All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Markus Armbruster" <armbru@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] The unholy encrypted image key mess
Date: Wed, 05 Mar 2014 11:40:58 +0100	[thread overview]
Message-ID: <5316FF3A.3050801@redhat.com> (raw)
In-Reply-To: <87k3c9ylss.fsf@blackfin.pond.sub.org>

Il 05/03/2014 11:36, Markus Armbruster ha scritto:
> Andreas Färber <afaerber@suse.de> writes:
>
>> Am 05.03.2014 09:43, schrieb Markus Armbruster:
>>> Kevin Wolf <kwolf@redhat.com> writes:
>>>
>>>> 'change' is a bit trickier because it involves several low-level actions
>>>> at once, and device_add is not one of them.
>>>
>>> The problem is that it can run while a device model is attached.
>>
>> What exactly is the problem here? 'change' is for floppy and CD, right?
>> The device stays realized/connected and guest-visible during that time,
>> and the guest should be able to live with no media while the new drive
>> is not yet decrypted. Are we just lacking a QMP command to enter the
>> password and complete the change while the guest is executing?
>
> Here's how change works (both HMP and QMP):
>
> 1. bdrv_close(); now we have no medium.
>
> 2. If a device model is attached, tell it the medium has been ejected.
>    A device model supporting notification (anything but floppy, I guess)
>    in turn notifies the guest.
>
> 3. bdrv_open(); now we again have a medium, we're in state NOKEY if the
>    image is unencrypted, and in state NEEDKEY if it's encrypted.
>
> 4. Only in state NOKEY: if a device model is attached, tell it a medium
>    has been loaded.  A device model supporting notification in turn
>    notifies the guest.
>
> 5. Only in state NEEDKEY:
>
>    If QMP, fail the command with error DeviceEncrypted.
>
>    If HMP, prompt user for password.
>
> In QMP, the client needs to follow up with a block_passwd command.  In
> HMP, the user neeeds to enter a password.  In both cases, time passes,
> guest can run, and even other monitor commands can be executed, possibly
> in other monitors.  When the password arrives:
>
> 7. Set the key, state is now GOTKEY.
>
> 8. If a device model is attached, tell it a medium has been loaded.  A
>    device model supporting notification in turn notifies the guest.
>
> Shit happens for encrypted images if anything reads or writes between
> 3. and 8.

You could use bdrv_new before step 3, to open the new medium on a new 
temporary BDS.  Then before step 8 you use bdrv_swap and delete the 
temporary BDS.

Paolo

  reply	other threads:[~2014-03-05 10:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 21:01 [Qemu-devel] The unholy encrypted image key mess Markus Armbruster
2014-02-28 22:08 ` Eric Blake
2014-03-01 14:44   ` Paolo Bonzini
2014-03-05  8:24     ` Markus Armbruster
2014-03-05  9:01       ` Paolo Bonzini
2014-03-05  9:49         ` Markus Armbruster
2014-03-05  8:15   ` Markus Armbruster
2014-03-05  9:29     ` Gerd Hoffmann
2014-03-05 10:16     ` Kevin Wolf
2014-03-05 12:45       ` Markus Armbruster
2014-03-03 10:58 ` Kevin Wolf
2014-03-05  8:43   ` Markus Armbruster
2014-03-05  9:17     ` Paolo Bonzini
2014-03-05  9:33     ` Andreas Färber
2014-03-05 10:36       ` Markus Armbruster
2014-03-05 10:40         ` Paolo Bonzini [this message]
2014-03-05 12:50           ` Markus Armbruster

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=5316FF3A.3050801@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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.