From: Peng Fan <b51431@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section
Date: Wed, 21 Oct 2015 17:42:20 +0800 [thread overview]
Message-ID: <20151021094216.GA29761@shlinux2> (raw)
In-Reply-To: <20151020145910.5e40f8cf@lilith>
Hello Albert,
On Tue, Oct 20, 2015 at 02:59:10PM +0200, Albert ARIBAUD wrote:
>Hello Peng,
>
>On Tue, 20 Oct 2015 15:41:30 +0800, Peng Fan <b51431@freescale.com>
>wrote:
>> Hi Albert,
>>
>> On Tue, Oct 20, 2015 at 09:32:51AM +0200, Albert ARIBAUD wrote:
>> >Hello Peng,
>> >
>> >On Tue, 20 Oct 2015 15:20:43 +0800, Peng Fan <b51431@freescale.com>
>> >wrote:
>> >> Hi Albert,
>> >>
>> >> On Tue, Oct 20, 2015 at 09:05:32AM +0200, Albert ARIBAUD wrote:
>> >> >Hello Peng,
>> >> >
>> >> >On Tue, 20 Oct 2015 13:59:53 +0800, Peng Fan <Peng.Fan@freescale.com>
>> >> >wrote:
>> >> >> The code such as PSCI in section named secure is bundled with
>> >> >> u-boot image, and when bootm, the code will be copied to their
>> >> >> runtime address same to compliation/linking address -
>> >> >> CONFIG_ARMV7_SECURE_BASE.
>> >> >>
>> >> >> When compile the PSCI code and link it into the u-boot image,
>> >> >> there will be relocation entries in .rel.dyn section for PSCI.
>> >> >> Actually, we do not needs these relocation entries.
>> >> >>
>> >> >> If still keep the relocation entries in .rel.dyn section,
>> >> >> r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
>> >> >> address which may not support read/write for one SoC.
>> >> >> 102 /* relative fix: increase location by offset */
>> >> >> 103 add r0, r0, r4
>> >> >> 104 ldr r1, [r0]
>> >> >> 105 add r1, r1, r4
>> >> >> 106 str r1, [r0]
>> >> >>
>> >> >> So discard the relocation entries for code in secure section.
>> >> >
>> >> >Actually, I'll need you to do a slight change -- that's my fault, and
>> >> >karma even ensured that my own self of two years ago would be the one
>> >> >to come and kick me. See:
>> >> >
>> >> >http://lists.denx.de/pipermail/u-boot/2013-December/168652.html
>> >>
>> >> Ok. Then arch/arm/cpu/armv8/u-boot.lds should also have such fix,
>> >> since lots sections are discarded in u-boot.lds for armv8.
>> >
>> >You are correct, armv8 needs to be fixed, as well as zynq (and x86 but
>> >that's outside of my province). Anyway, that's a different problem
>> >which does not need to be addressed in this series.
>> >
>> >> >Which basically is about never discarding any section in the ELF file,
>> >> >and only copying a subset of the ELF sections into the binary file.
>> >> >
>> >> >So rather than discarding the secure relocation records, let's move
>> >> >them to another section as you had proposed, and thus change the line
>> >> >
>> >> >> + /DISCARD/ : { *(.rel._secure*) }
>> >> >
>> >> >Into a
>> >> >
>> >> > .rel._secure { *(.rel._secure*) }
>> >> >
>> >> >Placed right after the already present
>> >> >
>> >> > .dynamic : { *(.dynamic*) }
>> >>
>> >> It can not be placed after .dynamic, since the following is at front.
>> >> 87 .rel.dyn : {
>> >> 88 *(.rel*)
>> >> 89 }
>> >> So relocation entry from secure text will first placed into .rel.dyn section.
>> >>
>> >> If not DISCARD, then I prefer to put ".rel.secure : { *(.rel._secure*) }"
>> >> at line 55 which is wrapped by CONFIG_ARMV7_NONSEC in arch/arm/cpu/u-boot.lds.
>> >
>> >I prefer all 'unused' sections to be kept together near the end of the
>> >LDS file -- I'll add an explicit comment in the LDS about it.
>> >
>> >Besides, there no need to wrap such a section with a preprocessor
>> >conditional, as the linker will simply not emit an output section if
>> >there are no input sections at all for it; IOW, adding the '.rel._secure
>> >{ *(.rel._secure*) }' line will be binary-invariant for platforms which
>> >do not have PSCI or other secure code.
>>
>> But ".rel._secure { *(.rel._secure*) }" can not be placed after
>> ".dynamic : { *(.dynamic*) }". Actually ".rel._secure { *(.rel._secure*) }"
>> should be placed before ".rel_dyn_start" in u-boot.lds, otherwise
>> the secure relocation entries will be placed into ".rel.dyn", but not
>> ".rel._secure".
>
>Hmm, you're correct, the linker will use the first pattern match, not
>the longest or best. :(
>
>But then, the secure reloc input section cannot go in line 55, because
>that's still inside the binary part of the image, which means it will
>waste space in there.
>
>So it's either use DISCARD at the very start of the SECTIONS (round
>line 17) or back to not generating relocatable code at all for PSCI.
I do not know how to generate non-relocatable code only for the secure text.
Since -mword-relocations and -pie are global flags, I do not know how to disable
mword-relocations when compiling PSCI and other secure text.
Is this ok for you?
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 65986e8..fb2128a 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -14,6 +14,7 @@ OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
+ /DISCARD/ : { *(.rel._secure*) }
. = 0x00000000;
. = ALIGN(4);
Regards,
Peng.
>
>> Regards,
>> Peng.
>>
>> >
>> >Amicalement,
>> >--
>> >Albert.
>>
>> --
>
>
>
>Amicalement,
>--
>Albert.
--
next prev parent reply other threads:[~2015-10-21 9:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-20 5:59 [U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section Peng Fan
2015-10-20 5:59 ` [U-Boot] [PATCH V2 2/3] mx7: psci: add basic psci support Peng Fan
2015-10-20 10:50 ` Fabio Estevam
2015-10-20 14:05 ` Li Frank
2015-10-20 14:25 ` Albert ARIBAUD
2015-10-20 14:29 ` Li Frank
[not found] ` <20151020165526.1ae0c332@lilith>
[not found] ` <BY2PR0301MB163850B2C1169D80C249AB2782390@BY2PR0301MB1638.namprd03.prod.outlook.com>
2015-10-20 21:04 ` Albert ARIBAUD
2015-10-20 21:12 ` Li Frank
2015-10-20 5:59 ` [U-Boot] [PATCH V2 3/3] imx: mx7: default enable non-secure mode Peng Fan
2015-10-20 7:05 ` [U-Boot] [PATCH V2 1/3] arm: discard relocation entry for secure section Albert ARIBAUD
2015-10-20 7:20 ` Peng Fan
2015-10-20 7:32 ` Albert ARIBAUD
2015-10-20 7:41 ` Peng Fan
2015-10-20 12:59 ` Albert ARIBAUD
2015-10-21 9:42 ` Peng Fan [this message]
2015-10-21 11:42 ` Albert ARIBAUD
2015-10-21 12:09 ` Peng Fan
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=20151021094216.GA29761@shlinux2 \
--to=b51431@freescale.com \
--cc=u-boot@lists.denx.de \
/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