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]

Date:	Mon, 16 Jun 2014 13:38:23 -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 05:36:20PM +0200, Borislav Petkov wrote:
> On Fri, Jun 13, 2014 at 08:46:09AM -0400, Vivek Goyal wrote:
> > If not, then we really can't do anything about it. A large memory
> > allocation will fail and user will get error.
> 
> Of course we can! You can't trust userspace and you need to check the
> values it gives you through the syscall.
> 
> And you need a sane default. The fact that I even have to state this
> explicitly...!

And what's the sane default in this case? Using current kernel's
command line size will not work if future kernel decide to support
even longer command line size.

> 
> So what if userspace gives a maximum value for which allocation
> succeeds? Does that mean that the kernel should blindly comply and
> allocate? Of course not! That would be dumb.

I agree that some kind of upper value is good. But I am disagreeing
that using current kernel's COMMAND_LINE_SIZE is better thing to do.

Also what's the upper limit on initramfs size? There is none. The issues
you are trying to prevent can be easily created simply by passing in
a large initrd file.

If we are not putting any sane defaults on size of kernel and initramfs, I
am not really sure what do we gain here by putting an incorrect limit
on kernel command line size.

> 
> > 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.
> 
> Do you have a sensible use case where 2048 cmdline size (on x86) won't
> be enough and you really need it larger?

Who knows that in future we might have to extend it beyond 2048. You
can't say that 2048 wil never be changed. Nobody knows.

> 
> And even if this is a problem - which I seriously doubt - it would be
> problem with the 1st kernel too, not only with the kexec-ed one.

Why it will be a problem with first kernel?

So assuming that you will agree that we might have to extend kernel
command line some day, my question is how would you support kexec from
old kernel to newer kernel with larger command line size. (If I limit
support commnad line to the one supported by running kernel).

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/