[Qemu-commits] [qemu/qemu] 900cbb: qapi: Belatedly update docs for commit 9c2f56e9f9d

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 900cbbde3f3b6467a893b7b2bbcb04b4ba4be7d5
      
https://github.com/qemu/qemu/commit/900cbbde3f3b6467a893b7b2bbcb04b4ba4be7d5
  Author: Markus Armbruster <address@hidden>
  Date:   2019-01-24 (Thu, 24 Jan 2019)

  Changed paths:
    M docs/devel/qapi-code-gen.txt

  Log Message:
  -----------
  qapi: Belatedly update docs for commit 9c2f56e9f9d

Signed-off-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>


  Commit: a95291007b2478fcf32a2d71bf133b688bb4b675
      
https://github.com/qemu/qemu/commit/a95291007b2478fcf32a2d71bf133b688bb4b675
  Author: Markus Armbruster <address@hidden>
  Date:   2019-01-24 (Thu, 24 Jan 2019)

  Changed paths:
    M docs/devel/qapi-code-gen.txt
    M include/qapi/qmp-event.h
    M monitor.c
    M qapi/qmp-event.c
    M scripts/qapi/events.py
    M stubs/monitor.c
    M tests/Makefile.include
    M tests/test-qmp-event.c

  Log Message:
  -----------
  qapi: Eliminate indirection through qmp_event_get_func_emit()

The qapi_event_send_FOO() functions emit events like this:

    QMPEventFuncEmit emit;

    emit = qmp_event_get_func_emit();
    if (!emit) {
  return;
    }

    qmp = qmp_event_build_dict("FOO");
    [put event arguments into @qmp...]

    emit(QAPI_EVENT_FOO, qmp);

The value of qmp_event_get_func_emit() depends only on the program:

* In qemu-system-FOO, it's always monitor_qapi_event_queue.

* In tests/test-qmp-event, it's always event_test_emit.

* In all other programs, it's always null.

This is exactly the kind of dependence the linker is supposed to
resolve; we don't actually need an indirection.

Note that things would fall apart if we linked more than one QAPI
schema into a single program: each set of qapi_event_send_FOO() uses
its own event enumeration, yet they share a single emit function.
Which takes the event enumeration as an argument.  Which one if
there's more than one?

More seriously: how does this work even now?  qemu-system-FOO wants
QAPIEvent, and passes a function taking that to
qmp_event_set_func_emit().  test-qmp-event wants test_QAPIEvent, and
passes a function taking that to qmp_event_set_func_emit().

It works by type trickery, of course:

    typedef void (*QMPEventFuncEmit)(unsigned event, QDict *dict);

    void qmp_event_set_func_emit(QMPEventFuncEmit emit);

    QMPEventFuncEmit qmp_event_get_func_emit(void);

We use unsigned instead of the enumeration type.  Relies on both
enumerations boiling down to unsigned, which happens to be true for
the compilers we use.

Clean this up as follows:

* Generate qapi_event_send_FOO() that call PREFIX_qapi_event_emit()
  instead of the value of qmp_event_set_func_emit().

* Generate a prototype for PREFIX_qapi_event_emit() into
  qapi-events.h.

* PREFIX_ is empty for qapi/qapi-schema.json, and test_ for
  tests/qapi-schema/qapi-schema-test.json.  It's qga_ for
  qga/qapi-schema.json, and doc-good- for
  tests/qapi-schema/doc-good.json, but those don't define any events.

* Rename monitor_qapi_event_queue() to qapi_event_emit() instead of
  passing it to qmp_event_set_func_emit().  This takes care of
  qemu-system-FOO.

* Rename event_test_emit() to test_qapi_event_emit() instead of
  passing it to qmp_event_set_func_emit().  This takes care of
  tests/test-qmp-event.

* Add a qapi_event_emit() that does nothing to stubs/monitor.c.  This
  takes care of all other programs that link code emitting QMP events.

* Drop qmp_event_set_func_emit(), qmp_event_get_func_emit().

Signed-off-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
[Commit message typos fixed]


  Commit: dd49d9d8a22c22c73c82f5e3f986d5814b3a4034
      
https://github.com/qemu/qemu/commit/dd49d9d8a22c22c73c82f5e3f986d5814b3a4034
  Author: Wainer dos Santos Moschetta <address@hidden>
  Date:   2019-01-24 (Thu, 24 Jan 2019)

  Changed paths:
    M qapi/misc.json

  Log Message:
  -----------
  qmp: Add examples to qom list, get, and set commands

Added examples for the qom-list, qom-get, and qom-set
commands in qapi misc JSON file.

Signed-off-by: Wainer dos Santos Moschetta <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>


  Commit: bbc0586ced6e9ffdfd29d89fcc917b3d90ac3938
      
https://github.com/qemu/qemu/commit/bbc0586ced6e9ffdfd29d89fcc917b3d90ac3938
  Author: Christophe Fergeau <address@hidden>
  Date:   2019-01-24 (Thu, 24 Jan 2019)

  Changed paths:
    M qobject/json-parser.c
    M tests/check-qjson.c

  Log Message:
  -----------
  json: Fix % handling when not interpolating

Commit 8bca4613 added support for %% in json strings when interpolating,
but in doing so broke handling of % when not interpolating.

When parse_string() is fed a string token containing '%', it skips the
'%' regardless of ctxt->ap, i.e. even it's not interpolating.  If the
'%' is the string's last character, it fails an assertion.  Else, it
"merely" swallows the '%'.

Fix parse_string() to handle '%' specially only when interpolating.

To gauge the bug's impact, let's review non-interpolating users of this
parser, i.e. code passing NULL context to json_message_parser_init():

* tests/check-qjson.c, tests/test-qobject-input-visitor.c,
  tests/test-visitor-serialization.c

  Plenty of tests, but we still failed to cover the buggy case.

* monitor.c: QMP input

* qga/main.c: QGA input

* qobject_from_json():

  - qobject-input-visitor.c: JSON command line option arguments of
    -display and -blockdev

    Reproducer: -blockdev '{"%"}'

  - block.c: JSON pseudo-filenames starting with "json:"

    Reproducer: https://bugzilla.redhat.com/show_bug.cgi?id=1668244#c3

  - block/rbd.c: JSON key pairs

    Pseudo-filenames starting with "rbd:".

Command line, QMP and QGA input are trusted.

Filenames are trusted when they come from command line, QMP or HMP.
They are untrusted when they come from from image file headers.
Example: QCOW2 backing file name.  Note that this is *not* the security
boundary between host and guest.  It's the boundary between host and an
image file from an untrusted source.

Neither failing an assertion nor skipping a character in a filename of
your choice looks exploitable.  Note that we don't support compiling
with NDEBUG.

Fixes: 8bca4613e6cddd948895b8db3def05950463495b
Cc: address@hidden
Signed-off-by: Christophe Fergeau <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Tested-by: Richard W.M. Jones <address@hidden>
[Commit message extended to discuss impact]
Signed-off-by: Markus Armbruster <address@hidden>


  Commit: 9dd0d8111fbb8015db75a38933aee1d45f9e64a3
      
https://github.com/qemu/qemu/commit/9dd0d8111fbb8015db75a38933aee1d45f9e64a3
  Author: Peter Maydell <address@hidden>
  Date:   2019-01-25 (Fri, 25 Jan 2019)

  Changed paths:
    M docs/devel/qapi-code-gen.txt
    M include/qapi/qmp-event.h
    M monitor.c
    M qapi/misc.json
    M qapi/qmp-event.c
    M qobject/json-parser.c
    M scripts/qapi/events.py
    M stubs/monitor.c
    M tests/Makefile.include
    M tests/check-qjson.c
    M tests/test-qmp-event.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-01-24' into 
staging

QAPI patches for 2019-01-24

# gpg: Signature made Thu 24 Jan 2019 14:25:19 GMT
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <address@hidden>"
# gpg:                 aka "Markus Armbruster <address@hidden>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-qapi-2019-01-24:
  json: Fix % handling when not interpolating
  qmp: Add examples to qom list, get, and set commands
  qapi: Eliminate indirection through qmp_event_get_func_emit()
  qapi: Belatedly update docs for commit 9c2f56e9f9d

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/87f6a866f12b...9dd0d8111fbb
      **NOTE:** GitHub Services has been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      We will provide an alternative path for the email notifications by 
January 31st, 2019.