From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] QMP accepts double dict keys
Date: Wed, 5 Dec 2018 12:17:39 +0000 [thread overview]
Message-ID: <20181205121737.GA2391@work-vm> (raw)
In-Reply-To: <de1686a3-1981-442d-a82a-704bca834922@redhat.com>
* Eric Blake (eblake@redhat.com) wrote:
> On 12/3/18 1:48 PM, Markus Armbruster wrote:
> > Eric Blake <eblake@redhat.com> writes:
> >
> > > On 12/3/18 10:30 AM, Max Reitz wrote:
> > > > Hi,
> > > >
> > > > QMP accepts double keys in dicts without complaining. The value it is
> > > > using is apparently the last one specified:
> > >
> > > JSON says it is undefined what happens when a client passes double
> > > keys. We are probably best off if we teach our parser to be strict and
> > > reject doubled keys in QMP as invalid.
> >
> > Not bug-compatible. Do we care?
>
> I don't think so. Such a client was already invoking undefined behavior.
> Relying on first- or last-past-the-post to win is not portable, since JSON
> parsers are allowed to use hash tables with non-deterministic lookups. I
> think erroring out is nicer than silently accepting one thing, especially if
> that might have been different than what the client (incorrectly) expected.
> I'm not even sure that we would want a deprecation period.
Agreed, because it's the type of thing that ends up being potentially
dangerous, since if you had some form of security check that was looking
at QMP messages it might check one version of the field and not the
other.
Dave
> >
> > > Hmm - can a client abuse QMP with duplicate keys to cause qemu to leak
> > > memory?
> >
> > No. parse_pair() inserts with qdict_put_obj(), which replaces the old
> > value without leaking it.
>
> Good to know.
>
> > > >
> > > > Another test case is iotest 229 which specifies both mode=absolute-paths
> > > > and mode=existing (it wants the latter).
>
> We'll have to fix such broken clients, of course. If it is just our iotests
> (and not libvirt), I'm less worried about the change in behavior.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
prev parent reply other threads:[~2018-12-05 12:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 16:30 [Qemu-devel] QMP accepts double dict keys Max Reitz
2018-12-03 16:36 ` Eric Blake
2018-12-03 19:48 ` Markus Armbruster
2018-12-03 19:57 ` Eric Blake
2018-12-04 10:24 ` Daniel P. Berrangé
2018-12-05 12:17 ` Dr. David Alan Gilbert [this message]
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=20181205121737.GA2391@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).