Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A - TF-A

13 Jan 2020

      Hi
Just to add to this: Given that:
* Your BL31 is nearly 64KB on its own, and
* DDR attacks are more feasible on runtime resident code (e.g. BL31)
Perhaps another more secure solution would be to do DDR init in BL1 or a new transient BL1.5 stage in SRAM. That way you could run BL31 in SRAM, and BL2 and other boot stages in DDR. You would still need to cut down the BL1_RW size though for this to work.
One way to cut down the memory used for page tables is to map all the required memory/devices in larger/fewer address ranges, and align the ranges on block boundaries (i.e. 2MB or 1GB for 4KB translation granules). Although this means mapping in unused address space, which might be less secure, it uses less memory for page tables.
Regards
Dan.
...
-----Original Message-----
From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Soby Mathew
via TF-A
Sent: 13 January 2020 15:13
To: Raghupathy Krishnamurthy raghu.ncstate@icloud.com; "严鸿亮(鸿先)"
hongxian.yhl@alibaba-inc.com; tf-a@lists.trustedfirmware.org
Cc: nd nd@arm.com
Subject: Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A
[Adding back TF-A list]
Hi Raghu
Since the same DRAM is partitioned to run both non-secure and secure software,
it is susceptible to Row Hammer attacks. Also depending on how accessible the
DRAM interface is, the DDR PHY can be probed for transactions. If the DRAM is
removable, then it can be deep frozen to retain values and plugged into
another system to extract contents. Hence the less `secure` comment.
Best Regards
Soby Mathew
From: Raghupathy Krishnamurthy raghu.ncstate@icloud.com
Sent: 13 January 2020 14:36
To: "严鸿亮(鸿先)" hongxian.yhl@alibaba-inc.com
Cc: Soby Mathew Soby.Mathew@arm.com; Xie, Shaolin <shaolin.xie@alibaba-
inc.com>; nd nd@arm.com
Subject: Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A
Hi Soby,
...
...
It is possible to create a secure carve-out in DDR and execute BL31
from there. It is less `secure` than running from SRAM but it is
acceptable for some market segments depending on the threat model.
Can you elaborate on why you say it is less "secure" to run out of DDR?
-Raghu
On January 13, 2020 at 4:36 AM, "严鸿亮(鸿先) via TF-A" <tf-
a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> wrote:
Hi Soby,
Many thanks for your advice. I will try to RUN BL2 as Boot ROM and try to
reduce the BL31 size. Hope BL2_NOPROGBITS+BL31 can be restricted below 64KB.
Wish me good luck:).
Best Regards
Yan Hongliang

发件人：Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com>
发送时间：2020年1月13日(星期一) 19:37
收件人：严鸿亮(鸿先) <hongxian.yhl@alibaba-inc.commailto:hongxian.yhl@alibaba-
inc.com>; "Xie, Shaolin" <shaolin.xie@alibaba-
inc.commailto:shaolin.xie@alibaba-inc.com>; tf-
a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-
a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>
抄　送：nd <nd@arm.commailto:nd@arm.com>; Ash Wilding
<Ash.Wilding@arm.commailto:Ash.Wilding@arm.com>
主　题：RE: 回复：[TF-A] MMU Table in ARM Trust-Firmware-A
Hi Yan,
OK, sounds good. From your description of the platform, having BL2 as the
Boot ROM is worth exploring. This way, you avoid the BL1_RW , BL2_PROGBITS
memory overhead. BL2_NOPROGBITS will need to be in SRAM. See the BL2_AT_EL3
and BL2_IN_XIP_MEM build flags for details. This depends on BL31 being able
to fit in the free space available after this is done. One option is using
the RECLAIM_INIT_CODE option which reclaims BL31 init-only code for runtime
data but it needs platform specific linker script support. There are other
ways to reduce the BL31 size, but trading security like
SEPARATE_CODE_AND_RODATA=0 or trading performance like USE_COHERENT_MEM=0.
Hope that helps.
Best Regards
Soby Mathew
From: 严鸿亮(鸿先) <hongxian.yhl@alibaba-inc.commailto:hongxian.yhl@alibaba-
inc.com>
Sent: 11 January 2020 06:04
To: Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com>; Xie,
Shaolin <shaolin.xie@alibaba-inc.commailto:shaolin.xie@alibaba-inc.com>;
tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org
Cc: nd <nd@arm.commailto:nd@arm.com>; Ash Wilding
<Ash.Wilding@arm.commailto:Ash.Wilding@arm.com>
Subject: 回复：[TF-A] MMU Table in ARM Trust-Firmware-A Hi Soby, Thanks for
your replies.
Currently, out BL2 size is 60KB, BL1_RW is 28KB, BL31_PROGBITS is 48KB,
BL31_NOPROGBITS is 24KB. For our testchip, we don't have too strictly
security requirement, so maybe putting BL31 into DDR is a way to save SRAM
and we don't need to worry about PROGBITS limit between BL31 and BL2.
For BL1_RW and BL2, there is 40KB used for MMU table. After I disable the MMU
related code in arm_bl1_plat_arch_setup()/arm_bl2_plat_arch_setup() and also
disable the build of xlat_table_lib, this 40KB space is saved. If the
consequence is decreasing performance and losing MMU protection without any
other functionality problem, then we might try this.
Best Regards
Yan Hongliang

发件人：Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com>
发送时间：2020年1月10日(星期五) 18:27
收件人："Xie, Shaolin" <shaolin.xie@alibaba-
inc.commailto:shaolin.xie@alibaba-inc.com>; tf-
a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-
a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>
抄　送：nd <nd@arm.commailto:nd@arm.com>; 严鸿亮(鸿先) <hongxian.yhl@alibaba-
inc.commailto:hongxian.yhl@alibaba-inc.com>; Ash Wilding
<Ash.Wilding@arm.commailto:Ash.Wilding@arm.com>
主　题：Re: [TF-A] MMU Table in ARM Trust-Firmware-A
On 10/01/2020 09:05, shaolin.xie via TF-A wrote:
...
Hey all:
We are trying to port ARM Trust-Firmware-A to our design, however, we are
facing serious SRAM size problem.
...
Our target SRAM is 64KB, but the compiled BL2 already taken 60K:
After some evaluation, we found that the MMU table take most of the space.
Our questions are:
Hi Shaolin,
There are some options to reduce the memory used for page-tables like using
non-identity virtual to physical mappings. But given your SRAM size, I
suspect you may not save enough to fit BL31.
...

Can we disable the MMU so we can fit the BL2 into 64KB space?

(However, in ARM's porting guide, enable MMU and icache/dcache is
mandatory. Refer to chapter 7.3 in
https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/por
ting-guide.html#introduction
https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/po
rting-guide.html#introduction.）
This is a possibility although not recommended for performance reasons and
you lose the protection of MMU during BL2 execution. This is not a
configuration we support an I suspect some changes to BL2 code may be
required for this.
...

In current design, BL31 is run in SRAM. If we enable DDR in BL2 and load

BL31 image to DDR, is there any potential issue?
...
Thanks in advances,
It is possible to create a secure carve-out in DDR and execute BL31 from
there. It is less `secure` than running from SRAM but it is acceptable for
some market segments depending on the threat model.
You target SRAM of 64 KB is on the lower side and fitting both BL2 and
BL31 in that space could be a challenge.
Could you let us know your BL2 and BL31 size and could you break down the
size in terms of PROGBITS and NOPROG BITS? The BL31 NOPROG BITS are usually
overlayed on top of BL2 memory and this will let us know whether fitting both
in SRAM is even possible. If both cannot fit together in SRAM, there are
other options you can explore like loading BL31 directly from BootROM or
using BL2 as an XIP BootROM image.
Best Regards
Soby Mathew
--
TF-A mailing list
TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
TF-A mailing list
TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
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.