public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>,
	binutils@sourceware.org
Subject: Re: Appending program headers to existing ELFs?
Date: Tue, 14 Nov 2023 12:47:25 +0000	[thread overview]
Message-ID: <f3c40681-219d-4605-a925-564aed5b3806@redhat.com> (raw)
In-Reply-To: <079b4d1e36355219a756c1eea8f18e37.matheus.a.m.moreira@gmail.com>

Hi Matheus,

> I'd like to embed arbitrary data into existing ELF executables
> in such a way that the data is automatically loaded onto memory
> and is reachable by the program at runtime.

I have to say that this does sound suspicious.  Why can't you add
the data at link time ?


> With objcopy it is already possible to embed arbitrary files
> to ELF files by placing them into sections:
> 
>      objcopy --add-section program.file1=file1 \
>              --add-section program.file2=file2 \
>              program program+files
> 
> However, those sections are unreachable when the program actually runs.

Hmm, could you create a new symbol for the section and reference the data
that way.  eg:

   objcopy \
     --add-section foo=file1 \
     --add-symbol foo_start=foo \
     --set-section-flags foo=alloc,load \
     a.out a.extra

This assumes that you can access the symbol table at runtime.  I have
no idea if this is true for kernel images however.


> So it seems to me that the solution is to add a new program header
> to the ELF executable instead of a new section. How can this be done
> with binutils tools?

At the moment this can only be done by the linker, and it will only work
if the input files are object files or relocatable binaries.  ie if a
final link has been performed then you are not going to be able to add
new program header entries using the binutils tools.  (At least not as
they are today).


> If it's not possible to do this with objcopy, can it be done with ld?
> Is it possible to add a placeholder program header table entry at link
> time so that it can be adjusted later by external tools to encompass the
> newly added sections without needing to relink the whole executable?

Possibly.  With a linker script you can layout a PHDRS structure which
describes the entries that should go into the program header.  So in
theory you can include an extra entry for use by later tools.  I do not
know if this has ever been done in practice however, so it may be that
there are unknown bugs waiting to be discovered.

Cheers
   Nick


  reply	other threads:[~2023-11-14 12:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13 14:19 Matheus Afonso Martins Moreira
2023-11-14 12:47 ` Nick Clifton [this message]
2023-11-15  1:26   ` Matheus Afonso Martins Moreira
2023-11-16  8:51     ` Nick Clifton
2023-11-17  8:05       ` Fangrui Song

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=f3c40681-219d-4605-a925-564aed5b3806@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=matheus.a.m.moreira@gmail.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).