- TF-A - lists.trustedfirmware.org

[RFC] Realm Management Extension (RME) patches

by Zelalem Aweke

Hi All, We have upstreamed TF-A patches for Arm Realm Management Extension (RME) feature at: https://review.trustedfirmware.org/q/topic:%22za%252Ffeat_rme%22+(status:op…. Any reviews/comments are very much appreciated 🙂 RME is an Armv9-A extension and is one component of the Arm Confidential Compute Architecture (Arm CCA)<https://www.arm.com/why-arm/architecture/security-features/arm-confidential…>. The major changes with this extension include: * Two additional Security states, Root and Realm * Two additional physical address spaces, Root and Realm * The ability to dynamically transition memory granules between physical addresses spaces * Granule Protection Check mechanism More information about RME and Arm CCA can be found at [1] and [2]. [1] https://developer.arm.com/documentation/ddi0615/latest [2] https://developer.arm.com/documentation/den0125/latest Thanks, Zelalem

4 years, 1 month

1
0
0 0

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

4 years, 1 month

1
0
0 0

Re: [TF-A] TRNG SMCs intercepted by SPM-MM

by Olivier Deprez

Hi Andrew, I have submitted the change as you have passed it through the ML as a base for the discussion. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/11002 The issue is acknowledged, we had a brief discussion internally as to how best to refactor if need be. It looks to us the main problem is that SPM-MM (pre-dating FF-A) has aged a bit and mixes standard and impdef func ids. e.g. MM is an Arm standard and only defines two func ids (0x84000040, 0x84000041) so it may just be a matter of updating SPM_MM_FID_MAX_VALUE to 0x41 such that MM related services go through. The other ids 0xX4000060, 61, 64, 65 are purely impdef for the SPM-MM to/from SP communication. Thus we may define SP_MM_FID_MIN_VALUE/SP_MM_FID_MAX_VALUE and a corresponding is_sp_mm_fid macro. This would avoid the clash with TRNG IDs (0xX4000050, 51, 52, 53). What do you reckon? Btw out of curiosity how did you discover this? Do you have a setup enabling both SPM_MM and TRNG_SUPPORT option? Or maybe this is because of Trusty SPD reuse of spm_mm_smc_handler? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 04 August 2021 22:50 To: Manish Pandey2 Cc: tf-a(a)lists.trustedfirmware.org; Jimmy Brisson; Andre Przywara Subject: Re: [TF-A] TRNG SMCs intercepted by SPM-MM I'm seeing server errors when I try "Generate Password" or setting the ssh key so I'm not sure how to push and authenticate. I've sent the patch directly to you, Manish, so the formatting doesn't get messed up and I don't know how to make git-send-email add it to a thread nicely.. On Wed, 4 Aug 2021 at 05:51, Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: Hi Andrew, Thanks for reporting the bug, "DEN0060A_ARM_MM_Interface_Specification.pdf" does not talk about range for SPM_MM but don't know how it's mentioned in the comments. Will you be able to push a patch following instructions at https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… 5. Contributor’s Guide — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm…> 5. Contributor’s Guide¶ 5.1. Getting Started¶. Make sure you have a Github account and you are logged on both developer.trustedfirmware.org<http://developer.trustedfirmware.org> and review.trustedfirmware.org<http://review.trustedfirmware.org>. If you plan to contribute a major piece of work, it is usually a good idea to start a discussion around it on the mailing list. trustedfirmware-a.readthedocs.io<http://trustedfirmware-a.readthedocs.io> Repository: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a , you will be able to login to gerrit using github credentials. TF-A/trusted-firmware-a · Gerrit Code Review<https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a> Gerrit Code Review review.trustedfirmware.org<http://review.trustedfirmware.org> If not, then could you please send me the patch file (it appears copying directly from email generates corrupt patch file) Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 03 August 2021 22:32 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>> Cc: Andre Przywara <Andre.Przywara(a)arm.com<mailto:Andre.Przywara@arm.com>>; Jimmy Brisson <Jimmy.Brisson(a)arm.com<mailto:Jimmy.Brisson@arm.com>> Subject: [TF-A] TRNG SMCs intercepted by SPM-MM I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com<mailto:ascull@google.com>> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 1 month

2
2
0 0

Re: [TF-A] TRNG SMCs intercepted by SPM-MM

by Manish Pandey2

Hi Andrew, Thanks for reporting the bug, "DEN0060A_ARM_MM_Interface_Specification.pdf" does not talk about range for SPM_MM but don't know how it's mentioned in the comments. Will you be able to push a patch following instructions at https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… 5. Contributor’s Guide — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm…> 5. Contributor’s Guide¶ 5.1. Getting Started¶. Make sure you have a Github account and you are logged on both developer.trustedfirmware.org and review.trustedfirmware.org. If you plan to contribute a major piece of work, it is usually a good idea to start a discussion around it on the mailing list. trustedfirmware-a.readthedocs.io Repository: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a , you will be able to login to gerrit using github credentials. TF-A/trusted-firmware-a · Gerrit Code Review<https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a> Gerrit Code Review review.trustedfirmware.org If not, then could you please send me the patch file (it appears copying directly from email generates corrupt patch file) Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 August 2021 22:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Andre Przywara <Andre.Przywara(a)arm.com>; Jimmy Brisson <Jimmy.Brisson(a)arm.com> Subject: [TF-A] TRNG SMCs intercepted by SPM-MM I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 1 month

2
1
0 0

TRNG SMCs intercepted by SPM-MM

by Andrew Scull

I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog

4 years, 1 month

1
0
0 0

Issue with Xilinx ZynqMP FPGA loading with ATF v2.5

by Robert Hancock

After updating to ATF v2.5 on the Xilinx ZynqMP platform, I was having issues with the FPGA PL logic not loading successfully from U-Boot, it was failing with this error: PL FPGA LOAD failed with err: 0x000007d6 which is PM_RET_ERROR_TIMEOUT. The following commit introduced the timeout: commit 4d9b9b2352f9a67849faf2d4484f5fcdd2788b01 Author: Tejas Patel <tejas.patel(a)xilinx.com> Date: Thu Feb 25 02:37:09 2021 -0800 plat: xilinx: Add timeout while waiting for IPI Ack Return timeout error if, IPI is not acked in specified timeout. Signed-off-by: Tejas Patel <tejas.patel(a)xilinx.com> Change-Id: I27be3d4d4eb5bc57f6a84c839e2586278c0aec19 The timeout value (TIMEOUT_COUNT_US) is set to 0x4000 (16384) usec, which appears to be too short for the FPGA loading operation (at least on the ZCU102 board with XCZU9EG device), causing it to always timeout. Increasing the timeout to 0xF4240 usec (i.e. 1 second) fixes the issue, though some lower value may also be sufficient. -- Robert Hancock Senior Hardware Designer, Calian Advanced Technologies www.calian.com

4 years, 1 month

1
0
0 0

Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset"

by raghu.ncstate＠icloud.com

>> Our initial ask was to only bump the SP image entrypoint past the DTB boundary while generating SP.pkg using sptool. IIUC, the issue you brought up is for passing the manifest base address to the SP at runtime. I think these two are independent issues. Please advise. [RK] Agree here. Passing information through the manifest to the SP is orthogonal to the main problem at hand where we are assuming that the size of manifest cannot be > 4K and the entrypoint offset is always at 0x100. -Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, June 22, 2021 7:35 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hi Olivier, >> [OD] The two questions are which entity is loading boot data (can be a DT blob) that is to be consumed by the SP? And how is the address for boot data conveyed to the SP? The SP manifest is made for the SPMC consumption. I guess it's ok to conflate DT information required by the SP into the SP manifest. It means the bootloader loads both the SP manifest and the SP boot data in a single "SP package". In current implementation the SP has no standard way to know where the DT blob is loaded in its own memory range. We have experimental patches around the FF-A boot protocol which may help. [VW] You are right - bootloader loads SP.pkg (header+manifest+image) into memory. Can you please help me understand what "SP boot data" contains? For passing the SP manifest pointer to the SP we should ask for ideas from the community. Some ideas to get the discussion started: 1. SPMC creates a mapping for the manifest in the SP's virtual address space. SP issues a SVC call to get the virtual address from the SPMC 2. SPMC creates a mapping for the manifest in the SP's virtual address space and passes the pointer to SP via X0 3. SP manifest contains an entry to publish the virtual address for its manifest. SPMC reads this entry and maps the manifest at that virtual address during boot. >> [OD] If the assumptions (implementation defined) are that the SP boot data fits into the SP manifest, and that the SP finds this data at a fixed address (e.g. offset 0 in the SP package) then yes it can be a way to go. [VW] Our initial ask was to only bump the SP image entrypoint past the DTB boundary while generating SP.pkg using sptool. IIUC, the issue you brought up is for passing the manifest base address to the SP at runtime. I think these two are independent issues. Please advise. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Tuesday, June 22, 2021 8:17 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, (sorry last message sent too fast) See few comments inline [OD]. Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 17 June 2021 12:33 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" Hi, >> [OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard. [VW] We don't have a policy for all SPs, yet. At least I don't know of one. But in our experimental setup we plan to work on some assumptions e.g. assume the manifest blob to always be present at a certain address. [OD] The two questions are which entity is loading boot data (can be a DT blob) that is to be consumed by the SP? And how is the address for boot data conveyed to the SP? The SP manifest is made for the SPMC consumption. I guess it's ok to conflate DT information required by the SP into the SP manifest. It means the bootloader loads both the SP manifest and the SP boot data in a single "SP package". In current implementation the SP has no standard way to know where the DT blob is loaded in its own memory range. We have experimental patches around the FF-A boot protocol which may help. >> [OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex. [VW] Can we list down the next steps? Do we agree in principle that sptool needs to be upgraded to handle this use case? We can collaborate on an implementation, once we agree on the direction. [OD] If the assumptions (implementation defined) are that the SP boot data fits into the SP manifest, and that the SP finds this data at a fixed address (e.g. offset 0 in the SP package) then yes it can be a way to go. Cheers. -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Thursday, June 17, 2021 8:40 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, Few comments [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 16 June 2021 14:37 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" Hi, >> Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI. [VW] Thanks for the heads up. >> what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself? [VW] We can assume tens of KB. In the worst case, a few hundred KB. The manifest is targeted towards the SP and not meant for Hafnium. Just curious, do you see any pitfalls? [OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard. >> To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there. [VW] Thanks for the links. I will review and leave comments - although we are not looking at introducing yet another script. [OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex. Cheers. -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, June 16, 2021 12:59 PM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, See inline [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 16 June 2021 13:07 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" HI Olivier, >> [OD] Just to be clear, is this about SEL0 partitions using an SEL1 >> shim No, this issue can be seen even without the shim. I don't think the usage of shim or VHE really matters here. [OD] All right. Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI. Not an issue as such but just making sure you have the full picture. At some point in time, when Hf VHE changes are merged we can create a specific TF-A test config to cover this case if necessary. Out of curiosity what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself? >> [OD] This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. I agree, this approach is good for the short term. But I propose we craft a forward-looking solution. Are you planning on merging the sptool patch[1]? If not, I propose we come up with a way to dynamically update the SP manifest - I understand this involves adding libfdt to update the manifest. [OD] There is no pressing need to merge [1] in the short term so this can wait for a better solution. To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there. -Varun [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, June 16, 2021 11:42 AM To: tf-a(a)lists.trustedfirmware.org; Nicolas Benech <nbenech(a)nvidia.com> Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Varun Wadekar <vwadekar(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi, See few comments inline [OD] Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 16 June 2021 11:41 To: tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hello, We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms [OD] Just to be clear, is this about SEL0 partitions using an SEL1 shim (as per https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… )? and recently hit an issue, where the "entrypoint-offset" field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the "entrypoint-offset" field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the "entrypoint-offset", we must manually update it. This needs to be fixed. We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the "entrypoint-offset" past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal. Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling. [OD] We had an attempt (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…) to move the entry point farther in the image such that we can support 64KB granules in the Stage-1 translation regime. This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. Cheers. [1] 14. FF-A manifest binding to device tree - Trusted Firmware-A documentation<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfi…> -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 1 month

4
11
0 0

Re: [TF-A] A Q about TZ porting guide

by Manish Pandey2

Hi Boaz, It appears that you have included plat/arm files in your platform porting which is causing Arm platform function definition to be included. Along with providing generic implementations Arm also has its own platforms(like any other partner platforms), code under plat/arm is meant only for Arm platforms. Check your make file and make sure that you don't include plat/arm/common/arm_pm.c(to avoid plat_setup_psci_ops) and plat/arm/common/aarch64/arm_helpers.S(for other functions you mentioned) this will avoid multiple definition errors. Hope this helps thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of IS20 Boaz Baron via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 July 2021 09:12 To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; IN20 Hila Miranda-Kuzi <Hila.Miranda-Kuzi(a)nuvoton.com> Subject: Re: [TF-A] A Q about TZ porting guide Also, those functions aren’t defined as WEAK so I encountered the same problem (multiple definitions) plat_crash_console_putc plat_crash_console_flush platform_mem_init From: IS20 Boaz Baron Sent: Thursday, July 29, 2021 10:14 AM To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org; IN20 Hila Miranda-Kuzi <Hila.Miranda-Kuzi(a)nuvoton.com> Subject: RE: [TF-A] A Q about TZ porting guide Thanks Madhukar for your answer, I think I wasn’t so clear. plat_setup_psci_ops is listed as mandatory in the porting guide. I implemented it locally but linkage fails because it is also defined in arm_pm.c. How do you suggest to avoid this multiple definition? Thanks, Boaz. From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com<mailto:Madhukar.Pappireddy@arm.com>> Sent: Wednesday, July 28, 2021 10:44 PM To: IS20 Boaz Baron <boaz.baron(a)nuvoton.com<mailto:boaz.baron@nuvoton.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] A Q about TZ porting guide Hi Boaz Yes, plat_setup_psci_ops() is mandatory. Every platform needs to implement it independently. You can use the implementation from [1] as a reference. I don’t think you have to delete any original function. If your platform does not support PSCI spec, you can implement a dummy function. Hope it helps. int plat_setup_psci_ops(uintptr_t sec_entrypoint, const plat_psci_ops_t **psci_ops) { return 0; } [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/c…<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> Thanks, Madhukar From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of IS20 Boaz Baron via TF-A Sent: Wednesday, July 28, 2021 7:58 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] A Q about TZ porting guide Hi all, I have a Q about plat_setup_psci_ops() function implementation , In the porting guide, that function is defined as mandatory BUT the original (arm) function isn’t defined as #pargam WEAK. what should I do? to use/ delete the original function? Thanks, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years, 1 month

1
0
0 0

Re: [TF-A] A Q about TZ porting guide

by Madhukar Pappireddy

Hi Boaz Yes, plat_setup_psci_ops() is mandatory. Every platform needs to implement it independently. You can use the implementation from [1] as a reference. I don't think you have to delete any original function. If your platform does not support PSCI spec, you can implement a dummy function. Hope it helps. int plat_setup_psci_ops(uintptr_t sec_entrypoint, const plat_psci_ops_t **psci_ops) { return 0; } [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/c… Thanks, Madhukar From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of IS20 Boaz Baron via TF-A Sent: Wednesday, July 28, 2021 7:58 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] A Q about TZ porting guide Hi all, I have a Q about plat_setup_psci_ops() function implementation , In the porting guide, that function is defined as mandatory BUT the original (arm) function isn't defined as #pargam WEAK. what should I do? to use/ delete the original function? Thanks, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years, 1 month

2
2
0 0

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

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 29th July 2021 16:00 – 17:00 (BST). Agenda: * Firmware Update Discussions - Led by Manish Badarkhe * A brief overview of firmware update mechanism as per firmware update specification release https://developer.arm.com/documentation/den0118/a/ (Version1.0 BET0). * Discuss TF-A BL2 involvement in the firmware update operation. [Patches for this work are in review: https://review.trustedfirmware.org/q/topic:%22fw-update-2%22+(status:open%2…] * Discuss existing firmware update mechanisms in the partner platforms and if any challenges to adapt to this firmware update specification. 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

4 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A