* Query regarding ELF loader arg style
@ 2014-01-09 15:37 Vivek Goyal
2014-01-15 1:42 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: Vivek Goyal @ 2014-01-09 15:37 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Kexec Mailing List
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.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query regarding ELF loader arg style
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
0 siblings, 1 reply; 6+ messages in thread
From: Eric W. Biederman @ 2014-01-15 1:42 UTC (permalink / raw)
To: Vivek Goyal; +Cc: Kexec Mailing List
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.
ARG_STYLE_NONE should just be simpley passing nothing into an ELF image.
When moving the code into the kernel we should be able to simply use
ARG_STYLE_LINUX. We can revist the other cases if there is ever a need.
The problem is real but I don't know if it needs to be solved any time soon.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query regarding ELF loader arg style
2014-01-15 1:42 ` Eric W. Biederman
@ 2014-01-16 15:13 ` Vivek Goyal
2014-01-16 23:27 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: Vivek Goyal @ 2014-01-16 15:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Kexec Mailing List
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Query regarding ELF loader arg style
2014-01-16 15:13 ` Vivek Goyal
@ 2014-01-16 23:27 ` Eric W. Biederman
2014-01-17 14:03 ` Vivek Goyal
0 siblings, 1 reply; 6+ messages in thread
From: Eric W. Biederman @ 2014-01-16 23:27 UTC (permalink / raw)
To: Vivek Goyal; +Cc: Kexec Mailing List
Vivek Goyal <vgoyal@redhat.com> writes:
> 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.
Agreed that is a deficiency. Today the maximum address is 4G and there
is a 4G pointer so assuming 4G seems safe.
> - 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.
Yes, that is unforutnate.
I expect the good solution is to have an ELF note for both of those
which will allows us to check these values in an architecture neutral
way.
But you are quite right that we haven't fixed that rough edge today :(
> - 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.
ELF does tell you if it is relocatable in the e_type field of the main
elf header. In particular ET_DYN vs ET_EXEC. ET_DYN can be loaded
anywhere, and ET_EXEC must be loaded at the specified address. It would
not surprise me if the kernel build process is using ET_EXEC in error.
ET_DYN is also what is used for PIE executables and shared libraires.
The rule with ET_DYN without a dynamic linker is that a constant offset
must be added to the load address of all of the program segments but
otherwise nothing changes. I thought I had support for that form in
kexec-tools.
Perhaps not.
> 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.
That sounds like a good start.
> I have also made purgatory a stand alone relocatable object and now
> purgatory is doing hash verification.
Cool.
> I am cleaning up the patches and will soon for another round of review
> pretty soon.
Sounds good.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Query regarding ELF loader arg style
2014-01-16 23:27 ` Eric W. Biederman
@ 2014-01-17 14:03 ` Vivek Goyal
2014-01-17 18:03 ` Eric W. Biederman
0 siblings, 1 reply; 6+ messages in thread
From: Vivek Goyal @ 2014-01-17 14:03 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Kexec Mailing List
On Thu, Jan 16, 2014 at 03:27:13PM -0800, Eric W. Biederman wrote:
[..]
> > - 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.
>
> ELF does tell you if it is relocatable in the e_type field of the main
> elf header. In particular ET_DYN vs ET_EXEC. ET_DYN can be loaded
> anywhere, and ET_EXEC must be loaded at the specified address. It would
> not surprise me if the kernel build process is using ET_EXEC in error.
>
> ET_DYN is also what is used for PIE executables and shared libraires.
>
> The rule with ET_DYN without a dynamic linker is that a constant offset
> must be added to the load address of all of the program segments but
> otherwise nothing changes. I thought I had support for that form in
> kexec-tools.
>
> Perhaps not.
Hi Eric,
Kexec-tools supports ET_DYN. I saw code for that. Current kernel vmlinux
is ET_EXEC though and expects to be loaded at the address for it has been
compiled for.
I think in intial version of patches I will just support ET_EXEC and then
support for ET_DYN can be added later. It should really be simple as all
the core structure to find a memory hole and load buffers there will
already be present. And at that time one can look into converting vmlinux
to a ET_DYN instead of ET_EXEC.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Query regarding ELF loader arg style
2014-01-17 14:03 ` Vivek Goyal
@ 2014-01-17 18:03 ` Eric W. Biederman
0 siblings, 0 replies; 6+ messages in thread
From: Eric W. Biederman @ 2014-01-17 18:03 UTC (permalink / raw)
To: Vivek Goyal; +Cc: Kexec Mailing List
Vivek Goyal <vgoyal@redhat.com> writes:
> On Thu, Jan 16, 2014 at 03:27:13PM -0800, Eric W. Biederman wrote:
>
> [..]
>> > - 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.
>>
>> ELF does tell you if it is relocatable in the e_type field of the main
>> elf header. In particular ET_DYN vs ET_EXEC. ET_DYN can be loaded
>> anywhere, and ET_EXEC must be loaded at the specified address. It would
>> not surprise me if the kernel build process is using ET_EXEC in error.
>>
>> ET_DYN is also what is used for PIE executables and shared libraires.
>>
>> The rule with ET_DYN without a dynamic linker is that a constant offset
>> must be added to the load address of all of the program segments but
>> otherwise nothing changes. I thought I had support for that form in
>> kexec-tools.
>>
>> Perhaps not.
>
> Hi Eric,
>
> Kexec-tools supports ET_DYN. I saw code for that. Current kernel vmlinux
> is ET_EXEC though and expects to be loaded at the address for it has been
> compiled for.
>
> I think in intial version of patches I will just support ET_EXEC and then
> support for ET_DYN can be added later. It should really be simple as all
> the core structure to find a memory hole and load buffers there will
> already be present. And at that time one can look into converting vmlinux
> to a ET_DYN instead of ET_EXEC.
Sounds good.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-17 18:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2014-01-16 23:27 ` Eric W. Biederman
2014-01-17 14:03 ` Vivek Goyal
2014-01-17 18:03 ` Eric W. Biederman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox