From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwtCz-0007U6-VF for qemu-devel@nongnu.org; Fri, 05 Dec 2014 08:46:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwtCr-0007Cb-2D for qemu-devel@nongnu.org; Fri, 05 Dec 2014 08:46:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwtCq-0007CK-R4 for qemu-devel@nongnu.org; Fri, 05 Dec 2014 08:46:00 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB5DjxSZ009690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 5 Dec 2014 08:46:00 -0500 Message-ID: <5481B716.1000803@redhat.com> Date: Fri, 05 Dec 2014 06:45:58 -0700 From: Eric Blake MIME-Version: 1.0 References: <1417774136-30001-1-git-send-email-mreitz@redhat.com> <1417774136-30001-3-git-send-email-mreitz@redhat.com> <5481B205.5040301@redhat.com> <5481B2DC.40402@redhat.com> In-Reply-To: <5481B2DC.40402@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rMLnwt48plpOd6QUOsehV88gdeaCGuXbL" Subject: Re: [Qemu-devel] [PATCH v2 2/4] hmp: Use blockdev-change-medium for change command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Markus Armbruster , Stefan Hajnoczi , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rMLnwt48plpOd6QUOsehV88gdeaCGuXbL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/05/2014 06:27 AM, Max Reitz wrote: >> Hmm. Not a problem with this patch (which is just reorganizing control= >> flow), but a possible design issue. The old 'change' QMP command cann= ot >> provide the encryption code, hence it cannot succeed when changing to = an >> encrypted media. But now that we are adding a new QMP command, we cou= ld >> possibly rectify that matter. However, the way I'm envisioning that i= s >> that blockdev-change-medium gains an optional parameter for encryption= >> key. Then the HMP command gains a new optional parameter for specifyi= ng >> the key, and the logic flow would look a bit more like: >> >> qmp_blockdev_change_medium(device, target, !!arg, arg, >> !!key, key, &err); >> if (err && error_get_class(err) =3D=3D ERROR_CLASS_DEVICE_ENCRYPTED &&= >> !key) { >> error_free(err); >> key =3D prompt_for_key_from_monitor; >> qmp_blockdev_change_medium(device, target, !!arg, arg, >> true, key, &err); >> } >> >> which would mean that a QMP command can now supply the key in one >> command, rather than HMP being the only way to supply a password becau= se >> of how it does a two-step process (that is, >> monitor_read_block_device_key isn't really accessible from QMP). >=20 > I'd rather put all of the encryption stuff back until we have figured > out how to fix it (that is, if we want to fix it at all)... Yeah, I totally understand (no point adding encryption unless we add it right). Which is why it doesn't hold up this series. But I _do_ want to make sure we're thinking through the design, and not painting ourselves into a corner; so at this point, I guess I'm just looking for confirmation on my thought experiment that we are extensible enough that we can support encryption at the QMP level down the road by adding optional parameters, regardless of how we map that at the HMP level. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --rMLnwt48plpOd6QUOsehV88gdeaCGuXbL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUgbcWAAoJEKeha0olJ0NqHkkH/1dRj2vHrmi1eWMM71RLK6iI /y2mmF4Usgor6wOh4JuvXFDoo2vB75R4DGM5OKWg5haGzb4sYUsw+MxCiP6JDkZ7 l2Ppenr92Di6ubJFtk9nZEof/5dKnVCLLAU6GEntJmNFY8Iz3g8aNe33ecdB9xAf RnL3Mqlr40gCKtQDXuN5j/ELcTIMVjO9Te92TkSqPdoUMmh4Q+gymnTe1UeYPIew SX6GMj6AuhNzgnSlyn6h+BGPq+KVBXSRYBWoN+JBXzX3vmrhFsk/rdWQR0CdNXTX pALHnA6CSbvgjJsvR+QaWI0Kftsb3mP3mjaAC3m9fEGYLOkbtBaaM2ejmXB1kAk= =+iAZ -----END PGP SIGNATURE----- --rMLnwt48plpOd6QUOsehV88gdeaCGuXbL--