linux-kernel - Re: [PATCH 10/11] kexec: Support for loading ELF x86

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: <20140310144237.GA4352@redhat.com>
Date:	Mon, 10 Mar 2014 10:42:37 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
	ebiederm@...ssion.com, hpa@...or.com, mjg59@...f.ucam.org,
	greg@...ah.com, jkosina@...e.cz
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.

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/