Daniel P. Berrangé <berra...@redhat.com> writes:
> On Wed, Sep 07, 2022 at 01:54:05PM +0200, Markus Armbruster wrote:
>> John Snow <js...@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.
