StandaloneMm: Remove hob creation in Arm

[LeviYeoReum]

Description

This patch series remove hob creation in Arm/StandaloneMmCoreEntryPoint. For this, This patch series includes: 1. Simplify standaloneMm entrypoint code for Arm 2. Replace CpuEntryPoint Hob with the protocol 3. Remove arm specific HobLib implementation used in StandaloneMmCore. 4. To support FF-A, add ArmFfaLib 5. Apply FF-A boot protocol for StandaloneMm 6. To apply booting with FF-A, use embedded stack for StandaloneMm because TF-A doesn't set stack for StandaloneMm

• [X] Breaking change

  1. This would work after TF-A patches which create hob for standaloneMm are applied (https://review.trustedfirmware.org/q/topic:%22hob_creation_in_tf_a%22)

  2. OpTee's stmm_sp.c should create hob to boot standaloneMm. However, It should be delivered NOT stmm_boot_info but via FF-A boot protocol with PHIT_HOB according to FF-A specification (https://developer.arm.com/documentation/den0077/j/?lang=en) In near futrue, I'll submit the FF-A patches which using FF-A boot protocol in StandaloneMm entrypoint. Until that Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc Wouldn't work.

How This Was Tested

Tested in Base FVP RevC platform by checking Boot and dumping uefi variables.

Integration Instructions

.

[ardbiesheuvel]

cc @apalos

Please asses the impact of these changes on the code in Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc in the edk2-platforms repo.

Also, please merge all patches that rename the MM #defines into a single one, so we don't break the build intermittently.

[LeviYeoReum]

Hi @ardbiesheuvel.

Please asses the impact of these changes on the code in Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc in the edk2-platforms repo.

Yes. It would break until I post the patchset related to FF-A boot protocol usage and it requires for optee to create phit hob using FF-A boot protocol.

I have a plan to FF-A boot protocol patch for edk2 in couple of week, and later I'll post the optee patch for this.

Also, please merge all patches that rename the MM #defines into a single one, so we don't break the build intermittently.

Thanks. I'll merge it

[apalos]

Hi @ardbiesheuvel.

Please asses the impact of these changes on the code in Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc in the edk2-platforms repo.

Yes. It would break until I post the patchset related to FF-A boot protocol usage and it requires for optee to create phit hob using FF-A boot protocol.

I have a plan to FF-A boot protocol patch for edk2 in couple of week, and later I'll post the optee patch for this.

I'd still like to understand a bit more how this affects the whole situation. Wouldn't that make certain versions of stmm incompatible with OP-TEE? Do we have a versioning field in there we could use and at least report an error message that makes sense?

Also, please merge all patches that rename the MM #defines into a single one, so we don't break the build intermittently.

Thanks. I'll merge it

[LeviYeoReum]

Hi @apalos.

I'd still like to understand a bit more how this affects the whole situation. Wouldn't that make certain versions of stmm incompatible with OP-TEE? Do we have a versioning field in there we could use and at least report an error message that makes sense?

Here is what I think:

optee	standaloneMm	Working	Comments
old	old	O	Legacy
new	old	X	load_stmm() in optee, doesn't set stack pointer. So as soon as enter standaloneMm, It will crash TA.
old	new	X	StandaloneMm check FF-A version, If it's under v1.2, StandaloneMm prints error message and fail to load TA.
new	new	O	.

Because, FF-A v1.2's. manifest doesn't have stack memory region for partition. So new standaloneMm set stack by itself.

For this. I think optee's stmm.c code should be modified with: - At the load, create Hob list and passes it with FF-A boot protocol - update stmm svc handler.

BTW, to confirm the optee modification, could you share me what is proper build command for TF-A / optee / u-boot for vexpress-fvp platform?

Thanks.

[apalos]

Hi @apalos.

I'd still like to understand a bit more how this affects the whole situation. Wouldn't that make certain versions of stmm incompatible with OP-TEE? Do we have a versioning field in there we could use and at least report an error message that makes sense?

Here is what I think: optee standaloneMm Working Comments old old O Legacy new old X load_stmm() in optee, doesn't set stack pointer. So as soon as enter standaloneMm, It will crash TA. old new X StandaloneMm check FF-A version, If it's under v1.2, StandaloneMm prints error message and fail to load TA. new new O .

Because, FF-A v1.2's. manifest doesn't have stack memory region for partition. So new standaloneMm set stack by itself.

Yes, that's what I assumed when I read the patches, thanks for the confirmation.

I don't personally mind if we remove the 1.0 variant, but this needs to be done properly and in coordination with OP-TEE. Parsing the FF-A version and not launching StMM if an older version is loaded is the bare minimum we should fix.

In any case, I'll ask around and see if anyone is affected by removing 1.0.

For this. I think optee's stmm.c code should be modified with: - At the load, create Hob list and passes it with FF-A boot protocol - update stmm svc handler.

BTW, to confirm the optee modification, could you share me what is proper build command for TF-A / optee / u-boot for vexpress-fvp platform?

I don't have anything for the FVP. I do keep a hacky branch that emulates an RPMB partition (in memory) for U-Boot though and you can test Get/Set variable from the bootloader. Just clone https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/, change your cross compiler in the build.sh script and run it. Once the build is done, the script will print a qemu cmd line for you to run. Once you reach the U-Boot consol do printenv -e .

Thanks.

[apalos]

@LeviYeoReum apologies, I missed that for some reason I am not getting github notifications... I'll have a look shorty, but did you manage to test this with the QEMU scripts I pasted above?

[LeviYeoReum]

@LeviYeoReum apologies, I missed that for some reason I am not getting github notifications... I'll have a look shorty, but did you manage to test this with the QEMU scripts I pasted above?

Hi @apalos. Sorry to late answer.

Yes, shared enviroments works for me and I've tested. And here is optee related patches: - https://github.com/OP-TEE/optee_os/pull/7086

Thanks!

[apalos]

@LeviYeoReum apologies, I missed that for some reason I am not getting github notifications... I'll have a look shorty, but did you manage to test this with the QEMU scripts I pasted above?

Hi @apalos. Sorry to late answer.

Yes, shared enviroments works for me and I've tested. And here is optee related patches: - OP-TEE/optee_os#7086

Thanks!

Thanks for working on this. I still can't compile the whole thing and https://github.com/tianocore/edk2-platforms/pull/209/files doesn't seem to apply cleanly.

Am I missing any other PR?

[LeviYeoReum]

@LeviYeoReum apologies, I missed that for some reason I am not getting github notifications... I'll have a look shorty, but did you manage to test this with the QEMU scripts I pasted above?

Hi @apalos. I've confirmed AARCH64 version with this PR and edk2-platform. And there is no problem to me. Could you share what error message you met?

Thanks

[nhivp]

Does this PR include an update for StandaloneMmPkg and MmCommunication to support FF-A 1.2? It does not sound relevant with the PR title.

[apalos]

@LeviYeoReum apologies, I missed that for some reason I am not getting github notifications... I'll have a look shorty, but did you manage to test this with the QEMU scripts I pasted above?

Hi @apalos. I've confirmed AARCH64 version with this PR and edk2-platform. And there is no problem to me. Could you share what error message you met?

Thanks

Ah you are right, I forgot to pull my edk2 repos before applying the patches. The only problem I see is that the patch in edk2-platforms doesnt apply cleanly, probably due to 7663e46925f382.

With this fixed up, the variables do indeed work

[LeviYeoReum]

Does this PR include an update for StandaloneMmPkg and MmCommunication to support FF-A 1.2? It does not sound relevant with the PR title.

Okay. I'll edit the title. thanks.

[samimujawar]

Thank you all for helping to review and test this series.

I believe the completion sequence for this series should be as follows:

1. @kuqin12 if you can help test the latest changes in your setup and confirm, it would be of great help.
2. @apalos If you can confirm that you are ok with this series, please?
3. If there is any other feedback then let's wait until mid next week i.e. 8 Jan 2025.
4. TF-A patches need to be merged (https://review.trustedfirmware.org/q/topic:%22hob_creation_in_tf_a%22)
5. As soon as TF-A patches are merged we should be in a position to merge this series.
6. The corresponding edk2-platforms series at https://github.com/tianocore/edk2-platforms/pull/209 can also be merged
7. Optee patches can then be merged by the Optee maintainers.

[kuqin12]

Thank you all for helping to review and test this series.

I believe the completion sequence for this series should be as follows:

1. @kuqin12 if you can help test the latest changes in your setup and confirm, it would be of great help.
2. @apalos If you can confirm that you are ok with this series, please?
3. If there is any other feedback then let's wait until mid next week i.e. 8 Jan 2025.
4. TF-A patches need to be merged (https://review.trustedfirmware.org/q/topic:%22hob_creation_in_tf_a%22)
5. As soon as TF-A patches are merged we should be in a position to merge this series.
6. The corresponding edk2-platforms series at ARM/VExpressPkg: Remove Hob creation in StandaloneMm. edk2-platforms#209 can also be merged
7. Optee patches can then be merged by the Optee maintainers.

Thanks for the update, @samimujawar. I tested this change with my local configuration, which has Hafnium as SPMC at S-EL2 and everything is functional as expected.

Tested-by: Kun Qin [email protected]

[samimujawar]

The TF-A patches have now been merged in the TF-A mainline at https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git/+log/refs/heads/master. If there are no further comments, I plan to merge this series on 17th Jan 2025.

[apalos]

@samimujawar apologies for the late reply, I was on vacation.

I plan to test this later today. The patches needed are this, the TF-A changes, the OP-TEE patches and https://github.com/tianocore/edk2-platforms/pull/209/commits right?

[LeviYeoReum]

Hi,

I plan to test this later today. The patches needed are this, the TF-A changes, the OP-TEE patches and https://github.com/tianocore/edk2-platforms/pull/209/commits right?

Yes it is, But because of 56dfab9a8a143aa486d07eafc3d5a78bff540228 which makes shadow copy for Boot firmware volume. It could be failed because of out of memory of heap.

For this, there is 2 options

• increase heap size which defined in stmm_sp.c of optee specified with stmm_heap_size
• applies below patch:
  • https://github.com/tianocore/edk2/pull/10642 and
  • on RPMB dsc with https://github.com/tianocore/edk2-platforms/pull/726

Thanks.

[LeviYeoReum]

@samimujawar apologies for the late reply, I was on vacation.

I plan to test this later today. The patches needed are this, the TF-A changes, the OP-TEE patches and https://github.com/tianocore/edk2-platforms/pull/209/commits right?

And here is my test result in Rpmb platform:

=> print -e
print -e
SetupMode:
    8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
    BS|RT|RO, DataSize = 0x1
    00000000: 01                                               .
SignatureSupport:
    8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
    BS|RT|RO, DataSize = 0x60
    00000000: 12 a5 6c 82 10 cf c9 4a b1 87 be 01 49 66 31 bd  ..l....J....If1.
    00000010: 26 16 c4 c1 4c 50 92 40 ac a9 41 f9 36 93 43 28  &[email protected](
    00000020: 07 53 3e ff d0 9f c9 48 85 f1 8a d5 6c 70 1e 01  .S>....H....lp..
    00000030: ae 0f 3e 09 c4 a6 50 4f 9f 1b d4 1e 2b 89 c1 9a  ..>...PO....+...
    00000040: e8 66 57 3c 9c 26 34 4e aa 14 ed 77 6e 85 b3 b6  .fW<.&4N...wn...
    00000050: a1 59 c0 a5 e4 94 a7 4a 87 b5 ab 15 5c 2b f0 72  .Y.....J....\+.r
SecureBoot:
    8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
    BS|RT|RO, DataSize = 0x1
    00000000: 00                                               .
certdbv:
    d9bee56e-75dc-49d9-b4d7-b534210f637a (d9bee56e-75dc-49d9-b4d7-b534210f637a)
    1970-01-01 00:00:01
    BS|RT|AT|RO, DataSize = 0x4
    00000000: 04 00 00 00                                      ....
AuditMode:
    8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
    BS|RT|RO, DataSize = 0x1
    00000000: 00                                               .
DeployedMode:
    8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
    BS|RT|RO, DataSize = 0x1
    00000000: 00                                               .
    ```

Thanks

[gmahadevan]

Description

This patch series remove hob creation in Arm/StandaloneMmCoreEntryPoint. For this, This patch series includes: 1. Simplify StandaloneMm entrypoint code for Arm 2. Replace CpuEntryPoint Hob with the protocol 3. Remove arm specific HobLib implementation used in StandaloneMmCore. 4. Support FF-A v1.2, add ArmFfaLib 5. Apply FF-A boot protocol for StandaloneMm 6. To apply booting with FF-A, use embedded stack for StandaloneMm because TF-A doesn't set stack for StandaloneMm 7. Apply FF-A Library in Mmcommunication Driver in Arm 8. StandaloneMm in Arm is UP migratable. Remove per-cpu feature 9. Support ExtractSectionLib for StandaloneMm. 10. Move StandaloneMmCoreEntryPoint & StandaloneMmCpu driver for Arm to ArmPkg.

• [x] Breaking change

  1. This would work after TF-A patches which create hob for standaloneMm are applied (https://review.trustedfirmware.org/q/topic:%22hob_creation_in_tf_a%22)
  2. OpTee's stmm_sp.c should create hob to boot standaloneMm. However, It should be delivered NOT stmm_boot_info but via FF-A boot protocol with PHIT_HOB according to FF-A specification (https://developer.arm.com/documentation/den0077/j/?lang=en) In near futrue, I'll submit the FF-A patches which using FF-A boot protocol in StandaloneMm entrypoint. Until that Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc Wouldn't work.

How This Was Tested

Tested in Base FVP RevC platform by checking Boot and dumping uefi variables.

Integration Instructions

.

Hello @LeviYeoReum Do you know of a PR/gerrit for changes to Hafnium? I mean for deployments where SPMC is at EL2, I am guessing Hafnium will be the one that sets up the HOBs for StMM.

Our deployment runs StMM where it is launched by Hafnium. The Image is built as a concatenation of the manifest+SP code and in the entry point we setup the HOB (by retrofitting the manifest info into the EFI_SECURE_PARTITION_BOOT_INFO structure first. We can try to adapt to this version where StMM gets the HOB from its loader if Hafnium is also doing something similar like TF-A.

Best Regards Girish