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  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 16:53:31 -0400
From:	Vivek Goyal <>
To:	Borislav Petkov <>
Cc:	WANG Chao <>, Dave Young <>,,,,,,,,,
Subject: Re: [PATCH 07/13] kexec: Implementation of new syscall

On Mon, Jun 16, 2014 at 10:05:26PM +0200, Borislav Petkov wrote:
> On Mon, Jun 16, 2014 at 01:38:23PM -0400, Vivek Goyal wrote:
> > 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.
> When do you ever get to kexec a kernel with command line size differing
> from the first kernel?This use case is pretty much non-existant to
> say the least (mind you, I'm open to examples but am still waiting for
> them). And even then you go and simply upgrade the first kernel.

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists