On 05.03.21 15:49, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the maximum number of parameters"):
>> Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the maximum number of parameters"):
>>> On 05.03.21 15:37, Ian Jackson wrote:
>>>> Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the maximum number of parameters"):
>>>>> This is the max number of 0 delimited string parameters. Especially the
>>>>> stubdom case needs a binary blob (with length, of course) as parameter,
>>>>> and the number of 0 bytes in this data is just limited by the allowed
>>>>> payload length.
>>>>>
>>>>> See the comment in line 111 of xenstored_control.c.
>>>>
>>>> AFAICT this "live-update" command is variadic.  So why is this
>>>> parameter set here it all then ?
>>>
>>> In order to avoid allocating an array for 4000 arguments when there
>>> are only 5 which need to be treated as strings.
>>
>> So this parameter is doing two jobs: 1. enabling non-variadic commands
>> to take binary input; 2. preventing variadic commands from allocating
>> unbounded memory.
>>
>> The problem with this is that in case 1 exceeding the value is normal
>> and the final argument is binary data; whereas in case 2 glomming
>> together the arguments together with zeroes is wrong and potentially
>> hazrdous.
>>
>> I suggest we solve problem 2 by imposing a higher fixed (for all
>> commands, variadic or not) limit (20 or something) which causes errors
>> when exceeded, rather than silent argument misinterpretation.
> 
> Also, this use of max_pars to do job 2 seems very inconsistent.  It is
> applied only to "live-update".
> 
> If it is necessary for "live-update", which is it not necessary for
> "check" or whatever ?

live-update is the only command with binary data. The other commands are
checking all parameters to be valid, similar to normal parameter parsing
in a main() function of a user program.


Juergen