Relocation fixup during AARCH64 SEC PE-COFF generation?

Relocation fixup during AARCH64 SEC PE-COFF generation?

[Achin Gupta]

Hi All,

Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
executes directly from within the firmware volume. The FV would typically be
loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
types converts a PE-COFF module into a stripped Terse executable as follows:

[Rule.AARCH64.SEC]
  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
    TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
  }

The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
when the ELF image is generated. Since the SEC module is able to "XIP" from the
within FV, this means that the relocations have to be fixed up at link time
before the TE image is created.

It seems to me that in GenFw.c, at least the static relocations are fixed up
when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
in understanding that dynamic relocations will be left as is in the PE-COFF
image while static relocations will be fixed up?

Please let me know if you need any clarifications.

Thanks a lot,
Achin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: Relocation fixup during AARCH64 SEC PE-COFF generation?

[Ard Biesheuvel]

On 13 September 2016 at 15:03, Achin Gupta <achin.gupta@arm.com> wrote:
> Hi All,
>
> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
> executes directly from within the firmware volume. The FV would typically be
> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
> types converts a PE-COFF module into a stripped Terse executable as follows:
>
> [Rule.AARCH64.SEC]
>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
>     TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
>   }
>
> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
> when the ELF image is generated. Since the SEC module is able to "XIP" from the
> within FV, this means that the relocations have to be fixed up at link time
> before the TE image is created.
>

Correct. GenFv relocates the image based on the runtime address of the
firmware volume.

> It seems to me that in GenFw.c, at least the static relocations are fixed up
> when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
> in understanding that dynamic relocations will be left as is in the PE-COFF
> image while static relocations will be fixed up?
>

We usually don't emit dynamic relocations, since we are not linking
shared objects.

Re: Relocation fixup during AARCH64 SEC PE-COFF generation?

[Ard Biesheuvel]

On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 13 September 2016 at 15:03, Achin Gupta <achin.gupta@arm.com> wrote:
>> Hi All,
>>
>> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
>> executes directly from within the firmware volume. The FV would typically be
>> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
>> types converts a PE-COFF module into a stripped Terse executable as follows:
>>
>> [Rule.AARCH64.SEC]
>>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
>>     TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
>>   }
>>
>> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
>> when the ELF image is generated. Since the SEC module is able to "XIP" from the
>> within FV, this means that the relocations have to be fixed up at link time
>> before the TE image is created.
>>
>
> Correct. GenFv relocates the image based on the runtime address of the
> firmware volume.
>
>> It seems to me that in GenFw.c, at least the static relocations are fixed up
>> when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
>> in understanding that dynamic relocations will be left as is in the PE-COFF
>> image while static relocations will be fixed up?
>>
>
> We usually don't emit dynamic relocations, since we are not linking
> shared objects.

... or more specifically, all absolute static relocations are
converted into PE/COFF base relocations, all relative static
relocations are validated against the PE/COFF layout (which we keep
1:1 identical with the ELF section layout), and all dynamic
relocations are ignored. Note that this implies that proxy generating
static relocations are rejected, since --emit-relocs does not produce
any output for the proxies.

Re: Relocation fixup during AARCH64 SEC PE-COFF generation?

[Achin Gupta]

On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote:
> On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 13 September 2016 at 15:03, Achin Gupta <achin.gupta@arm.com> wrote:
> >> Hi All,
> >>
> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
> >> executes directly from within the firmware volume. The FV would typically be
> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
> >> types converts a PE-COFF module into a stripped Terse executable as follows:
> >>
> >> [Rule.AARCH64.SEC]
> >>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
> >>     TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
> >>   }
> >>
> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
> >> when the ELF image is generated. Since the SEC module is able to "XIP" from the
> >> within FV, this means that the relocations have to be fixed up at link time
> >> before the TE image is created.
> >>
> >
> > Correct. GenFv relocates the image based on the runtime address of the
> > firmware volume.
> >
> >> It seems to me that in GenFw.c, at least the static relocations are fixed up
> >> when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
> >> in understanding that dynamic relocations will be left as is in the PE-COFF
> >> image while static relocations will be fixed up?
> >>
> >
> > We usually don't emit dynamic relocations, since we are not linking
> > shared objects.
>
> ... or more specifically, all absolute static relocations are
> converted into PE/COFF base relocations, all relative static
> relocations are validated against the PE/COFF layout (which we keep
> 1:1 identical with the ELF section layout), and all dynamic
> relocations are ignored.

Thanks Ard. I expect the relative static relocations to be fixed by the PE-COFF
loader at runtime.

> Note that this implies that proxy generating
> static relocations are rejected, since --emit-relocs does not produce
> any output for the proxies.

You lost me here. What do you mean by "proxy generating static relocations"?

cheers,
Achin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: Relocation fixup during AARCH64 SEC PE-COFF generation?

[Ard Biesheuvel]

On 13 September 2016 at 16:16, Achin Gupta <achin.gupta@arm.com> wrote:
> On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote:
>> On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > On 13 September 2016 at 15:03, Achin Gupta <achin.gupta@arm.com> wrote:
>> >> Hi All,
>> >>
>> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
>> >> executes directly from within the firmware volume. The FV would typically be
>> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
>> >> types converts a PE-COFF module into a stripped Terse executable as follows:
>> >>
>> >> [Rule.AARCH64.SEC]
>> >>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
>> >>     TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
>> >>   }
>> >>
>> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
>> >> when the ELF image is generated. Since the SEC module is able to "XIP" from the
>> >> within FV, this means that the relocations have to be fixed up at link time
>> >> before the TE image is created.
>> >>
>> >
>> > Correct. GenFv relocates the image based on the runtime address of the
>> > firmware volume.
>> >
>> >> It seems to me that in GenFw.c, at least the static relocations are fixed up
>> >> when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
>> >> in understanding that dynamic relocations will be left as is in the PE-COFF
>> >> image while static relocations will be fixed up?
>> >>
>> >
>> > We usually don't emit dynamic relocations, since we are not linking
>> > shared objects.
>>
>> ... or more specifically, all absolute static relocations are
>> converted into PE/COFF base relocations, all relative static
>> relocations are validated against the PE/COFF layout (which we keep
>> 1:1 identical with the ELF section layout), and all dynamic
>> relocations are ignored.
>
> Thanks Ard. I expect the relative static relocations to be fixed by the PE-COFF
> loader at runtime.
>

No. The PE/COFF loader only processes base relocations, which are
essentially pointers into the image where absolute addresses are
stored, and which need to have an offset applied based on the
difference between the link time base address and the load time base
address. Like in ELF, no relative dynamic relocations exist.

Only because of the ELF to PE/COFF conversion, we have to ensure that
any relative references are still valid after the conversion.

>> Note that this implies that proxy generating
>> static relocations are rejected, since --emit-relocs does not produce
>> any output for the proxies.
>
> You lost me here. What do you mean by "proxy generating static relocations"?
>

Basically, GOT based relocations that result in a GOT entry to be
emitted when linking a shared object. Since those relocations are
essentially instructions to the linker to emit such a GOT entry, the
absolute relocation itself which causes the GOT entry to hold the
correct value at runtime is not present in the object file, will hence
not be emitted by --emit-relocs, and so will not have a corresponding
PE/COFF base relocation emitted for it. This is the reason why we
currently cannot support such GOT based relocations.

Re: Relocation fixup during AARCH64 SEC PE-COFF generation?

[Achin Gupta]

On Tue, Sep 13, 2016 at 04:25:32PM +0100, Ard Biesheuvel wrote:
> On 13 September 2016 at 16:16, Achin Gupta <achin.gupta@arm.com> wrote:
> > On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote:
> >> On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> > On 13 September 2016 at 15:03, Achin Gupta <achin.gupta@arm.com> wrote:
> >> >> Hi All,
> >> >>
> >> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
> >> >> executes directly from within the firmware volume. The FV would typically be
> >> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
> >> >> types converts a PE-COFF module into a stripped Terse executable as follows:
> >> >>
> >> >> [Rule.AARCH64.SEC]
> >> >>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
> >> >>     TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
> >> >>   }
> >> >>
> >> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
> >> >> when the ELF image is generated. Since the SEC module is able to "XIP" from the
> >> >> within FV, this means that the relocations have to be fixed up at link time
> >> >> before the TE image is created.
> >> >>
> >> >
> >> > Correct. GenFv relocates the image based on the runtime address of the
> >> > firmware volume.
> >> >
> >> >> It seems to me that in GenFw.c, at least the static relocations are fixed up
> >> >> when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
> >> >> in understanding that dynamic relocations will be left as is in the PE-COFF
> >> >> image while static relocations will be fixed up?
> >> >>
> >> >
> >> > We usually don't emit dynamic relocations, since we are not linking
> >> > shared objects.
> >>
> >> ... or more specifically, all absolute static relocations are
> >> converted into PE/COFF base relocations, all relative static
> >> relocations are validated against the PE/COFF layout (which we keep
> >> 1:1 identical with the ELF section layout), and all dynamic
> >> relocations are ignored.
> >
> > Thanks Ard. I expect the relative static relocations to be fixed by the PE-COFF
> > loader at runtime.
> >
>
> No. The PE/COFF loader only processes base relocations, which are
> essentially pointers into the image where absolute addresses are
> stored, and which need to have an offset applied based on the
> difference between the link time base address and the load time base
> address. Like in ELF, no relative dynamic relocations exist.
>
> Only because of the ELF to PE/COFF conversion, we have to ensure that
> any relative references are still valid after the conversion.

Obviously I am not well versed with the correct terminology :(

I guess we are both talking about the base relocations done in
PeCoffLoaderRelocateImage() (MdePkg/Library/BasePeCoffLib/BasePeCoff.c) i.e. the
EFI_IMAGE_REL_BASED_* types defined in EfiImage.h?

>
> >> Note that this implies that proxy generating
> >> static relocations are rejected, since --emit-relocs does not produce
> >> any output for the proxies.
> >
> > You lost me here. What do you mean by "proxy generating static relocations"?
> >
>
> Basically, GOT based relocations that result in a GOT entry to be
> emitted when linking a shared object. Since those relocations are
> essentially instructions to the linker to emit such a GOT entry, the
> absolute relocation itself which causes the GOT entry to hold the
> correct value at runtime is not present in the object file, will hence
> not be emitted by --emit-relocs, and so will not have a corresponding
> PE/COFF base relocation emitted for it. This is the reason why we
> currently cannot support such GOT based relocations.

makes sense! Thanks for the clarification.

Thanks,
Achin


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: Relocation fixup during AARCH64 SEC PE-COFF generation?

[Ard Biesheuvel]

On 13 September 2016 at 16:55, Achin Gupta <achin.gupta@arm.com> wrote:
> On Tue, Sep 13, 2016 at 04:25:32PM +0100, Ard Biesheuvel wrote:
>> On 13 September 2016 at 16:16, Achin Gupta <achin.gupta@arm.com> wrote:
>> > On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote:
>> >> On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >> > On 13 September 2016 at 15:03, Achin Gupta <achin.gupta@arm.com> wrote:
>> >> >> Hi All,
>> >> >>
>> >> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
>> >> >> executes directly from within the firmware volume. The FV would typically be
>> >> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
>> >> >> types converts a PE-COFF module into a stripped Terse executable as follows:
>> >> >>
>> >> >> [Rule.AARCH64.SEC]
>> >> >>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
>> >> >>     TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
>> >> >>   }
>> >> >>
>> >> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
>> >> >> when the ELF image is generated. Since the SEC module is able to "XIP" from the
>> >> >> within FV, this means that the relocations have to be fixed up at link time
>> >> >> before the TE image is created.
>> >> >>
>> >> >
>> >> > Correct. GenFv relocates the image based on the runtime address of the
>> >> > firmware volume.
>> >> >
>> >> >> It seems to me that in GenFw.c, at least the static relocations are fixed up
>> >> >> when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
>> >> >> in understanding that dynamic relocations will be left as is in the PE-COFF
>> >> >> image while static relocations will be fixed up?
>> >> >>
>> >> >
>> >> > We usually don't emit dynamic relocations, since we are not linking
>> >> > shared objects.
>> >>
>> >> ... or more specifically, all absolute static relocations are
>> >> converted into PE/COFF base relocations, all relative static
>> >> relocations are validated against the PE/COFF layout (which we keep
>> >> 1:1 identical with the ELF section layout), and all dynamic
>> >> relocations are ignored.
>> >
>> > Thanks Ard. I expect the relative static relocations to be fixed by the PE-COFF
>> > loader at runtime.
>> >
>>
>> No. The PE/COFF loader only processes base relocations, which are
>> essentially pointers into the image where absolute addresses are
>> stored, and which need to have an offset applied based on the
>> difference between the link time base address and the load time base
>> address. Like in ELF, no relative dynamic relocations exist.
>>
>> Only because of the ELF to PE/COFF conversion, we have to ensure that
>> any relative references are still valid after the conversion.
>
> Obviously I am not well versed with the correct terminology :(
>
> I guess we are both talking about the base relocations done in
> PeCoffLoaderRelocateImage() (MdePkg/Library/BasePeCoffLib/BasePeCoff.c) i.e. the
> EFI_IMAGE_REL_BASED_* types defined in EfiImage.h?
>

Correct.

>>
>> >> Note that this implies that proxy generating
>> >> static relocations are rejected, since --emit-relocs does not produce
>> >> any output for the proxies.
>> >
>> > You lost me here. What do you mean by "proxy generating static relocations"?
>> >
>>
>> Basically, GOT based relocations that result in a GOT entry to be
>> emitted when linking a shared object. Since those relocations are
>> essentially instructions to the linker to emit such a GOT entry, the
>> absolute relocation itself which causes the GOT entry to hold the
>> correct value at runtime is not present in the object file, will hence
>> not be emitted by --emit-relocs, and so will not have a corresponding
>> PE/COFF base relocation emitted for it. This is the reason why we
>> currently cannot support such GOT based relocations.
>
> makes sense! Thanks for the clarification.
>

My pleasure,
Ard.