Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: Query regarding ELF loader arg style
Date: Thu, 16 Jan 2014 10:13:02 -0500	[thread overview]
Message-ID: <20140116151301.GB6156@redhat.com> (raw)
In-Reply-To: <87a9eyaumi.fsf@xmission.com>

On Tue, Jan 14, 2014 at 05:42:13PM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > Hi Eric,
> >
> > I am looking at kexec ELF loader code and wondering what are arg style
> > options.
> >
> > #define ARG_STYLE_ELF   0
> > #define ARG_STYLE_LINUX 1
> > #define ARG_STYLE_NONE  2
> >
> >
> > I have looked at them many a times but frankly never fully understood
> > what do they represent and what's the intention behind them. Can you
> > please elaborate a bit on this.
> 
> There is no standard of what kind of arguments a standalone ELF
> executable will receive from a bootloader.
> 
> Which means that in practice to support different OS's you either need
> to pass nothing or make something up.
> 
> ARG_STYLE_ELF is my own invention and a sad attempt at coming up with an
> OS agnostic standard.
> 
> ARG_STYLE_LINUX is an ELF image receiving the same arguments as the
> linux kernel.  It is a mess but it is reasonably well documented.

Hi Eric,


Even ARG_STYLE_LINUX seems to be making assumptions.

For example, look at init_linux_parameters() in
kexec-tools/kexec/arch/i386/x86-linux-setup.c.

void init_linux_parameters(struct x86_linux_param_header *real_mode)
{
        /* Fill in the values that are usually provided by the kernel. */

        /* Boot block magic */ 
        memcpy(real_mode->header_magic, "HdrS", 4);
        real_mode->protocol_version = 0x0206;
        real_mode->initrd_addr_max = DEFAULT_INITRD_ADDR_MAX;
        real_mode->cmdline_size = COMMAND_LINE_SIZE;
}

- We have no idea what's the max address we can load initrd at. So we make
  assumptions.

- We have no idea what's the maximum command line size kernel suppports. So
  we make assumptions. The other side affect of this is that we can't do
  error handling properly. I can't tell user back that you are passing
  command line which is longer than what kernel can support.

- ELF does not tell anything whether it is self relocating or not. So we
  are forced to load it at a address it has been compiled for (In case of
  kdump). And that address is already occupied by current running kernel
  so it does not work.

For the time being I have written a simple ELF loader along the lines of
kexec-tools. It defaults to ARG_STYLE_LINUX and works only with kexec and
not kexec on panic.

I have also made purgatory a stand alone relocatable object and now
purgatory is doing hash verification.

I am cleaning up the patches and will soon for another round of review
pretty soon.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2014-01-16 15:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 15:37 Query regarding ELF loader arg style Vivek Goyal
2014-01-15  1:42 ` Eric W. Biederman
2014-01-16 15:13   ` Vivek Goyal [this message]
2014-01-16 23:27     ` Eric W. Biederman
2014-01-17 14:03       ` Vivek Goyal
2014-01-17 18:03         ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140116151301.GB6156@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox