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
