Hafnium August 2021

hafnium@lists.trustedfirmware.org

3 participants
3 discussions

TF-A Tech Forum Agenda: Thu 12th August 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 12th August 2021 16:00 – 17:00 (BST). Agenda: * Enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE – Presented by Raghupathy Krishnamurthy * Summary: Present and discuss enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE. The goal is to present an ARM server centric view point on the requirements in Secure World, the solution space explored to meet these requirements and why/how FF-A S-EL0 partition on hafnium using FEAT_VHE appear to fit these requirements. 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: 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 on the TF-A mailing list. 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>. Thanks Joanna

2 years, 8 months

Re: [Hafnium] Bug in hftest.py

by Olivier Deprez

Hi Raghu, Thanks for reporting. This part of the test infrastructure (testing the SPMC) is still very fresh and requires improvement iterations so please bear with us. Also a reason it's not yet part of the automated non-regression with jenkins (as opposed to the legacy kokoro/test.sh). For the time being we still mostly rely on the TF-A CI for testing on the secure side. IIUC this change was made to help with the test time as the FVP takes long to reload on every test. But indeed it might have the side effect you describe. So either we revert the FVP reloading on every test. Or another (somewhat hackish) possibility is to clear the mentioned variables from within the test (or make them part of BSS)? To be fair, the both worlds test scenario is not 100% stable on my machine (for some reason the connection is not always successful between the FVP and hftest) hence limiting confidence/robustness of my testing and investigations. So I wonder is the scripting is still somewhat a bit fragile. Regards, Olivier. ________________________________________ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 03 August 2021 23:47 To: 'Raghu Krishnamurthy via Hafnium' Subject: [Hafnium] Bug in hftest.py Hi All, Wanted to report to you that commit 18a25f9241f86ba2d637011ff465ce3869e8651b in hafnium "appears" broken. The issue with the optimization in this patch is that the partition images are not reloaded for each test run, which means a previous test could have written data to say SRAM, and the following test would use the old values from the previous test, when the same image is executed again from SRAM for a following test. This would be a problem for pretty much anything in the data section of a partition. In my case, I have a counter in the data section of my partition, which does not get reset back to its original value. I've attached a patch to help repro the issue. Fix is to disable the optimization or somehow reload the images for each run. This affects only "both world" tests. Let me know if I'm missing something here. Apply patch and run timeout --foreground 300s ./test/hftest/hftest.py --out_partitions out/reference/secure_aem_v8a_fvp_vm_clang --log out/reference/kokoro_log --spmc out/reference/secure_aem_v8a_fvp_clang/hafnium.bin --driver=fvp --hypervisor out/reference/aem_v8a_fvp_clang/hafnium.bin --partitions_json test/vmapi/ffa_secure_partitions/ffa_both_world_partitions_test.json The command line is from kokoro/test_spmc.sh. Thanks Raghu -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium

2 years, 8 months

Bug in hftest.py

by raghu.ncstate＠icloud.com

Hi All, Wanted to report to you that commit 18a25f9241f86ba2d637011ff465ce3869e8651b in hafnium "appears" broken. The issue with the optimization in this patch is that the partition images are not reloaded for each test run, which means a previous test could have written data to say SRAM, and the following test would use the old values from the previous test, when the same image is executed again from SRAM for a following test. This would be a problem for pretty much anything in the data section of a partition. In my case, I have a counter in the data section of my partition, which does not get reset back to its original value. I've attached a patch to help repro the issue. Fix is to disable the optimization or somehow reload the images for each run. This affects only "both world" tests. Let me know if I'm missing something here. Apply patch and run timeout --foreground 300s ./test/hftest/hftest.py --out_partitions out/reference/secure_aem_v8a_fvp_vm_clang --log out/reference/kokoro_log --spmc out/reference/secure_aem_v8a_fvp_clang/hafnium.bin --driver=fvp --hypervisor out/reference/aem_v8a_fvp_clang/hafnium.bin --partitions_json test/vmapi/ffa_secure_partitions/ffa_both_world_partitions_test.json The command line is from kokoro/test_spmc.sh. Thanks Raghu

2 years, 8 months

2024

2023

2022

2021

2020

Hafnium August 2021