Re: Maximum QMP reply size

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Sep 07, 2022 at 01:54:05PM +0200, Markus Armbruster wrote:
>> John Snow <jsnow@redhat.com> writes:
>> 
>> > Hi, I suspect I have asked this before, but I didn't write it down in
>> > a comment, so I forget my justification...
>> >
>> > In the QMP lib, we need to set a buffering limit for how big a QMP
>> > message can be -- In practice, I found that the largest possible
>> > response was the QAPI schema reply, and I set the code to this:
>> >
>> >     # Maximum allowable size of read buffer
>> >     _limit = (64 * 1024)
>> >
>> > However, I didn't document if this was a reasonable limit or just a
>> > "worksforme" one. I assume that there's no hard limit for the protocol
>> > or the implementation thereof in QEMU. Is there any kind of value here
>> > that would be more sensible than another?
>> >
>> > I'm worried that if replies get bigger in the future (possibly in some
>> > degenerate case I am presently unaware of) that the library default
>> > will become nonsensical.
>> >
>> > Any pointers/tips?
>> 
>> Peter and Daniel already provided some.  I can add a bit of insight into
>> how QMP output works in QEMU, which may or may not help you.
>> 
>> QEMU executes one command after the other.  A command's response
>> (success or failure) is a QDict.  Which is then formatted as JSON and
>> appended to the monitor's output buffer.
>> 
>> Events work similarly.
>> 
>> The conversion to JSON does not limit the resulting string's size.  If
>> it runs out of memory, QEMU dies.
>> 
>> The output buffer is also unbounded.  It drains into the monitor's
>> character device.
>> 
>> If the QMP client sends enough commands without reading their responses,
>> QEMU can run out of memory and die.
>> 
>> Now I'm ready to go back to your question, which is about a *single*
>> message (QMP command response or event): nothing in QEMU limits the size
>> of the QMP output message text.
>> 
>> Weak consolation: I guess QEMU is somewhat likely to run out of memory
>> and die before your client software does.  That's because QDict is a
>> pig: an empty one eats 4120 Bytes on my system.  Compares unfavourable
>> to its text representation "{}".
>
> A malicious QEMU that's trying to attack the mgmt software client
> wouldn't need to use QDict, so that's only consolation against
> accidents. An evil QEMU would just write JSON directly onto the
> monitor chardev. It wouldn't even have to be well formed JSON,
> as it could just start a string and never end it.
>
>  {"blah..repeated for 1 TB for data...."

Yes, a malicious QEMU should be able to flood the QMP socket with
constant memory and negligible CPU overhead.