Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load

[Vivek Goyal <vgoyal@redhat.com>]

On Fri, Jun 13, 2014 at 09:50:11AM +0200, Borislav Petkov wrote:
> On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote:
> > IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does
> > not tell us anything about command line size supported by kernel being
> > loaded.
> 
> Whatever you do, you do need a sane default because even querying the
> boot protocol is not reliable as the to-be-loaded kernel's boot protocol
> might be manipulated too, before signing (who knows what people do
> in the wild).

If signature verification is on, that should catch any manipulation to
to protocol headers.

If not, then we really can't do anything about it. A large memory
allocation will fail and user will get error. 

This is not different than length of kernel or length of initrd. Somebody
might prepare a very huge file and pass that fd to kernel and kernel will
try to read the whole thing in. If file is too large, memory allocation
will fail and user space will get error. We don't try to put an upper
limit on size of kernel image or initrd.

> 
> So having a sane, unconditional fallback COMMAND_LINE_SIZE from the
> first kernel is a must, methinks.

I disagree here. What if new kernel supports (2 * COMMAND_LINE_SIZE) length
command line. We don't want to truncate command line to smaller size
because running kernel does not support that long a command line.

Thanks
Vivek