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, 10 Mar 2014 10:42:37 -0400
From:	Vivek Goyal <>
To:	Borislav Petkov <>
Subject: Re: [PATCH 10/11] kexec: Support for loading ELF x86_64 images

On Fri, Mar 07, 2014 at 07:39:59PM +0100, Borislav Petkov wrote:

> > Well, this is mandated by the boot protocol, no?
> > 
> > "If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
> > the boot protocol version is "old".  Loading an old kernel, the
> > following parameters should be assumed:
> > 
> >         Image type = zImage
> >         initrd not supported
> >         Real-mode kernel must be located at 0x90000."
> > 
> > About version 0x0206:
> > 
> > Field name:     cmdline_size
> > Type:           read
> > Offset/size:    0x238/4
> > Protocol:       2.06+
> > 
> >   The maximum size of the command line without the terminating
> >   zero. This means that the command line can contain at most
> >   cmdline_size characters. With protocol version 2.05 and earlier, the
> >   maximum size was 255.
> > 
> > So according to the protocol, cmdline_size should be set by
> > kexec_file_load and not hardcoded to 2K, if we're mandating protocol
> > version 2.06.
> Btw, all those fields above are of type "read", which means,
> "For each field, some are information from the kernel to the bootloader
> ("read"),... "
> Now, if we assume that the first kernel is the bootloader and it loads
> the second kernel, then the first kernel shouldn't be setting all those
> fields *at* *all* because it violates the boot protocol. And that's a
> no-no.

Yes, that's a read only information for bootloader.

> Generally, how important is that use case for loading ELF images? If no
> one is actually using it, why even bother?

Distributions use bzImage for booting. Personally I have not seen anybody
using ELF vmliux for booting.

When I posted V1 of patches, Eric Biederman had said that without ELF
loader support this patchset should not go in. He said that ELF is very
generic and if we are implementing a new system call we should support
ELF loader.

So I have put a basic ELF loader in patches to show that it can work. Not
that I am very keen on it.

I will gladly remove it if others are comfortable with the idea that we
don't need an ELF loader at this point of time.

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