Re: [Qemu-devel] KVM call minutes for Feb 15

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/17/2011 03:26 AM, Avi Kivity wrote:
> On 02/16/2011 03:34 PM, Anthony Liguori wrote:
>> On 02/16/2011 04:24 AM, Avi Kivity wrote:
>>> On 02/16/2011 01:13 AM, Anthony Liguori wrote:
>>>> On 02/15/2011 10:26 AM, Chris Wright wrote:
>>>>> QAPI and QMP
>>>>> - Anthony adding a new wiki page to describe all of this
>>>>
>>>> http://wiki.qemu.org/Features/QAPI
>>>>
>>>
>>>   [ 'change', {'device': 'str', 'target': 'str'}, {'arg': 'str'}, 
>>> 'none' ]
>>>     ->
>>>   void qmp_change(const char *device, const char *target, bool 
>>> has_arg, const char *arg, Error **errp);
>>>
>>> AFAICT a json-string allows embedded NULs ('\0000').  There 
>>> translate to UTF-8 as '\0', terminating your char *s.  Either we use 
>>> some length/pointer structure, or the parser has to look for them 
>>> and kill them, and we have to specify them as verboten.
>>
>> I feel like it would be safer for us to not accept strings with 
>> embedded NULs.  There's no way we're going to consistently handle 
>> this correctly in QEMU since we expect NUL terminated strings.  They 
>> won't work for any of the standard C functions either.
>
> I agree.  Technically we're making a backwards incompatible change to 
> the protocol specification, but I don't think there's any risk that 
> somebody is sending in strings with NULs.
>
> (btw what happens in a non-UTF-8 locale? I guess we should just reject 
> unencodable strings).

While QEMU is mostly ASCII internally, for the purposes of the JSON 
parser, we always encode and decode UTF-8.  We reject invalid UTF-8 
sequences.  But since JSON is string-encoded unicode, we can always 
decode a JSON string to valid UTF-8 as long as the string is well formed.

Regards,

Anthony Liguori