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: <20140616210927.GJ8170@pd.tnic>
Date:	Mon, 16 Jun 2014 23:09:27 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Vivek Goyal <vgoyal@...hat.com>
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 Mon, Jun 16, 2014 at 04:53:31PM -0400, Vivek Goyal wrote:
> Kdump kernel uses a different command line. It adds extra command line
> options to currently running kernels.
> 
> Till recent past we used to pass new kernel's memory map using command
> line "memmap=" and when command line size was 256, we could easily exhaust
> command line on large machines.
> 
> Now we support 2048 and we have not seen that issue and now we have
> moved to passing memory ranges in bootparams so that issue does not
> exist. But kernel still does allow passing memmap= on command line.
> 
> One can do same thing using kexec too.
> 
> Agreed that it is a very corner case use case. Now we can say that we
> will not support it. I am fine with that but I atleast wanted a discussion
> and common understanding of what new syscall will support and what it
> will not.
> 
> Some arches still seem to have COMMAND_LINE_SIZE 256. They will more
> likely to hit this scenario at some point of time.
> 
> Given the fact you feel so strongly on putting this upper limit, I will
> introduce it. And put a comment that if the kernel we are kexecing into
> supports longer command line, the we will not support that size and one
> needs to upgrade first kernel.

Nah, I don't feel strongly about it - I just don't trust userspace and
think that every value we get from it should be "sanitized".

But if you say that you want to be able to pass bigger command line to
2nd kernel because this is how kexec passes info, then I'm fine with it.
This is actually a very valid use case which I was asking for, thanks!

I guess if a malicious user goes at lenths to manipulate
header->cmdline_size just so that kmalloc still succeeds and we're fine
with it then I certainly don't have anything against it. I.e., if user
really wants to shoot himself in the foot, user can.

So it is a good thing we talked about it then. :-)

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/