public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: valerij zaporogeci <vlrzprgts@gmail.com>
To: edk2-devel <edk2-devel@lists.01.org>
Subject: TE relocations
Date: Wed, 5 Oct 2016 18:08:53 +0300	[thread overview]
Message-ID: <CANPuzFwKjhBks_ASxhWQ8CTi8faUQ=k0vpAzf-VbFfYY0hpoWw@mail.gmail.com> (raw)

Hi everyone. I have a problem with understanding the description of TE
files and its relocations.
The specifications says this:
"17.2 XIP Images
For execute-in-place (XIP) images that do not require relocations,
loading a TE image simply
requires that the loader adjust the image’s entry point from the value
specified in the
EFI_TE_IMAGE_HEADER. For example, if the image (and thus the TE
header) resides at memory
location LoadedImageAddress, then the actual entry for the driver is
computed as follows:
EntryPoint = LoadedImageAddress + sizeof (EFI_TE_IMAGE_HEADER)
+
((EFI_TE_IMAGE_HEADER *)LoadedImageAddress)–>
AddressOfEntryPoint – ((EFI_TE_IMAGE_HEADER *)
LoadedImageAddress)–>StrippedSize;"

But it looks not as simple as "simply" adjusting the only
AddressOfEntryPoint. What "do not require relocations means" here?
Suppose an Image has ImageBase set to X in its header, and it IS at
the address X in XIP memory. Will it need relocations? For PE it
won't, but it seems it is not the case for TE. Since not only
AddressOfEntryPoint is affected, also CodeBase, sections RVAs and all
base relocations too. They all are lying not at their RVA in XIP
memory, because TE has a smaller header and screws up even
FileAlignment of sections. Doesn't it?
The adjustment in the quote uses StrippedSize and it is described as
what was removed from PE:

"The StrippedSize should be set to the number of bytes removed from
the start of the original
image, which will typically include the MS-DOS, COFF, and optional
headers, as well as the section headers."

But does it take into account section alignment by FileAlignment?
(SectionAlignment==FileAlignment in this case). Because for example if
FileAlignment = 200h, then in PE, section for code would be sitting at
n*200h from the beginning of the file and from ImageBase in XIP
memory.
Here is how specification describes PE->TE tranformation process:
"• Create an EFI_TE_IMAGE_HEADER in memory
• Parse the PE/COFF headers in an existing image and extract the
necessary fields to fill in  the EFI_TE_IMAGE_HEADER
• Fill in the signature and stripped size fields in the EFI_TE_IMAGE_HEADER
• Write out the EFI_TE_IMAGE_HEADER to a new binary file
• Write out the contents of the original image, less the stripped
headers, to the output file"

This process would place any section at different file offset
(dispecting alignment) than in PE, and as a result for XIP - different
RVA from ImageBase. For XIP this would mean that such a file requires
relocation, even though its actual ImageBase is exactly what is
written in the file. For non-XIP it would mean that the loader would
need section headers to know what displacement to put the section to
in memory to not break addresses. But they are stripped! Otherwise, if
it just blindly copies what is after TE header, RVAs would be broken,
all addresses would be broken, as for XIP.
In fact this means any TE file loaded at its preferred ImageBase will
need relocations. And for non-XIP. section header cannot be stripped.
Then what TE files would not need relocations?
Did I understand right?
Thank you for answers.


             reply	other threads:[~2016-10-05 15:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-05 15:08 valerij zaporogeci [this message]
2016-10-05 16:51 ` TE relocations Andrew Fish
2016-10-05 19:24   ` valerij zaporogeci
2016-10-05 20:58     ` Andrew Fish
2016-10-05 21:45       ` valerij zaporogeci
2016-10-05 22:11         ` Andrew Fish
2016-10-05 23:25           ` valerij zaporogeci
2016-10-06  0:07             ` Andrew Fish
2016-10-06 13:01               ` valerij zaporogeci
2016-10-08  8:54               ` Gao, Liming

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-list 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='CANPuzFwKjhBks_ASxhWQ8CTi8faUQ=k0vpAzf-VbFfYY0hpoWw@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /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