Re: [Qemu-devel] [PULL 14/30] opts: don't silently truncate long parameter keys

[Thomas Huth <thuth@redhat.com>]

On 09.05.2018 00:14, Paolo Bonzini wrote:
> From: Daniel P. Berrangé <berrange@redhat.com>

Here the accent is right ^

> The existing QemuOpts parsing code uses a fixed size 128 byte buffer
> for storing the parameter keys. If a key exceeded this size it was
> silently truncate and no error reported to the user. This behaviour was
> reasonable & harmless because traditionally the key names are all
> statically declared, and it was known that no code was declaring a key
> longer than 127 bytes. This assumption, however, ceased to be valid once
> the block layer added support for dot-separate compound keys. This
> syntax allows for keys that can be arbitrarily long, limited only by the
> number of block drivers you can stack up. With this usage, silently
> truncating the key name can never lead to correct behaviour.
> 
> Hopefully such truncation would turn into an error, when the block code
> then tried to extract options later, but there's no guarantee that will
> happen. It is conceivable that an option specified by the user may be
> truncated and then ignored. This could have serious consequences,
> possibly even leading to security problems if the ignored option set a
> security relevant parameter.
> 
> If the operating system didn't limit the user's argv when spawning QEMU,
> the code should honour whatever length arguments were given without
> imposing its own length restrictions. This patch thus changes the code
> to use a heap allocated buffer for storing the keys during parsing,
> lifting the arbitrary length restriction.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

But this one got mojibaked -------^

 Thomas