- TF-A - lists.trustedfirmware.org

Cancelled event: TF-A Tech Forum @ Thu 31 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 31 Dec 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 3 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 3 Dec 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years

1
0
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Achin Gupta

Hi Heyi, Happy to discuss the detail but the short answer is no. Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. Cheers, Achin On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years

3
7
0 0

Re: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Apologies, I need to cancel this weeks TF-A Tech Forum session on 3rd December due to clashing events for Arm attendees. Next meeting will be 17th December which will be the last session of 2020. 31st December session is also cancelled with the first 2021 session being 14th January 2021. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 3 December 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

5 years

1
0
0 0

Does TF-A support to load and run both TEE and SPM_MM?

by Heyi Guo

Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi

5 years

1
0
0 0

Re: [TF-A] [PATCH] plat/qemu/qemu_sbsa: Include libraries for Cortex-A72

by Jens Wiklander

Hi Tanmay, Please upload the patch at https://review.trustedfirmware.org/, for details see https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Thanks, Jens On Thu, Nov 19, 2020 at 7:28 PM Tanmay Jagdale <tanmay.jagdale(a)linaro.org> wrote: > > Include libraries needed to emulate Cortex-A72 in sbsa-ref target of Qemu. > > Signed-off-by: Tanmay Jagdale <tanmay.jagdale(a)linaro.org> > --- > plat/qemu/qemu_sbsa/platform.mk | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk > index 1a4a2db02..a8036f622 100644 > --- a/plat/qemu/qemu_sbsa/platform.mk > +++ b/plat/qemu/qemu_sbsa/platform.mk > @@ -43,7 +43,8 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ > > BL1_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > - lib/cpus/aarch64/cortex_a57.S > + lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S > > BL2_SOURCES += drivers/io/io_semihosting.c \ > drivers/io/io_storage.c \ > @@ -72,6 +73,7 @@ QEMU_GIC_SOURCES := ${GICV3_SOURCES} \ > BL31_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S \ > lib/semihosting/semihosting.c \ > lib/semihosting/${ARCH}/semihosting_call.S \ > plat/common/plat_psci_common.c \ > -- > 2.29.2 >

5 years

2
1
0 0

Hafnium / TF-A v2.4 first tagged release is available

by Olivier Deprez

Hi All, Following the announcement of the Trusted Firmware-A/Trusted Firmware-A-tests v2.4 release: We are pleased to announce the first tagged release of Hafnium [1] implementing the SPMC according to the FF-A v1.0 specification [2]. As a reminder, Hafnium has been transferred to trustedfirmware.org back in May 2020 to become the reference open source S-EL2 firmware, under an Arm/Google co-maintainership. Contributions are open to partners in trustedfirmware.org The Secure Partition Manager documentation is available at [3] Please also refer to the change log at [4] The companion TF-A test suite permits the validation of FF-A ABIs and NWd/SWd communication by the use of bare-metal S-EL1 secure partitions. Thanks to all who contributed to make it happen. Regards, Olivier. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.4 [2] https://developer.arm.com/documentation/den0077/latest [3] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… [4] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 November 2020 14:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

5 years, 1 month

1
0
0 0

TF-A Tech Forum Agenda @ Thr 19th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 19th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST. A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Trace-based Code Coverage Tooling for Firmware Projects * Presented by Basil Eljuse & Saul Romero * Summary * TF-A has adopted a code coverage system to measure the effectiveness of the various runtime testing performed and this is achieved without doing code instrumentation. This presentation is an overview of that approach which has applicability beyond the TF-A project. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

5 years, 1 month

1
0
0 0

Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available

by Manish Badarkhe

Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

5 years, 1 month

1
0
0 0

atf-a with optee-os for firefly-rk3399

by Piotr Lobacz

Hi All, i've been trying for a couple of days to load current optee together with atf from the github, with no luck. For that i have been using manuals (https://trustedfirmware-a.readthedocs.io/en/latest/plat/rockchip.html , http://opensource.rock-chips.com/wiki_ATF ) for rockchip and what i have succeded is to run very old atf tag 1.3 with optee blob from rockchip which i suspect is also very old. And if i try to use any newer atf >= 1.4 than i suspect that it does not load, because i do not see any LOGS from it, no matter that LOG_LEVEL was set to 50... Can anybody help me solving this issue or point me to some solution? Thanks in advance. BR Piotr Łobacz [https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com> Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego Rejestru Sądowego KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości.

5 years, 1 month

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Soby Mathew

Hi Julius, The TF-A build sets the `-mstrict-align` compiler option, that means that the compiler will generate only aligned accesses as default. So disabling the check at runtime, seems `unaligned` with the compiler option IMO. The programmer can induce unaligned access though, although I am struggling to understand why the programmer would want to do that. The case you have pointed out seems like an error which needs to be corrected in platform code IMO. > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. TF-A has linker symbol references and non-trivial linker section manipulations at runtime and these have previously triggered alignment errors when binary layout changed due to code issues. Disabling the alignment check at runtime means these errors would have remained undetected and would have resulted in more obscure crash at runtime or even a vulnerablility. In some cases, only the RELEASE builds (DEBUG=0) triggered the alignment fault. > There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense). Agree. But I am failing to understand why the unaligned accesses came to be there in the first place. My worry is, if this was not intended by the programmer, this might as well be a bug that will remain undetected if the alignment check is disabled. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius > Werner via TF-A > Sent: 10 November 2020 02:31 > To: raghu.ncstate(a)icloud.com > Cc: tf-a <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Alignment fault checking in EL3 > > > >>. What I am worried about is mistakes and oversights that slip > > >>through testing and then cause random or even attacker-controllable > > >>crashes in production > > > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing > the relation between the crash and SCTLR.A bit. If there are oversights that > slip through testing and an attacker can cause a crash, there is > vulnerability/bug. > > If there is something that slipped through, that causes a data > abort(perhaps address not mapped in the translation tables), would we turn > off the MMU ? > > Well, my assumption is that performing an unaligned access cannot be a > vulnerability. If you have examples to the contrary please let me know, but > as far as I am aware letting an unaligned access through should always work > and will always result in the behavior the programmer intended (other than > maybe contrived cases where device address space is mapped with a non- > Device memory type, which is already very wrong for plenty of other reasons > and should never happen). The only negative consequence is that the access > may take slightly longer than if it were aligned. I do understand the desire to > be able to shake out unaligned accesses during development and testing > > I don't think the comparison to a data abort works because obviously with a > data abort the program usually can't just continue and still assume its internal > state is valid.

5 years, 1 month

2
2
0 0

FW: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A

by Matteo Carlini

Cross-posting on the TF-A mailing list too for interested people to attend the kickoff meeting listed below hosted by Linaro. Thanks Matteo -----Original Message----- From: Linaro-open-discussions <linaro-open-discussions-bounces(a)op-lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions Sent: 10 November 2020 10:21 To: linaro-open-discussions(a)op-lists.linaro.org Subject: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A Hi all, As previously announced we are hosting a kickoff meeting for the above topic/project. The meeting has been added to the linaro-open-discussions calendar, according to the below. Feel free to join us on Thursday this week! Kind regards Ulf Hansson, Linaro KWG When: Thursday Nov 12, 16:00-17:00 CET. Agenda: 1. Introduction. 2. Update of the current support in Linux. 3. Collaborations. 4. Technical things. 5. Other matters. To join the Zoom Meeting: https://linaro-org.zoom.us/j/97261221687 Meeting ID: 972 6122 1687 One tap mobile +13462487799,,97261221687# US (Houston) +16465588656,,97261221687# US (New York) Dial by your location +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) Meeting ID: 972 6122 1687 Find your local number: https://linaro-org.zoom.us/u/acg3UrpmdE -- Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

5 years, 1 month

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Julius Werner

> >>. What I am worried about is mistakes and > >>oversights that slip through testing and then cause random or even > >>attacker-controllable crashes in production > > Why would this not be the case even with SCTLR.A bit set? I'm not seeing the relation between the crash and SCTLR.A bit. If there are oversights that slip through testing and an attacker can cause a crash, there is vulnerability/bug. > If there is something that slipped through, that causes a data abort(perhaps address not mapped in the translation tables), would we turn off the MMU ? Well, my assumption is that performing an unaligned access cannot be a vulnerability. If you have examples to the contrary please let me know, but as far as I am aware letting an unaligned access through should always work and will always result in the behavior the programmer intended (other than maybe contrived cases where device address space is mapped with a non-Device memory type, which is already very wrong for plenty of other reasons and should never happen). The only negative consequence is that the access may take slightly longer than if it were aligned. I do understand the desire to be able to shake out unaligned accesses during development and testing, but at least in a production build I think taking that performance hit would always be preferable to a crash. I don't think the comparison to a data abort works because obviously with a data abort the program usually can't just continue and still assume its internal state is valid.

5 years, 1 month

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, A lot of the rationale for the default initialization is not listed in the documentation and I do think perhaps we can do better as at the end of the day it’s decisions around platform ports and how they are going to be deployed in products that may influence decisions here for changing the defaults. Your thoughts around attacker control able crashes are a valid one. I don’t think any one setting is all pros with no cons and platform providers need to make decisions but I think the default code with the settings is more likely to flush out alignment bugs and although I don’t have specific examples any bug could play a part in future vulnerability so best to flush them out rather than lie hidden. It could be said that in the reference implementation a known crash may be better than a more nebulous unknown behaviour that could come with an undetected bug that could later be taken advantage of. The use a DEBUG flag is an idea but we have all seen debug builds not operating like production builds so the value may be lost here. It’s why on reviewing our documentation on seeing your post I think we could do better to explain the rationale for the settings in TF-A so platform owners can be better informed and override default settings if they really feel they have the need. Cheers Joanna ________________________________ From: Julius Werner Sent: Monday, November 9, 2020 10:42 PM To: Joanna Farley Cc: raghu.ncstate(a)icloud.com; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Alignment fault checking in EL3 Hi Joanna, Thank you for your detailed response. I was mostly wondering if this was a deliberate choice or just something someone wrote this way once and nobody ever thought about again. Since it sounds like it is intentional, I'll try to understand your rationale better. > Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. I'm curious, can you elaborate on that? I can't really think of a scenario where lack of alignment checking can really make code behave in an unintentional way. (I don't think Raghu's scenario of accessing MMIO registers works because those registers should be mapped with a Device memory type anyway, and that memory type enforces aligned accesses regardless of the SCTLR.A flag.) If there truly are security concerns with this I can understand your approach much better. > Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense).

5 years, 1 month

1
0
0 0

Re: [TF-A] Alignment fault checking in EL3

by Joanna Farley

Hi Julius, Talking to the team here its has always been felt it is best practise to forbid unaligned data accesses in Arm's embedded projects. That's the reason TF-A also enforces the build options: -mno-unaligned-access (AArch32) and -mstrict-align (AArch64). In the TF-A documentation [1] SCTLR_EL3.A and other settings are listed in the Architectural Initialisation section. There is thought to be only a few cases where unaligned access are correct and intentional and most are defects that should be caught early and not in production and as such it is better to detect unaligned data access conditions early in a platform porting, rather than in the field especially if there is no firmware update capability. Alignment faults should be treated as fatal as they should never happen in production when components have been designed as such from the beginning. Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them. We can of course provide better rationalisation based on the above in our documentation to provide platforms porting efforts better guidance. It is after all up to partners in their platform ports to make appropriate decisions for their ports where settings could be changed however the upstreamed reference code should follow the settings we have which are felt to be best practices for TF-A. It is known other projects follow other practices and that is fine if that works for them. Once a project enables unaligned accesses, it's very hard to go back again since it's likely that code that does unaligned accesses will slowly get added to the project. However for TF-A maintaining the current settings is felt to be the best approach when weighing up the costs and benefits. Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward. Thanks Joanna [1] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.h… On 09/11/2020, 17:47, "TF-A on behalf of Raghu Krishnamurthy via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes? -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 1 month

3
2
0 0

Re: [TF-A] Alignment fault checking in EL3

by raghu.ncstate＠icloud.com

Hi Julius, I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset. Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior. So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks. >> I am still wondering why we choose to set the SCTLR_EL3.A I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0. Thanks Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Friday, November 6, 2020 6:38 PM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Alignment fault checking in EL3 Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

5 years, 1 month

1
0
0 0

Alignment fault checking in EL3

by Julius Werner

Hi, I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers. Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.) For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?

5 years, 1 month

1
0
0 0

[RFC PATCH] hw/arm/virt: use sbsa-ec for reboot and poweroff in secure mode

by Maxim Uvarov

If we're emulating EL3 then the EL3 guest firmware is responsible for providing the PSCI ABI, including reboot, core power down, etc. sbsa-ref machine has an embedded controller to do reboot, poweroff. Machine virt,secure=on can reuse this code to do reboot inside ATF. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- Hello, This patch implements reboot for the secure machine inside ATF firmware. I.e. current qemu patch should be used with [1] ATF patch. It looks like that Embedded Controller qemu driver (sbsa-ec) can be common and widely used for other emulated machines. While if there are plans to extend sbsa-ec then we might find some other solution. So for the long term it looks like machine virt was used as an initial playground for secure firmware. While the original intent was a runner for kvm guests. Relation between kvm guest and firmware is not very clear now. If everyone agree it might be good solution to move secure firmware things from virt machine to bsa-ref and make this machine reference for secure boot, firmware updates etc. [1] https://github.com/muvarov/arm-trusted-firmware/commit/6d3339a0081f6f2b45d9… Best regards, Maxim. hw/arm/virt.c | 9 +++++++++ include/hw/arm/virt.h | 2 ++ 2 files changed, 11 insertions(+) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index e465a988d6..6b77912f02 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -152,6 +152,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_ACPI_GED] = { 0x09080000, ACPI_GED_EVT_SEL_LEN }, [VIRT_NVDIMM_ACPI] = { 0x09090000, NVDIMM_ACPI_IO_LEN}, [VIRT_PVTIME] = { 0x090a0000, 0x00010000 }, + [VIRT_EC] = { 0x090c0000, 0x00001000 }, [VIRT_MMIO] = { 0x0a000000, 0x00000200 }, /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */ [VIRT_PLATFORM_BUS] = { 0x0c000000, 0x02000000 }, @@ -1729,6 +1730,13 @@ static void virt_cpu_post_init(VirtMachineState *vms, int max_cpus, } } +static void init_ec_controller(VirtMachineState *vms) +{ + vms->ec = qdev_new("sbsa-ec"); + + sysbus_mmio_map(SYS_BUS_DEVICE(vms->ec), 0, vms->memmap[VIRT_EC].base); +} + static void machvirt_init(MachineState *machine) { VirtMachineState *vms = VIRT_MACHINE(machine); @@ -1797,6 +1805,7 @@ static void machvirt_init(MachineState *machine) */ if (vms->secure && firmware_loaded) { vms->psci_conduit = QEMU_PSCI_CONDUIT_DISABLED; + init_ec_controller(vms); } else if (vms->virt) { vms->psci_conduit = QEMU_PSCI_CONDUIT_SMC; } else { diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index aad6d69841..6f2ce4e4ff 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -85,6 +85,7 @@ enum { VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, VIRT_PVTIME, + VIRT_EC, VIRT_LOWMEMMAP_LAST, }; @@ -163,6 +164,7 @@ struct VirtMachineState { DeviceState *gic; DeviceState *acpi_dev; Notifier powerdown_notifier; + DeviceState *ec; }; #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM) -- 2.17.1

5 years, 1 month

5
7
0 0

TF-A Tech Forum Agenda @ Thr 5th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 5th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST. A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * TF-A Tests Framework Overview * Presented by Varun Wadekar * Summary * Trusted Firmware-A Tests (TF-A Tests) is a suite of baremetal tests to exercise the Trusted Firmware-A (TF-A) features from the Normal World. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

5 years, 1 month

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 1 month

1
0
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Ruchika Gupta

Hi, *For [1] - Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood.* You can check the implementation at https://github.com/microsoft/MSRSec This compiles for aarch64. I had a few queries for chips having physical TPM. Case 1. Should all entities doing the measurement (BL1, BL2) have the TPM driver to extend the measurements as they are done. This would be the most secure flow. Case 2. If BL1 and BL2 don't have the TPM driver as mentioned in Case 1 above, who would be responsible for extending the measurements for secure world entities. -- Should there be a TPM driver in Secure EL0/EL1 which does this ? -- Event log is also passed to the BL33. In case there is no TPM driver at all in the secure world - is it expected that BL33 should extend the measurements in PCR ? Regards, Ruchika On Mon, 26 Oct 2020 at 21:03, Stuart Yoder via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Regarding measuring TB_FW_CONFIG-- > > BL1 could measure the unmodified TB_FW_CONFIG image as it was loaded from > flash. It could then update TB_FW_CONFIG with that measurement which > reflects the image as it was on flash. This could allow detection of > tampering with flash. I would recommend doing this, as TB_FW_CONFIG is > critical data. > > BL2 could make a measurement of the TB_FW_CONFIG image as it was passed to > it in memory. > > Thanks, > Stuart > > > On 10/26/20 6:16 AM, Alexei Fedorov wrote: > > Hi Javer, > > Please see my comments below. > > [3] Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. > > These hooks can be implemented in the next phase #2 of Measured Boot > implementation. > > [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. > BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. > It can also pass FW_CONFIG hash in the same DTB, but it is not clear how > own TB_FW_CONFIG hash can be passed in itself. > > Stuart, do you have opinion on that? > > Regards. > > Alexei > ------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa > Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Sent:* 26 October 2020 10:25 > *To:* raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > <raghu.ncstate(a)icloud.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] Questions raised about Measured Boot + fTPM test > case > > Hi Raghu, > > Thank you very much for your comments and for your feedback. > > With regards to the (f)TPM service and as discussed during the last TF-A > Tech Forum call, we will discuss internally the need of a new > implementation, probably after the next TF-A release, and we will schedule > the work (in case we decide to go ahead with it) for the upcoming months. > We will announce any decision we make through the mailing list and/or on > future TF-A Tech Forum calls . > > Regarding to changes to TF-A to include extra functionality/APIs/hooks, I > guess my colleague Alexei can provide further details about the next > features planned for Measured Boot, if any. > > To finish, I would just like to clarify one of the questions raised on > your email: > > [1] Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > > > - Microsoft has a reference implementation of the TPM 2.0 > specification. That implementation is in the form of an architecture > agnostic library that implements the specification. Along with the library, > there are a couple of example applications for different platforms built > around the former, one of them being the fTPM we used for testing. That > application was written for AARCH32 and seemed to be outdated (I don't know > if it was abandoned, actually), so we updated it and added support for > Measured Boot to it. > > > Best regards, > Javier > > -----Original Message----- > *From*: raghu.ncstate(a)icloud.com > *To*: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com > <'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> > *Cc*: tf-a(a)lists.trustedfirmware.org > *Subject*: RE: [TF-A] Questions raised about Measured Boot + fTPM test > case > *Date*: Sun, 25 Oct 2020 14:31:10 -0700 > > Hi Javier, > > > > As discussed during the TF-A call, here are some suggestions/feedback that > can be incorporated when time permits based on priorities, schedule, > resources etc: > > 1. Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > 2. Would be good if the TPM TA works on FF-A as opposed to proprietary > OPTEE API’s. > 3. Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. This is a requirement from a security perspective to not > wait until the tpm TA is loaded to be able to extend the measurements into > a tpm. I understand this can be done in the platform hook that calls > tpm_record_measurement but it is convenient place to put tpm related > platform hooks. > 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > > > Thanks > > Raghu > > > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Javier Almansa > Sobrino via TF-A > *Sent:* Friday, October 9, 2020 10:51 AM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Questions raised about Measured Boot + fTPM test case > > > > Hello all, > > > > Following up the question raised yesterday during the TF-A Tech Forum with > regards to any modification needed on the Linux Kernel to run the test case > that I was presenting (Measured Boot + fTPM service), I double checked > today and I ran some tests on system and I can confirm that the test case > works with the mainline Linux Kernel, with no modification other than > enabling the driver on the DTB. > > > > The modules involved on the interaction with the fTPM (for this particular > example) are: > > > > * optee.ko: Allows communication between the REE (unsecure world), the > Trusted OS (secure world) and the tee-supplicant (unsecure world). > > * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a > char device. This also includes the reference implementation used on the > test case. > > > > In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 > TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. > > > > I would also like to highlight the following points: > > > > A) The test case is only meant to test the ability of the Measured Boot > Driver and a TPM 2.0 compliant device to interact with each other. As such, > we are not providing an fTPM meant to be used on a production environment. > Instead, we are using an existing reference implementation to which we > added support for Measured Boot to fulfil our needs for the test and use it > as a functional example. The implementation details on how to interact with > a particular TPM device (either firmware or discrete) can differ from the > ones used on the test case as those details can be platform dependent. For > example, we use an OPTEE TA fTPM on this example, but other platforms might > use a discrete TPM or an fTPM running on a different Trusted OS. > > > > B) As stated on the presentation, we are undergoing internal review of the > contributions done for the fTPM service to make it compatible with Measured > Boot. Once the review is completed and the changes merged into the TPM repo > mainline, we will update the TF-A documentation with instructions on how to > download and build all the components to run the tests manually. > > > > Please, let me know in case you have any more questions. > > > > Best regards, > > Javier > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

5 years, 1 month

3
2
0 0

Re: [TF-A] [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode

by Matteo Carlini

Cross-posting to the TF-A mailing list as well for interested partners. > -----Original Message----- > From: Linaro-open-discussions <linaro-open-discussions-bounces@op- > lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions > Sent: 28 October 2020 15:45 > To: linaro-open-discussions(a)op-lists.linaro.org > Cc: Lauren Wehrmeister <Lauren.Wehrmeister(a)arm.com>; Lina Iyer > <ilina(a)codeaurora.org>; Dan Handley <Dan.Handley(a)arm.com>; Madhukar > Pappireddy <Madhukar.Pappireddy(a)arm.com>; Bhutada Harshad > <hbhutada(a)qti.qualcomm.com>; Gabriel FERNANDEZ > <gabriel.fernandez(a)st.com> > Subject: [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode > > Hi all, > > In the Linux kernel v5.6, we introduced the basic support for PSCI OS-initiated > mode. Linaro is still working on evolving the support, step by step. > Additionally, we are helping some of our members with corresponding SoC > deployment, which is planned to continue for a while. > > Basically, the PSCI OS-initiated mode allows Linux to be in charge of idlestate > decisions for a group of CPUs (aka CPU cluster), which may share idlestates. > In some cases this enables improvements in regards to performance/energy, > but could also be used to help manage resources that may share power- > /clock-domains with CPUs. > > Moving forward, we are now planning to extend the corresponding PSCI > implementation in the Trusted Firmware-A (TF-A) with the OS-initiated mode, > together with our members and member engineers. Currently, only the > default PSCI platform-coordinated mode is supported by the TF-A. > > We seek for additional collaborations and input to the new project! > Please get in touch, if you have any feedback and/or find this project > interesting. > > Finally, a kickoff meeting is about to be scheduled and held within a few > weeks. Let me know if you want to join the discussions. > > Kind regards > Ulf Hansson, Linaro Kernel Working Group > -- > Linaro-open-discussions mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

5 years, 1 month

1
0
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I'm able to eliminate the warning using the -j .text and see the image load and run ok. The issue I am seeing is that the bsp I am using expects my bot loader bl31.bin to power on the UART and do the low level init that makes PCIe controller accessible. I think at exit from bl31.bin I don't have this initialization. Can you point me the TFA code to enable LPUART and make PCIe controller accessible in imx8qm before handoff to BL33 ? Regards Ravi > On Oct 28, 2020, at 11:33 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, Thanks for the hint. Yes, my App.bin image has a bunch of header info > and that's the root cause of the undef ARM instructions. I grabbed a pure ELF image > I built using the integrity compiler and see the following warning on trying to convert ELF to > raw binary on linux. The conversion is not permitted. Do I need some flags ? > > Regards > Ravi > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-readelf -h ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf > ELF Header: > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF64 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: EXEC (Executable file) > Machine: AArch64 > Version: 0x1 > Entry point address: 0xffffff8080200000 > Start of program headers: 64 (bytes into file) > Start of section headers: 866208 (bytes into file) > Flags: 0x0 > Size of this header: 64 (bytes) > Size of program headers: 56 (bytes) > Number of program headers: 49 > Size of section headers: 64 (bytes) > Number of section headers: 78 > Section header string table index: 77 > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-objcopy -O binary ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf ~/imx8qm/imx-mkimage/iMX8QM/dummy.bin > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.text' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.data' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.boottable' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.secinfo' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy:/home/ravi/imx8qm/imx-mkimage/iMX8QM/dummy.bin[.example_virtual.text]: file truncated > > > > > > On Wed, Oct 28, 2020 at 10:09 AM Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > Hi Ravi, > > Is App.bin generated by the tool you use is a "pure" binary or contains some extra entries at the start of the image (e.g. 0x7F 0x45 0x4C 0x46 = "ELF" )? > This might also help: > https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone… <https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone…> > > Alexei > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > Sent: 27 October 2020 22:03 > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > No, we don't see the same behavior when launching our hello world app (using Integrity178 rtos) > from U-boot. The only change uboot needed was related to size of the image (i don't have specifics about this change). > But, the hello app runs fine from U-boot printing normally on the imx8qm MEK board. > > I don't see this test app write to the UART launching from bl31.bin at 0x80020000. I can see the > handoff is successful setting a breakpoint at 0x80020000 from my Lauterbach debugger probe. > > The test app is prepared using the GHS tools (elf to bin) using gmemfile.exe and then uboot's mkimage > command: mkimage -A arm64 -O u-boot -T kernel -C none -a 0x80200000 -e 0x80200000 -n "INTEG" -d tmp.bin App.bin. > This generates the App.bin that tftpboots boots fine from any given address on my board. This very same image > does not work booting from bl31.bin. > > Can you suggest what could be going on ? > > Regards > Ravi > > > > > > On Oct 27, 2020, at 8:34 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > > > > Hi Ravi, > > > > It is good to know that you have some progress with your problem. > > > > "I'm seeing some undef instruction, etc, etc." > > Do you see the same behaviour when launching BL33 from U-Boot? > > > > Regards. > > Alexei > > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > > Sent: 26 October 2020 20:23 > > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > > Subject: Re: [TF-A] BL31 as bootloader > > > > Hi Alexei, Manish, > > > > I had some better luck with my debugger this time. I can see > > the handoff from bl31.bin (imx-atf) to BL33 entry point (0x80020000) > > in my debugger now. > > > > The problem was in setting up the debugger properly which was > > preventing me from seeing the breakpoint. My bad. > > > > Now, I can see the handoff and execution of instruction of the > > test app. This app is an integrity178 app and I'm seeing some undef > > instruction, etc, etc. Likely specific to the rtos we are using for this app. > > So, I will follow up on that end. Thanks for your debug support and > > helping me experiment with TFA for our product. > > > > Regards > > Ravi > > > > > >> On Oct 26, 2020, at 4:44 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >> > >> Hi Ravi > >> > >> As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. > >> > >> Regards. > >> Alexei > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Sent: 24 October 2020 22:48 > >> To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Subject: Re: [TF-A] BL31 as bootloader > >> > >> Hi Alexei, Manish, > >> > >> I instrumented the imx8QM platform code and saw normal execution with bl31_main() > >> exiting normally with entry point for my BL33 image. But, I haven't seen the handoff > >> work yet. Can you suggest what else I can try to debug this ? I have an image copied > >> at 0x80020000 from what I can see in the debugger. Thanks in advance. > >> > >> Regards > >> Ravi > >> > >> > >> > >> > >> On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> wrote: > >> Hi Manish, > >> > >> I have been able to copy the test app (BL33) to entry point address 0x80020000. > >> I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf > >> makefile target to use the "-data" option as follows: > >> flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >> The -data option appears to copy the image at the 0x80020000 address. Now, I think we should > >> be able to handoff since PC (program counter) is set : > >> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >> > >> I don't see any serial console output using an image that works when using u-boot. I am not using > >> u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to > >> the App.bin ? At which BL31 function or module does the handoff occur ? > >> > >> I don't see my HW breakpoint trigger at location location 0x80020000. > >> > >> Regards > >> Ravi > >> > >>> On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>> > >>> Hi Manish, > >>> > >>> Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? > >>> Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). > >>> > >>> The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 > >>> to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming > >>> its some NXP firmware doing it. Do you know where it could be ? > >>> > >>> Regards > >>> Ravi > >>> > >>> > >>>> On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>> > >>>> Hi Ravi, > >>>> > >>>> This is normal behaviour when you RESET_TO_BL31. > >>>> The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. > >>>> Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. > >>>> > >>>> thanks > >>>> Manish > >>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>> Sent: 23 October 2020 05:08 > >>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>> Subject: Re: [TF-A] BL31 as bootloader > >>>> > >>>> Hi Alexei, Manish, > >>>> > >>>> I repeated the test (below) a few times and see the same result. > >>>> > >>>> (1) Do I need to copy my BL33 (non-secure) image from > >>>> flash.bin some how to RAM 0x80020000 entry point address ? > >>>> Is there any example of how to copy the flash.bin image ? I not sure > >>>> what address or where to copy it from. > >>>> > >>>> (2) Is there some existing debug code that I can use > >>>> to dump/print the ARMv8 RAM address space from inside > >>>> BL31.bin ? > >>>> > >>>> I only found some TF-A tf_log macros in debug.h. > >>>> I would like to dump some memory address contents > >>>> (like 0x80020000) from inside bl31.bin to console just for > >>>> debugging at run-time. > >>>> > >>>>> On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>> > >>>>> Hi Alexei, > >>>>> > >>>>> I captured the LOG_LEVEL=50 log (attached putty-ser0.log) from TF-A bl31.bin. > >>>>> I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) > >>>>> > >>>>> The flash.bin image I am running is constructed using imx-mkimage tool with the following target: > >>>>>> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >>>>>> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>> > >>>>> I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. > >>>>> > >>>>> I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). > >>>>>> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > >>>>>> index 92a2027dd..51afb13ea 100644 > >>>>>> --- a/bl31/bl31_main.c > >>>>>> > >>>>>> +++ b/bl31/bl31_main.c > >>>>>> @@ -147,6 +147,11 @@ void bl31_main(void) > >>>>>> * from BL31 > >>>>>> */ > >>>>>> bl31_plat_runtime_setup(); > >>>>>> + > >>>>>> + INFO("BL31: leaving bl31_main\n"); > >>>>>> + INFO("entering while(1)\n"); > >>>>>> + > >>>>>> + while (1) {}; > >>>>>> } > >>>>> It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at > >>>>> address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). > >>>>> See the debugger output. > >>>>> > >>>>> When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin > >>>>> copy the image from flash to RAM ? > >>>>> > >>>>> Can you suggest what could be going on ? > >>>>> > >>>>> Regards > >>>>> Ravi > >>>>> > >>>>> > >>>>> > >>>>>> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>> > >>>>>> Hi Ravi, > >>>>>> > >>>>>> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> > >>>>>> > >>>>>> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. > >>>>>> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. > >>>>>> > >>>>>> Regards. > >>>>>> Alexei > >>>>>> > >>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>> Sent: 21 October 2020 19:59 > >>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.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>> > >>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>> > >>>>>> Alexei, > >>>>>> > >>>>>> I don't have a DS-5 debugger setup/licensed. I am hoping > >>>>>> on getting something shortly. > >>>>>> > >>>>>> Can you point me to the TFTF image that I can use to > >>>>>> test the BL33 handoff ? > >>>>>> > >>>>>> Sorry, I'm not familiar at this time. > >>>>>> > >>>>>> Regards > >>>>>> Ravi > >>>>>> > >>>>>> > >>>>>>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>> > >>>>>>> You can also use TFTF image as BL33. > >>>>>>> > >>>>>>> Alexei > >>>>>>> > >>>>>>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>> Sent: 21 October 2020 15:26 > >>>>>>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). > >>>>>>> > >>>>>>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>> - You can use a linux image and device tree to test it > >>>>>>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function > >>>>>>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" > >>>>>>> > >>>>>>> > >>>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>> Sent: 21 October 2020 12:12 > >>>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.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>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> Hi Alexei, Manish, > >>>>>>> > >>>>>>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: > >>>>>>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, > >>>>>>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; > >>>>>>>> #endif > >>>>>>>> #endif > >>>>>>>> + // DEBUG ONLY - FIXME > >>>>>>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> + > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> /* init the first cluster's cci slave interface */ > >>>>>>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); > >>>>>>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); > >>>>>>>> + > >>>>>>>> } > >>>>>>> But no luck. > >>>>>>> > >>>>>>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? > >>>>>>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> > >>>>>>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > >>>>>>>> Hi Ravi, > >>>>>>>> > >>>>>>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: > >>>>>>>> > >>>>>>>> /* Populate entry point information for BL33 */ > >>>>>>>> SET_PARAM_HEAD(&bl33_image_ep_info, > >>>>>>>> PARAM_EP, > >>>>>>>> VERSION_1, > >>>>>>>> 0); > >>>>>>>> /* > >>>>>>>> * Tell BL31 where the non-trusted software image > >>>>>>>> * is located and the entry state information > >>>>>>>> */ > >>>>>>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >>>>>>>> > >>>>>>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> Regards. > >>>>>>>> Alexei > >>>>>>>> > >>>>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Sent: 21 October 2020 10:57 > >>>>>>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > >>>>>>>> Hi Manish, > >>>>>>>> > >>>>>>>> The test image should not have any dependency on device tree (dtb?) > >>>>>>>> for console init. > >>>>>>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match > >>>>>>>> the MEK board. > >>>>>>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) > >>>>>>>> as well but no luck. > >>>>>>>> I don't believe PC is getting set to the 0x80020000 entry point. > >>>>>>>> > >>>>>>>> The test image has validated with u-boot using these tftpboot settings: > >>>>>>>> setenv ipaddr x.x.x.x > >>>>>>>> setenv serverip x.x.x.x > >>>>>>>> tftpboot 0xf0000000 App.bin > >>>>>>>> bootm 0xf0000000 > >>>>>>>> > >>>>>>>> I don't see any console output on the screen running it with bl31.bin as below. > >>>>>>>> Is there any debug I can add somewhere to help troubleshoot? > >>>>>>>> > >>>>>>>> Can you please provide me instructions on where to patch this missing code : > >>>>>>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" > >>>>>>>> I can try it to see if any change in behavior. > >>>>>>>> > >>>>>>>> Thanks in advance. > >>>>>>>> Regards > >>>>>>>> Ravi > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > >>>>>>>> > Also, does your "test image" depends on device tree for console initialization? > >>>>>>>> > > >>>>>>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > >>>>>>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> > > >>>>>>>> > thanks > >>>>>>>> > Manish > >>>>>>>> > > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 21 October 2020 00:10 > >>>>>>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > >>>>>>>> > > >>>>>>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > >>>>>>>> > > >>>>>>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > >>>>>>>> > > >>>>>>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > >>>>>>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>>>>> > > >>>>>>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > >>>>>>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > >>>>>>>> > > >>>>>>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > >>>>>>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > >>>>>>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > >>>>>>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > >>>>>>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > >>>>>>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > >>>>>>>> > NOTICE: Non-secure Partitioning Succeeded > >>>>>>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > >>>>>>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > >>>>>>>> > INFO: bl31_platform_setup is called > >>>>>>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > >>>>>>>> > INFO: BL31: Initializing runtime services > >>>>>>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > >>>>>>>> > INFO: BL31: Preparing for EL3 exit to normal world > >>>>>>>> > INFO: Entry point address = 0x80020000 > >>>>>>>> > INFO: SPSR = 0x3c9 > >>>>>>>> > INFO: BL31: DEBUG: image_type is: normal > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > >>>>>>>> > Note, the same test image works fine using u-boot. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > >>>>>>>> > I will try it out and confirm. And, thanks for this suggestion. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Have you tried to use RESET_TO_BL31 build option for your platform? > >>>>>>>> > > >>>>>>>> > Regards. > >>>>>>>> > Alexei > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 07 October 2020 17:01 > >>>>>>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi, > >>>>>>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > >>>>>>>> > > >>>>>>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > >>>>>>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > >>>>>>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. > >>>>>>>> > This is without any security requirements or dependencies. > >>>>>>>> > > >>>>>>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > >>>>>>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > >>>>>>>> > 0x80020000 address ? > >>>>>>>> > > >>>>>>>> > Thanks in advance. > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > >>>>>>>> TF-A mailing list > >>>>>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>> > >>>>> > >>>>> -- > >>>>> TF-A mailing list > >>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>> > >>> -- > >>> TF-A mailing list > >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <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

5 years, 1 month

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 24 October 2020 22:48 To: Ravi Kohli <rkohli2000(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I instrumented the imx8QM platform code and saw normal execution with bl31_main() exiting normally with entry point for my BL33 image. But, I haven't seen the handoff work yet. Can you suggest what else I can try to debug this ? I have an image copied at 0x80020000 from what I can see in the debugger. Thanks in advance. Regards Ravi On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> wrote: Hi Manish, I have been able to copy the test app (BL33) to entry point address 0x80020000. I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf makefile target to use the "-data" option as follows: flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin The -data option appears to copy the image at the 0x80020000 address. Now, I think we should be able to handoff since PC (program counter) is set : bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); I don't see any serial console output using an image that works when using u-boot. I am not using u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to the App.bin ? At which BL31 function or module does the handoff occur ? I don't see my HW breakpoint trigger at location location 0x80020000. Regards Ravi On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Manish, Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming its some NXP firmware doing it. Do you know where it could be ? Regards Ravi On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: Hi Ravi, This is normal behaviour when you RESET_TO_BL31. The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. thanks Manish ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 23 October 2020 05:08 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I repeated the test (below) a few times and see the same result. (1) Do I need to copy my BL33 (non-secure) image from flash.bin some how to RAM 0x80020000 entry point address ? Is there any example of how to copy the flash.bin image ? I not sure what address or where to copy it from. (2) Is there some existing debug code that I can use to dump/print the ARMv8 RAM address space from inside BL31.bin ? I only found some TF-A tf_log macros in debug.h. I would like to dump some memory address contents (like 0x80020000) from inside bl31.bin to console just for debugging at run-time. On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Alexei, I captured the LOG_LEVEL=50 log (attached putty-ser0.log<https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) The flash.bin image I am running is constructed using imx-mkimage<https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c index 92a2027dd..51afb13ea 100644 --- a/bl31/bl31_main.c +++ b/bl31/bl31_main.c @@ -147,6 +147,11 @@ void bl31_main(void) * from BL31 */ bl31_plat_runtime_setup(); + + INFO("BL31: leaving bl31_main\n"); + INFO("entering while(1)\n"); + + while (1) {}; } It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). See the debugger output<https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin copy the image from flash to RAM ? Can you suggest what could be going on ? Regards Ravi On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. Regards. Alexei ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 19:59 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.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>> Subject: Re: [TF-A] BL31 as bootloader Alexei, I don't have a DS-5 debugger setup/licensed. I am hoping on getting something shortly. Can you point me to the TFTF image that I can use to test the BL33 handoff ? Sorry, I'm not familiar at this time. Regards Ravi On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: You can also use TFTF image as BL33. Alexei ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 21 October 2020 15:26 To: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? - You can use a linux image and device tree to test it Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 12:12 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.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>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; #endif #endif + // DEBUG ONLY - FIXME + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); + SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); /* init the first cluster's cci slave interface */ cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); + } But no luck. Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? Thanks. On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: /* Populate entry point information for BL33 */ SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); /* * Tell BL31 where the non-trusted software image * is located and the entry state information */ bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 21 October 2020 10:57 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Manish, The test image should not have any dependency on device tree (dtb?) for console init. I used the NXP provided imx8qm-mek-ca53.dtb file which should match the MEK board. I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) as well but no luck. I don't believe PC is getting set to the 0x80020000 entry point. The test image has validated with u-boot using these tftpboot settings: setenv ipaddr x.x.x.x setenv serverip x.x.x.x tftpboot 0xf0000000 App.bin bootm 0xf0000000 I don't see any console output on the screen running it with bl31.bin as below. Is there any debug I can add somewhere to help troubleshoot? Can you please provide me instructions on where to patch this missing code : "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" I can try it to see if any change in behavior. Thanks in advance. Regards Ravi On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: > > Hi Ravi, > > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > Also, does your "test image" depends on device tree for console initialization? > > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > > thanks > Manish > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 21 October 2020 00:10 > To: Ravi Kohli <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> > Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > NOTICE: Non-secure Partitioning Succeeded > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > INFO: bl31_platform_setup is called > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x80020000 > INFO: SPSR = 0x3c9 > INFO: BL31: DEBUG: image_type is: normal > > > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > Note, the same test image works fine using u-boot. > > Regards > Ravi > > > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: > > Hi Ravi, > > Have you tried to use RESET_TO_BL31 build option for your platform? > > Regards. > Alexei > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 07 October 2020 17:01 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: [TF-A] BL31 as bootloader > > Hi, > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > specify this container image with both bl31.bin and a separate custom app at a give flash address. > This is without any security requirements or dependencies. > > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > 0x80020000 address ? > > Thanks in advance. > Ravi > > > > -- > 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<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- 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<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 1 month

2
6
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Alexei Fedorov

Hi Javer, Please see my comments below. [3] Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. These hooks can be implemented in the next phase #2 of Measured Boot implementation. [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. It can also pass FW_CONFIG hash in the same DTB, but it is not clear how own TB_FW_CONFIG hash can be passed in itself. Stuart, do you have opinion on that? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 26 October 2020 10:25 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Questions raised about Measured Boot + fTPM test case Hi Raghu, Thank you very much for your comments and for your feedback. With regards to the (f)TPM service and as discussed during the last TF-A Tech Forum call, we will discuss internally the need of a new implementation, probably after the next TF-A release, and we will schedule the work (in case we decide to go ahead with it) for the upcoming months. We will announce any decision we make through the mailing list and/or on future TF-A Tech Forum calls . Regarding to changes to TF-A to include extra functionality/APIs/hooks, I guess my colleague Alexei can provide further details about the next features planned for Measured Boot, if any. To finish, I would just like to clarify one of the questions raised on your email: [1] Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. * Microsoft has a reference implementation of the TPM 2.0 specification. That implementation is in the form of an architecture agnostic library that implements the specification. Along with the library, there are a couple of example applications for different platforms built around the former, one of them being the fTPM we used for testing. That application was written for AARCH32 and seemed to be outdated (I don't know if it was abandoned, actually), so we updated it and added support for Measured Boot to it. Best regards, Javier -----Original Message----- From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> To: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com<mailto:'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Questions raised about Measured Boot + fTPM test case Date: Sun, 25 Oct 2020 14:31:10 -0700 Hi Javier, As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc: 1. Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks. 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A Sent: Friday, October 9, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Questions raised about Measured Boot + fTPM test case Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A