Re: Proper /proc/pid/cmdline behavior when command line is corrupt?

[Edward Falk <efalk@google.com>]

Jan Engelhardt wrote:
> Hi Edward,

>>that the environment buffer is assumed to immediately follow the
>>command line buffer.
> 
> 
> The environment buffer is not assumed to be there, it is _known_ to come right
> after the argument string, because that is how the kernel sets it up on execve
> (for x86 at least).

Is that in a spec somewhere?  Otherwise, I would argue that it isn't 
_known_ to come right after the argument string, it just _happens_ to 
come right after the argument string.  This could change in future kernels.



>>I'm currently working on a patch that removes the one page limit on
>>the returned command line buffer but I'm not convinced I should
>>retain this behavior.
> 
> 
> I think yes. proc_pid_cmdline() has these lines:
> 
> 	len = mm->arg_end - mm->arg_start
>   *	if (len > PAGE_SIZE)
>   *		len = PAGE_SIZE;
> 	res = access_process_vm(task, mm->arg_start, buffer, len, 0);
> 
> 
> and @buffer is allocated in the caller as only one page:

True, but that's an arbitrary limitation which I'm in the process of 
removing.  I have a new version of proc_pid_cmdline() which will return 
the entire commandline buffer no matter what its length.  If the 
grab-more-data-from-environment-buffer behavior is actually broken, I'd 
rather not propagate it to the new code.

	-ed falk