From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a16NQ-0004X6-CN for qemu-devel@nongnu.org; Tue, 24 Nov 2015 00:42:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a16NO-0005Iz-Rz for qemu-devel@nongnu.org; Tue, 24 Nov 2015 00:42:52 -0500 References: <1448342531-16407-1-git-send-email-famz@redhat.com> <1448342531-16407-13-git-send-email-famz@redhat.com> From: Eric Blake Message-ID: <5653F8CF.7090006@redhat.com> Date: Mon, 23 Nov 2015 22:42:39 -0700 MIME-Version: 1.0 In-Reply-To: <1448342531-16407-13-git-send-email-famz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k40Jr8Ur3svaBQtfxoV1bf3M4D2cspoqj" Subject: Re: [Qemu-devel] [PATCH for-2.6 12/14] qemu-img: In 'map', use QDict to generate JSON output List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , qemu-devel@nongnu.org Cc: Kevin Wolf , qemu-block@nongnu.org, Jeff Cody , Peter Lieven , Markus Armbruster , Stefan Hajnoczi , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k40Jr8Ur3svaBQtfxoV1bf3M4D2cspoqj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/23/2015 10:22 PM, Fam Zheng wrote: > Switch json output generation from hand-written to QDict encoder, so > that the coming str field will be properly escaped. >=20 > Iotest 122 output is updated accordingly. >=20 > Signed-off-by: Fam Zheng > --- > qemu-img.c | 30 +++++++++++---- > tests/qemu-iotests/122.out | 96 ++++++++++++++++++++++++++------------= -------- > 2 files changed, 76 insertions(+), 50 deletions(-) >=20 > case OFORMAT_JSON: > - printf("%s{ \"start\": %"PRId64", \"length\": %"PRId64", \"dep= th\": %d," > - " \"zero\": %s, \"data\": %s", > - (e->start =3D=3D 0 ? "[" : ",\n"), > - e->start, e->length, e->depth, > - (e->flags & BDRV_BLOCK_ZERO) ? "true" : "false", > - (e->flags & BDRV_BLOCK_DATA) ? "true" : "false"); > + if (e->start =3D=3D 0) { > + printf("["); > + } else { > + printf(","); > + } > + > + dict =3D qdict_new(); > + qdict_put(dict, "start", qint_from_int(e->start)); > + qdict_put(dict, "length", qint_from_int(e->length)); > + qdict_put(dict, "depth", qint_from_int(e->depth)); > + qdict_put(dict, "zero", qbool_from_bool(e->flags & BDRV_BLOCK_= ZERO)); > + qdict_put(dict, "data", qbool_from_bool(e->flags & BDRV_BLOCK_= DATA)); > if (e->flags & BDRV_BLOCK_OFFSET_VALID) { > - printf(", \"offset\": %"PRId64"", e->offset); > + qdict_put(dict, "offset", qint_from_int(e->offset)); > } > - putchar('}'); > + str =3D qobject_to_json(QOBJECT(dict)); > + printf("%s\n", qstring_get_str(str)); The conversion is sane... > +++ b/tests/qemu-iotests/122.out > @@ -49,12 +49,13 @@ read 65536/65536 bytes at offset 4194304 > 64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) > read 65536/65536 bytes at offset 8388608 > 64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) > -[{ "start": 0, "length": 65536, "depth": 0, "zero": false, "data": tru= e}, > -{ "start": 65536, "length": 4128768, "depth": 0, "zero": true, "data":= false}, > -{ "start": 4194304, "length": 65536, "depth": 0, "zero": false, "data"= : true}, > -{ "start": 4259840, "length": 4128768, "depth": 0, "zero": true, "data= ": false}, > -{ "start": 8388608, "length": 65536, "depth": 0, "zero": false, "data"= : true}, > -{ "start": 8454144, "length": 4128768, "depth": 0, "zero": true, "data= ": false}] > +[{"length": 65536, "start": 0, "zero": false, "depth": 0, "data": true= } =2E..but the output shows that QDict output is tied to internal hashing and therefore different than first-in-first-out creation order. JSON-wise, it's still valid. But are we guaranteed that our hashing is stable? If so, is that something an attacker could attempt to exploit as a Denial of Service, by intentionally creating predictable collisions? [I'm guessing not, as the denial of service is mainly an issue if a user can degrade performance of typical lookups from nominal O(1) to O(n) by supplying LOTS of user-provided input, but the keys we output in JSON are generally under our control via .json files and not something where the user is dynamically creating lots of keys - but still worth asking.] And if it is not stable, then will our test break when someone else's system hashes differently than yours? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --k40Jr8Ur3svaBQtfxoV1bf3M4D2cspoqj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWU/jPAAoJEKeha0olJ0Nqj5sIAI7gBEdp9TA9V6KV4OHlC7Ow z6xfwclaY7QD4HVRofymT9yEkCv27UEa6vSheCvuCAHSqAwQIhnII9X2eNEWCbjz MdSLadB3F8m/fT45HIBq/ICMHIf+eV4z+zjR7vodsQN1Fspa1AA4QRH/2m5t0LDR UYL3MgtjIt24PhiBbjKKfu6f84PB5ioBvN8f7t1pTTUhSPrL6hm9YWZefD691pP8 J32K4rw6ukYPo6piXPJzH2HXtgccMSuuYOVPgn2OPyZnlxK99MWEqgMMS62iNkBH kkAoPOC+P0OH+N6ggZH0/o98alq2K+sWxtihqLsfqo2lZItc/uUtbS7PqP+WPw4= =Lopf -----END PGP SIGNATURE----- --k40Jr8Ur3svaBQtfxoV1bf3M4D2cspoqj--