linux-kernel - Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140613124609.GC5871@redhat.com>
Date:	Fri, 13 Jun 2014 08:46:09 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	WANG Chao <chaowang@...hat.com>, Dave Young <dyoung@...hat.com>,
	mjg59@...f.ucam.org, bhe@...hat.com, jkosina@...e.cz,
	greg@...ah.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, ebiederm@...ssion.com, hpa@...or.com,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 07/13] kexec: Implementation of new syscall
 kexec_file_load

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/