- TF-A - lists.trustedfirmware.org

by Madhukar Pappireddy

Hi, We have upgraded Trusted Firmware-A CI to use the GCC toolchain version 9.2.-2019.12 publicly available through developer.arm.com [1]. The relevant documentation has been updated [2] to reflect the use of these cross compilers. We request the platform maintainers to update their respective platform documentation ( trusted-firmware-a/docs/plat/*.rst) as needed. AArch32 bare-metal target (arm-none-eabi) AArch64 ELF bare-metal target (aarch64-none-elf) [1] https://developer.arm.com/tools-and-software/open-source-software/developer… [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=f35e… Thanks, Madhukar

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Regards, Sandrine

6 years, 1 month

2
1
0 0

Re: [TF-A] Who better implements a safe environment: cortex-M or cortex-A?

by Joanna Farley

Hi Iñigo, We needs a little bit more information to know how best to answer your question. Is this just an academic question of is there a real use case you are trying to decide on which way to go? Its not so much a question of which architecture is easier its just that they are different with Cortex-M powering the most energy-efficient embedded devices where as Cortex-A is offering supreme performance at optimal power. Each architecture offers different hardware constraints and the secure TrustZone is implemented to handle each and an ecosystem of solutions surrounds each. If this is an academic question I would refer you to Arm's pages on TrustZone as a starting point: https://www.arm.com/why-arm/technologies/trustzone-for-cortex-m https://www.arm.com/why-arm/technologies/trustzone-for-cortex-a If there is need for guidance on a specific solution or difficulties you are trying to overcome while building a solution please give us some more details. Thanks Joanna On 22/01/2020, 08:07, "TF-A on behalf of Iñigo Vicente Waliño via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Can someone explain to me why it is easier to implement a secure TrustZone environment with secure boot and storage and PSA certificate in cortex-M than in cortex-A? Who better implements a safe environment: cortex-M or cortex-A? Why? Thanks. -- TF-A mailing list TF-A(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.

6 years, 1 month

1
0
0 0

Who better implements a safe environment: cortex-M or cortex-A?

by Iñigo Vicente Waliño

Hi, Can someone explain to me why it is easier to implement a secure TrustZone environment with secure boot and storage and PSA certificate in cortex-M than in cortex-A? Who better implements a safe environment: cortex-M or cortex-A? Why? Thanks.

6 years, 1 month

1
0
0 0

Please revert "Remove RSA PKCS#1 v1.5 support from cert_tool"

by Scott Branden

Please revert the removal of RSA PKCS#1 v1.5 support from cert_tool: https://github.com/ARM-software/arm-trusted-firmware/commit/6a415a508ea6ace… We have products shipping with such support. I think this problem came up before when somebody tried removing such support. They still need to run with the latest yocto codebase. Regards, Scott

6 years, 1 month

1
0
0 0

Re: [TF-A] Gerrit review latency

by Joanna Farley

Hi Varun, It can be a challenge to keep on top of the reviews and we are aware of the backlog increase after the end of year break and trying different approaches to get reviews completed. Any suggestions on process improvements from the developer community at large are welcome. Cheers Joanna On 16/01/2020, 17:34, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hello, We (NVIDIA) frequently post changes on the TF-A gerrit dashboard and wait for the maintainers to gradually get to them. This is very time consuming and non-deterministic. Curious to know if other developers face the same problems or are we missing something when asking for reviews? If most of us face the same problems, then we should try to formulate a process to reduce the latency. Thoughts? -Varun ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -- TF-A mailing list TF-A(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.

6 years, 1 month

2
1
0 0

Gerrit review latency

by Varun Wadekar

Hello, We (NVIDIA) frequently post changes on the TF-A gerrit dashboard and wait for the maintainers to gradually get to them. This is very time consuming and non-deterministic. Curious to know if other developers face the same problems or are we missing something when asking for reviews? If most of us face the same problems, then we should try to formulate a process to reduce the latency. Thoughts? -Varun ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

6 years, 1 month

1
0
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Soby Mathew

On 13/12/2019 22:04, Julius Werner via TF-A wrote: > On Fri, Dec 13, 2019 at 6:20 AM Joanna Farley <Joanna.Farley(a)arm.com> wrote: >> On the subject of DebugFS's purpose it was envisages and is today as Sandrine describes as a debug build only capability. Saying that though there has been some early thoughts that it could evolve into a Secure Debug feature where this type of capability or something like it is always on requiring debug certificates for authenticated access. This is something very much for a possible future evolution and is not in the patches available today. We would welcome any thoughts on such an evolution in this space. > > I guess this gets into a bit of a philosophy discussion and becomes a > matter of opinion, so there's probably no one right answer. > Personally, adding authentication on top of this doesn't really > resolve my concerns and adds yet more on top. I'm a strong proponent > of the concept of a minimal Trusted Computing Base, i.e. keeping the > amount of code executing at the highest privilege level as small and > low-complexity as possible. Any code can have bugs, so the idea is > that the more complicated the code you run in EL3 is (and the more > complicated APIs it exposes), the more likely it becomes that you > accidentally have an exploitable vulnerability in there. Like a p9 > filesystem driver, a certificate-based authentication system > (especially if it's based on x509/ASN.1 which are notoriously hard to > implement safely) is a pretty complex piece of code with a pretty > large attack surface that I'd rather not have in my EL3 firmware if I > can avoid it. I understand that for certain use cases you may need > something like this (if you really want a very extensive and > extensible debugging API that must be restricted to a few > authenticated actors), but in my use case I really just need the > ability to trigger one small debugging feature and that feature itself > doesn't need to be restricted, so a minimal SMC interface would work > much better for that case. Hi Julius, Just to trying to understand, if TF-A were to expose a crash inducing SMC, this would still be restricted to special builds for your test runs ? This would not make it to production for Chromebook right ? I agree 9p filesystem is not desirable in a EL3 runtime firmware. We could enhance it to use a more tight data structure, if there is a desire in that direction. If that is the case, leaving aside the 9p filesystem issues, can DebugFS serve this requirement (we can remove the limitation that it is restricted to only Debug builds) ? The intention that DebugFS can prove useful atleast in the verification/testing space and if there is more we can do to get there, it would be good to know. > >> On 13/12/2019, 13:01, "TF-A on behalf of Sandrine Bailleux via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: >> Going back to the SMC-based solution then, I am not quite convinced >> SYSTEM_RESET2 is the right interface for intentionally triggering a >> panic in TF-A. I think the semantics do not quite match. If anything, a >> firmware crash seems more like a shutdown operation to me rather than a >> reset (we don't recover from a firmware crash). I am not even sure we >> should look into the PSCI SMC range, as it's not a power-management >> operation. > > Crash recovery behavior is platform dependent (via > plat_panic_handler()). On all the platforms we use in Chrome OS we > have that implemented as a system reboot. I think for most systems > (whether it's a Chromebook, a server or some embedded device) that's > probably what you want for random runtime crashes (and least in a > production environment), but I agree that TF doesn't enforce any > standard behavior so it's hard to clearly match it to one or the other > SMC. > >> So it sounds like it's not the first time that you hit this issue, is >> it? Do you have any other example of Normal World OS feature you would >> have liked to expose through a generic SMC interface? I am wondering >> whether this could help choosing the right SMC range, if we can identify >> some common criteria among a set of such features. > > No, it's the first time I've really run into this. But I think we > might quickly come up with more uses for a "non-secure OS" SMC range > if we had one. We often see roughly the same SMC again on different > platforms, because fundamentally they usually need to do the same > kinds of things -- for example, most platforms have some kind of DDR > frequency scaling which always needs part of it implemented in EL3, so > they all need some kind of SMC to switch to a new DDR frequency. Many > also need some kind of "write value to secure register" SMC that just > allows the non-secure OS to write a few whitelisted registers that are > only accessible in EL3 for some reason. If we could standardize these > interfaces in a non-vendor-specific SMC range, we might be able to > reduce some code duplication both on the TF and the Linux side. > > I guess none of these things are really Linux-specific, now that I > think of it. So really, I guess the problem is that it would be great > to have a range of "generic" SMC IDs that can be easily and > unbureaucratically allocated to try out new features, without having > to ask Arm to write a big specification document about it every time. > It's sort of a development velocity issue. > We have utilized the ARM SiP range for some "generic" purposes in the past (see PMF and the execution state switch SMCs). This could be direction for the some of use-cases. But if the SMCs are meant to be truly generic and to be relied on for use by generic normal world software components, it would need to be properly specified I would think. For dynamically modifying some EL3 registers, it would be good to get these requirements out. Perhaps there is scope for architecting some of them as an ARM specification. If not, we could revert to a TF-A standard if there is enough pull for them (perhaps utilizing the ARM SiP range). Best Regards Soby Mathew

6 years, 1 month

2
1
0 0

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

by Dan Handley

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(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew > via TF-A > Sent: 13 January 2020 15:13 > To: Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com>; "严鸿亮(鸿先)" > <hongxian.yhl(a)alibaba-inc.com>; tf-a(a)lists.trustedfirmware.org > Cc: nd <nd(a)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(a)icloud.com> > Sent: 13 January 2020 14:36 > To: "严鸿亮(鸿先)" <hongxian.yhl(a)alibaba-inc.com> > Cc: Soby Mathew <Soby.Mathew(a)arm.com>; Xie, Shaolin <shaolin.xie@alibaba- > inc.com>; nd <nd(a)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(a)lists.trustedfirmware.org<mailto: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(a)arm.com<mailto:Soby.Mathew@arm.com>> > 发送时间：2020年1月13日(星期一) 19:37 > 收件人：严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba- > inc.com>>; "Xie, Shaolin" <shaolin.xie@alibaba- > inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding > <Ash.Wilding(a)arm.com<mailto: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(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba- > inc.com>> > Sent: 11 January 2020 06:04 > To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Xie, > Shaolin <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; > tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding > <Ash.Wilding(a)arm.com<mailto: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(a)arm.com<mailto:Soby.Mathew@arm.com>> > 发送时间：2020年1月10日(星期五) 18:27 > 收件人："Xie, Shaolin" <shaolin.xie@alibaba- > inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; 严鸿亮(鸿先) <hongxian.yhl@alibaba- > inc.com<mailto:hongxian.yhl@alibaba-inc.com>>; Ash Wilding > <Ash.Wilding(a)arm.com<mailto: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. > > > > > 1. 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. > > > > > 2. 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(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(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.

6 years, 1 month

1
0
0 0

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

by Soby Mathew

[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(a)icloud.com> Sent: 13 January 2020 14:36 To: "严鸿亮(鸿先)" <hongxian.yhl(a)alibaba-inc.com> Cc: Soby Mathew <Soby.Mathew(a)arm.com>; Xie, Shaolin <shaolin.xie(a)alibaba-inc.com>; nd <nd(a)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(a)lists.trustedfirmware.org<mailto: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(a)arm.com<mailto:Soby.Mathew@arm.com>> 发送时间：2020年1月13日(星期一) 19:37 收件人：严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba-inc.com>>; "Xie, Shaolin" <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding <Ash.Wilding(a)arm.com<mailto: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(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba-inc.com>> Sent: 11 January 2020 06:04 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Xie, Shaolin <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding <Ash.Wilding(a)arm.com<mailto: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(a)arm.com<mailto:Soby.Mathew@arm.com>> 发送时间：2020年1月10日(星期五) 18:27 收件人："Xie, Shaolin" <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; 严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba-inc.com>>; Ash Wilding <Ash.Wilding(a)arm.com<mailto: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. > > 1. 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/porting-… <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-…>.） 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. > > 2. 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(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

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

by Soby Mathew

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. > > 1. 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/porting-… <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-…>.） 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. > > 2. 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

6 years, 1 month

2
3
0 0

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

by Marek

Another option to BL31 in system memory (DDR) is, which we are exploring, is loading an image (in our case BL33/Uboot) to system caches (inner L1/L2 & outer LLC/L3 which ever) and initialize the DDR from within it. This is not trivial though but working successfully with us for Cortex-A15, A53 and A57 with CCN (Cache Coherent Network 504 and 512) featuring the Last Level Cache on three of our SoCs. Marek On Fri, 10 Jan 2020 at 11:12, Soby Mathew via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > 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. > > > > > 1. 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/porting-… > < > https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… > >.） > > 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. > > > > > 2. 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(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- Slán, Marek

6 years, 2 months

1
0
0 0

MMU Table in ARM Trust-Firmware-A

by shaolin.xie

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: 1. 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/porting-… <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-…>.） 2. 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,

6 years, 2 months

1
1
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Matteo Carlini

Back on-list. > One more question, the operation of TrustZone is the same in the armv7-A and Armv8-A architectures, right? Not exactly…for a description about TZ differences between the Armv7-A and Armv8-A architecture please have a look at this presentation: https://www.youtube.com/watch?v=q32BEMMxmfw https://www.slideshare.net/linaroorg/arm-trusted-firmareforarmv8alcu13 As a reference, all public talks and presentations on TF-A over the years are listed here: https://developer.trustedfirmware.org/w/tf_a/ Thanks Matteo > From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> > Sent: 09 January 2020 11:21 > To: Matteo Carlini <Matteo.Carlini(a)arm.com> > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > One more question, the operation of TrustZone is the same in the armv7-A and Armv8-A architectures, right? > Thanks for your answers, > Iñigo.

6 years, 2 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Matteo Carlini

Another option is to look at the 96boards platforms: https://www.96boards.org/product/developerbox/ (that's supported upstream by TF-A https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/socio… ) and the Secure96 mezzanine board https://www.96boards.org/product/secure96/ https://www.96boards.org/blog/getting-started-with-the-secure96-tpm/ but the boot flow with TF-A and this mezzanine board hasn't been officially proved. Ard and Stuart (cc-ed) have done some investigations and experiment in this direction and might add something. Thanks Matteo > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > Handley via TF-A > Sent: 09 January 2020 09:56 > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > (Back on the list) > > Sorry Iñigo, I don't know enough about the hw capabilities of Raspberry Pi > and its boot flow to be able to help you further. Olivier gave some more > pointers. > > Dan. > > > From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> > Sent: 09 January 2020 07:42 > To: Dan Handley <Dan.Handley(a)arm.com> > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Yes, thank you very much. > > Then, what I'm trying to say is that if I want a secure boot, I need a trust root. > If Raspberry Pi cannot provide that trusted root, can I use a TPM? > > Iñigo > > El mié., 8 ene. 2020 a las 16:32, Dan Handley via TF-A (<tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) > escribió: > (Back on the list) > > By rpi I guess you mean Raspberry Pi? > > > How do we ensure that the ROM is safe? > I'm not sure what you mean by "safe". By definition the ROM is non- > modifiable but maybe you also want it to be non-readable by normal world > software? > > Although Raspberry Pi contains CPUs that implement TrustZone, I believe > there is no TrustZone Controller IP policing access to memory so there is > nothing preventing normal world software from accessing memory that is > mapped in as secure. Perhaps that is what you mean by "rpi does not provide > security"? I also don't know what you mean by "a TPM does not work". > > Dan. > > From: Iñigo Vicente Waliño > <inigovicentewalino(a)gmail.com<mailto:inigovicentewalino@gmail.com>> > Sent: 08 January 2020 14:54 > To: Dan Handley <Dan.Handley(a)arm.com<mailto:Dan.Handley@arm.com>> > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Assuming that BL1 is used and implemented in ROM, for example, with an rpi. > How do we ensure that the ROM is safe? He sought that rpi does not provide > security and that a TPM does not work. Why? > > Thanks. > > El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf- > a(a)lists.trustedfirmware.org<mailto:tf- > a(a)lists.trustedfirmware.org><mailto:tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>>) > escribió: > Hi Inigo > > TrustZone is a trademark referring to the security extensions of the Arm > architecture. That is separate to BL1, which is the first boot stage of Trusted > Firmware-A (or some other equivalent boot firmware). The expectation is > that BL1, if used, is implemented in ROM to provide the Root of Trust for the > Application Processor (AP). > > An alternative flow is for a separate "security processor" to authenticate the > AP firmware before the AP is released from reset. In such a flow, there is no > need for BL1 and BL2 since that functionality is provided by the security > processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see > in-source documentation). > > A TPM can provide additional security by storing secrets not even visible to > TrustZone software (e.g. root keys or boot measurements). However, TPMs > typically don't do firmware authentication on their own; some other > software will need to use the secrets it stores, e.g. boot firmware may ask > the TPM verify a signature corresponding to the next boot stage. > > > If the TPM is changed to another, is the boot performed? > That depends on your system design. > > Dan. > > > -----Original Message----- > > From: TF-A > > <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trus > > tedfirmware.org><mailto:tf-a-bounces@lists.trustedfirmware.org<mailto: > > tf-a-bounces(a)lists.trustedfirmware.org>>> On Behalf Of Iñigo Vicente > > Waliño via TF-A > > Sent: 08 January 2020 10:33 > > To: > > tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>< > > mailto:tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmwar > > e.org>> > > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > > > Hi, > > > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used > as > > a trusted root or is it useless? > > If the TPM is changed to another, is the boot performed? > > > > Thanks, > > Inigo. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>< > > mailto:TF-A@lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmwar > > e.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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF- > A(a)lists.trustedfirmware.org><mailto:TF- > A(a)lists.trustedfirmware.org<mailto: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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto: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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 2 months

2
1
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Dan Handley

(Back on the list) Sorry Iñigo, I don't know enough about the hw capabilities of Raspberry Pi and its boot flow to be able to help you further. Olivier gave some more pointers. Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> Sent: 09 January 2020 07:42 To: Dan Handley <Dan.Handley(a)arm.com> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Yes, thank you very much. Then, what I'm trying to say is that if I want a secure boot, I need a trust root. If Raspberry Pi cannot provide that trusted root, can I use a TPM? Iñigo El mié., 8 ene. 2020 a las 16:32, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) escribió: (Back on the list) By rpi I guess you mean Raspberry Pi? > How do we ensure that the ROM is safe? I'm not sure what you mean by "safe". By definition the ROM is non-modifiable but maybe you also want it to be non-readable by normal world software? Although Raspberry Pi contains CPUs that implement TrustZone, I believe there is no TrustZone Controller IP policing access to memory so there is nothing preventing normal world software from accessing memory that is mapped in as secure. Perhaps that is what you mean by "rpi does not provide security"? I also don't know what you mean by "a TPM does not work". Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com<mailto:inigovicentewalino@gmail.com>> Sent: 08 January 2020 14:54 To: Dan Handley <Dan.Handley(a)arm.com<mailto:Dan.Handley@arm.com>> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Assuming that BL1 is used and implemented in ROM, for example, with an rpi. How do we ensure that the ROM is safe? He sought that rpi does not provide security and that a TPM does not work. Why? Thanks. El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org><mailto:tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>>) escribió: Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org><mailto:tf-a-bounces@lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>>> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org><mailto:tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org><mailto:TF-A@lists.trustedfirmware.org<mailto: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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org><mailto:TF-A@lists.trustedfirmware.org<mailto: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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto: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.

6 years, 2 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Olivier Deprez

Hi, To add to Dan's observation about rpi lacking TZ memory controller: Notice the first subsystem to boot on BCM SoC is the VideoCore (which itself releases ARM cores resets). Thus, there are early boot stages running even before TF-A gets handed over. So it needs trusting the VC ROM and VC bootloader (residing on SD card, or EEPROM from rpi4). As to whether those early components get verified by the BCM chip, this is not documented publicly AFAIK. I extrapolate "TPM does not work" means the "public rpi" is good for prototyping TZ and/or a TPM solution. Although it is eventually not directly usable as a production platform for such use cases. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 08 January 2020 16:32 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? (Back on the list) By rpi I guess you mean Raspberry Pi? > How do we ensure that the ROM is safe? I'm not sure what you mean by "safe". By definition the ROM is non-modifiable but maybe you also want it to be non-readable by normal world software? Although Raspberry Pi contains CPUs that implement TrustZone, I believe there is no TrustZone Controller IP policing access to memory so there is nothing preventing normal world software from accessing memory that is mapped in as secure. Perhaps that is what you mean by "rpi does not provide security"? I also don't know what you mean by "a TPM does not work". Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> Sent: 08 January 2020 14:54 To: Dan Handley <Dan.Handley(a)arm.com> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Assuming that BL1 is used and implemented in ROM, for example, with an rpi. How do we ensure that the ROM is safe? He sought that rpi does not provide security and that a TPM does not work. Why? Thanks. El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) escribió: Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto: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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto: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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 2 months

1
0
0 0

Updates to the Change Log process

by Lauren Wehrmeister

Hi, We are intending to move the updates to the change log from completely release based to more rolling updates. I have created a new change log file in the docs directory (change-log-upcoming.rst) for changes that need to be included for the upcoming release: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3081. The intention is for individual developers to update the document with the relevant patch as the code change is being made. The usual change log document (docs/change-log.rst) will be updated at release time to include all changes for each release. Thanks, Lauren

6 years, 2 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Dan Handley

(Back on the list) By rpi I guess you mean Raspberry Pi? > How do we ensure that the ROM is safe? I'm not sure what you mean by "safe". By definition the ROM is non-modifiable but maybe you also want it to be non-readable by normal world software? Although Raspberry Pi contains CPUs that implement TrustZone, I believe there is no TrustZone Controller IP policing access to memory so there is nothing preventing normal world software from accessing memory that is mapped in as secure. Perhaps that is what you mean by "rpi does not provide security"? I also don't know what you mean by "a TPM does not work". Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> Sent: 08 January 2020 14:54 To: Dan Handley <Dan.Handley(a)arm.com> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Assuming that BL1 is used and implemented in ROM, for example, with an rpi. How do we ensure that the ROM is safe? He sought that rpi does not provide security and that a TPM does not work. Why? Thanks. El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) escribió: Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto: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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto: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.

6 years, 2 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Dan Handley

Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > TF-A mailing list > TF-A(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.

6 years, 2 months

1
0
0 0

Does ARMv8 TrustZone provide a secure ROM?

by Iñigo Vicente Waliño

Hi, Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a trusted root or is it useless? If the TPM is changed to another, is the boot performed? Thanks, Inigo.

6 years, 2 months

1
0
0 0

(no subject)

by Iñigo Vicente Waliño

Hi, Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a trusted root or is it useless? If the TPM is changed to another, is the boot performed? Thanks, Inigo.

6 years, 2 months

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hi Sumit, On 1/8/20 7:09 AM, Sumit Garg via TF-A wrote: > Hi Sandrine, > > On Fri, 20 Dec 2019 at 12:29, Sumit Garg <sumit.garg(a)linaro.org> wrote: >> >> Hi Sandrine, >> >> On Wed, 18 Dec 2019 at 21:07, Sandrine Bailleux >> <Sandrine.Bailleux(a)arm.com> wrote: >>> >>> Hi Sumit, >>> >>> I've started providing some early review comments on your patches in >>> Gerrit but these are mainly about implementation details. I would like >>> to continue the higher-level design discussions here in parallel on the >>> mailing list, if that's fine with you. >>> >> >> Yes that's perfectly fine with me. >> > > Do you have any further comments? As I have already incorporated most > of the your comments related to design and implementation details in > latest v4 patch-set [1]. > > [1] https://review.trustedfirmware.org/q/topic:%22tbbr%252Ffw_enc%22+(status:op… Apologies, with the Christmas break, I haven't had a chance to look at your patches again. I will allocate some time for it this week and get back to you. Regards, Sandrine

6 years, 2 months

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hi Sumit, I've started providing some early review comments on your patches in Gerrit but these are mainly about implementation details. I would like to continue the higher-level design discussions here in parallel on the mailing list, if that's fine with you. On 12/6/19 1:29 PM, Sumit Garg via TF-A wrote: > Hi Sandrine, > > On Thu, 5 Dec 2019 at 20:31, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: >>>> Also, I am still trying to get my head around how this would integrate >>>> with a cryptographic engine where the key does not leave the chip. I can >>>> imagine that we could get the address of the encrypted firmware image >>>> from the FIP, pass that to a cryptographic engine, request it to decrypt >>>> it and store the result somewhere in Trusted RAM. In this case, we >>>> wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we >>>> would pull this off? Like how the different modules (IO layer, crypto >>>> module, image parser module, ...) would integrate together? >>> >>> In this case, I would expect platform to provide key identifier rather >>> than actual key as part of plat_get_fip_encryption_key() which is then >>> passed onto auth_decrypt() that is implementation specific to >>> cryptographic engine in similar terms as currently done for mbedTLS >>> backend. >> >> Ah I see, so plat_get_fip_encryption_key() could return either the key >> itself or a key identifier. Just like plat_get_rotpk_info() can return >> either the key or a hash of it today. However, in the case of >> plat_get_rotpk_info(), it also returns some flags indicating which one >> it is. Don't we need something similar for >> plat_get_fip_encryption_key()? How will the crypto module be able to >> tell the difference between a key and a key ID otherwise? Or would you >> expect a given crypto module backend to always use either keys or key >> IDs, but not both? >> > > It perfectly makes sense for crypto module backend to support both key > ID and actual key. But I was thinking from use-case perspective that > why would one like to expose key to the firmware if the crypto module > could better protect it. And I could come up with one use-case where > the SSK (burnt in SoC fuses) is provided as an actual key and BSSK > (accessible only to crypto module) is provided via a key ID. Yes, that makes sense to me. > So yes I agree with you to provide additional flags field along with > key buffer. Also, I think it makes sense to rename > "plat_get_fip_encryption_key()" to "plat_get_fip_enc_key_info()". Agree. >>>> I have some concerns around the generation of the initialization vectors >>>> in the encrypt_fw tool. Right now, IVs are simply a random sequence of >>>> bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I >>>> would imagine that RAND_bytes() is typically based on a good random >>>> number generator and thus will generate different sequences every time >>>> it is called. At least, as long as it is called from the same machine >>>> every time. But what if we encrypt a new FIP bundle from a different >>>> machine, say in the context of a firmware update? Is it not possible >>>> that it might choose the same IV out of bad luck? >>>> >>>> Perhaps that's an issue left to provisioning/manufacturing time and is >>>> out of the scope here. But it worries me because AFAIU, the security of >>>> AES-GCM is critically undermined if the same nonce is used multiple >>>> times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). >>>> If the encryption key is the SSK (rather than the BSSK) then I guess the >>>> probability is even higher, as it is shared amongst a class of devices. >>>> >>> >>> Agree that "nonce" should be unique and using a random number >>> generator available on build machine was an effort towards that. But >>> thinking about the case that you have mentioned, I think we could have >>> an optional user provided "nonce" as an input to "encrypt_fw" tool, so >>> that the user is aware to randomly generate and provide a unique >>> nonce. >> >> Yes, I like your suggestion of specifying the nonce to the tool. But I >> think it should be the default behaviour then. You mention an *optional* >> user-provided nonce, I would like to suggest we make this mandatory >> instead. We could provide an option to request the tool to generate the >> nonce, intended for development purposes. >> > > Making nonce as default and mandatory command line option seems to be > overkill for a user. It may also lead to unsafe practices of > hardcoding a nonce in Makefile, shell scripts etc. So I think we > should keep this as optional only for a narrow use-case where people > might not trust uniqueness property of RNG from multiple build > machines. I don't know... Hard-coding a nonce in the makefile is unsafe for sure but I would think that a nonce generated by the tool is also unsafe without proper management of these nonces across keys and devices, but in a much more subtle manner. I still think the nonce generation would be better left outside of the scope of this tool. > BTW, I have already added nonce command line option as part of v3 > patch-set [1]. Please have a look. > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496/2..3 > >>>> Impact on memory footprint and performance >>>> ------------------------------------------ >>>> >>>> Do you know what the performance impact is when this feature is enabled >>>> in TF-A, to decrypt images at boot time? Obviously it depends on the >>>> platform and whether there is a dedicated cryptographic engine, and I >>>> suppose you cannot really get any relevant measurements out of QEMU but >>>> I would be interested if you've got any rough numbers. >>> >>> Following are measurements based on qemu for mbedTLS software library >>> based authenticated decryption: >>> >>> BL31 plain: >>> NOTICE: Load image time: 137us, size: 28KB >>> BL31 encrypted: >>> NOTICE: Load image time: 3979us, size: 28KB >>> >>> BL32 plain: >>> NOTICE: Load image time: 1791us, size: 360KB >>> BL32 encrypted: >>> NOTICE: Load image time: 36339us, size: 360KB >> >> Thanks. So it's a 29% increase for BL31 and 20% for BL32. I would have >> naively expected similar percentages, any idea why we get such a >> difference between BL31 and BL32? I am just curious. Maybe it's down to >> how the crypto algorithm/mode of operation works under the hood? > > Yes this additional increase for BL31 seems to be due to one time > initialization operations carried on first invocation of mbedTLS gcm > APIs, especially time taken to generate AES tables (see call to > aes_gen_tables() in mbedtls/library/aes.c +576). Ah I see, thanks for the explanation. Regarding the memory impact, given that it's adding quite a bit of code and data (around 9KB for BL1 and 12KB for BL2 from what you were saying in a previous email), I think we need to make this feature optional and wrap it under a build flag. Not everyone will need to encrypt firmware images, having only authentication is a valid use case as well. If I am not mistaken, your patches right now unconditionally pull the mbedTLS primitives into BL1 and BL2 (as long as TBBR is enabled of course). As a matter of fact, I am not able to build BL1 on FVP platform with your patches, presumably due to the unconditional size increase. The following build command: > make TRUSTED_BOARD_BOOT=1 ARM_ROTPK_LOCATION=devel_rsa MBEDTLS_DIR=mbedtls bl1 ... fails at link time: aarch64-linux-gnu-ld.bfd: build/fvp/release/bl1/bl1.elf section `xlat_table' will not fit in region `RAM' aarch64-linux-gnu-ld.bfd: BL1's RW section has exceeded its limit. aarch64-linux-gnu-ld.bfd: region `RAM' overflowed by 4096 bytes Makefile:889: recipe for target 'build/fvp/release/bl1/bl1.elf' failed Regards, Sandrine

6 years, 2 months

2
2
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Dan Handley

Hi > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew > via TF-A > Sent: 06 January 2020 12:34 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org; > Sheetal Tigadoli <sheetal.tigadoli(a)broadcom.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-A] [Question] Why are the log related macros defined in > multiple of 10's > > > Hi All, > > > > I wanted to understand the reason behind defining LOG_LEVEL_* macros > > as multiple of 10's, also same goes with LOG_MARKER_* macros. > > If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and > > division operation when printing the msgs to console. > > > > Please let me your thoughts on this. > > > > Link to this question on Phabricator - > > https://developer.trustedfirmware.org/T624 > > > > Thanks > > Sheetal > As Sandrine said in Phabricator, the reason was simply to leave space between the levels to allow adding intermediate levels without breaking compatibility. Compatibility was a possible concern if external tools used the log level and you only rebuilt some of the TF-A components (components could end up using different values). However, I suspect the actual level value is never emitted in practice (just the text prefix) so this may not be a real concern. > Hi Sheetal > I didn't quite get reason for the optimization from multiples of 10 to > consecutive numbers. The mod operation you refer to are assertions which will > be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that > there is a single divide by 10 operation within the default implementation of > plat_log_get_prefix(). > > > If the logging utility is considered performance critical, removing the > single divide by 10 will not result in any gain. Usually the bottleneck for > logs are UART baudrates and the CPU spends most of time spinning in a wait > loop for UART to be free. Hence I don't see any need for change for log > levels macro if the intent is performance optimization. > +1. Unless there's an actual performance gain, this sounds like an unnecessary change. Dan. 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.

6 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A