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 ? Ian.