ArmPkg, MdePkg: drop SPM_MM support from edk2

[LeviYeoReum]

Description

Since TF-A v2.14, SPM_MM has been deprecated ([0], [1]).
Therefore, drop SPM_MM support in edk2.

Link: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/Z6GAD7OGKNDPNKECJ63HQZ4XEYUJXTNM/ [0]
Link: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/about/release-information.rst [1]

• Breaking change?
  • Breaking change - Does this PR cause a break in build or boot behavior?
  • Examples: Does it add a new library class or move a module to a different repo.
• Impacts security?
  • Security - Does this PR have a direct security impact?
  • Examples: Crypto algorithm change or buffer overflow fix.
• Includes tests?
  • Tests - Does this PR include any explicit test code?
  • Examples: Unit tests or integration tests.

How This Was Tested

Booting test in FVP

Integration Instructions

N/A

[ardbiesheuvel]

@apalos fyi

[apalos]

Thanks @ardbiesheuvel.
@LeviYeoReum how is this relevant to a TF-A decision? Isn't that going to completely break the EFI variable store on an RPMB via OP-TEE? If so I don't think we can just get rid of it. There's a few companies using it already and there's no alternative that they can replace it with.

The Arm SP that plans to replace this is also missing Linux kernel patches to enable SetVariable at Runtime which is needed by distros.

[os-d]

Thanks @ardbiesheuvel. @LeviYeoReum how is this relevant to a TF-A decision? Isn't that going to completely break the EFI variable store on an RPMB via OP-TEE? If so I don't think we can just get rid of it. There's a few companies using it already and there's no alternative that they can replace it with.

Agreed. I'm fully supportive of deprecating SPM_MM and all new products using FF-A; that is the right direction. But there are recently shipped platforms using SPM_MM and we need to be able to service them for years to come. If the support is stripped in edk2, we cannot do that.

I'll note that your first link also indicates long term support for SPM_MM:

The SPM-MM implementation would continue to be supported in LTS branches maintained for 7 years.

In edk2, the long term support branch is master, for better or worse. I would propose creating a similar plan for supporting SPM_MM in edk2's mainline for a number of years, but marking it as deprecated (or at least documenting) and eventually drop the support.

[LeviYeoReum]

Hi @apalos and @os-d

Thanks @ardbiesheuvel. @LeviYeoReum how is this relevant to a TF-A decision? Isn't that going to completely break the EFI variable store on an RPMB via OP-TEE? If so I don't think we can just get rid of it. There's a few companies using it already and there's no alternative that they can replace it with.

The Arm SP that plans to replace this is also missing Linux kernel patches to enable SetVariable at Runtime which is needed by distros.

AFAIK, RPMB via OP-TEE doesn't use the SPM_MM but use FF-A direct message.

• https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/stmm_sp.c#L524
  So, I think that wouldn't a problem for RPMB platform.

Also, There is no SPM_MM interface relavant specificaiton but it was TF-A's interface definition
(https://trustedfirmware-a.readthedocs.io/en/v2.14.0/components/secure-partition-manager-mm.html)

So, If TF-A determines to deprecate it, It should deprecate otherwise, I'm afraid of adding a service or platform to using SPM_MM based.

Additionally, in case of linux kernel side, user of MM_COMM is only Stmm which runs with optee RPBM AFAIK.
Moreover, kernel side, since it calls via SetVariable runtime service, kernel doesn't need to know what is backend side implementation (FF-A or SPM_MM) Doesn't it?

But there are recently shipped platforms using SPM_MM and we need to be able to service them for years to come.

That is what i afraid of...

In edk2, the long term support branch is master, for better or worse. I would propose creating a similar plan for supporting SPM_MM in edk2's mainline for a number of years, but marking it as deprecated (or at least documenting) and eventually drop the support.

@samimujawar, If recently some of platform is shipped using SPM_MM I think we couldn't drop the SPM_MM support rihgt now, But we need to think as @os-d suggested.

What do you think?

[kuqin12]

@samimujawar, If recently some of platform is shipped using SPM_MM I think we need to drop the SPM_MM support rihgt now, But we need to think as @os-d suggested.

What do you think?

Agree with @os-d and @apalos. At present, TFA releases are owned by silicon vendors, whereas OEMs can build their own UEFI. Introducing a breaking change as such would effectively block OEMs from updating their edk2 base until a corresponding TFA update is available. While avoiding updates may reduce short‑term effort, it risks undermining the long‑term health of the ecosystem.

[apalos]

Hi @apalos and @os-d

Thanks @ardbiesheuvel. @LeviYeoReum how is this relevant to a TF-A decision? Isn't that going to completely break the EFI variable store on an RPMB via OP-TEE? If so I don't think we can just get rid of it. There's a few companies using it already and there's no alternative that they can replace it with.
The Arm SP that plans to replace this is also missing Linux kernel patches to enable SetVariable at Runtime which is needed by distros.

AFAIK, RPMB via OP-TEE doesn't use the SPM_MM but use FF-A direct message.

IIRC it the FF-A messaging in only limited to the RPMB read/write ops. SPM is still needed to communicate with StMM. Unless something changed recently and I missed it.

• https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/stmm_sp.c#L524
  So, I think that wouldn't a problem for RPMB platform.

Also, There is no SPM_MM interface relavant specificaiton but it was TF-A's interface definition (https://trustedfirmware-a.readthedocs.io/en/v2.14.0/components/secure-partition-manager-mm.html)

So, If TF-A determines to deprecate it, It should deprecate otherwise, I'm afraid of adding a service or platform to using SPM_MM based.

As I said I am fine deprectating, but only when we have an SP that's on par with the current solution for UEFI

Additionally, in case of linux kernel side, user of MM_COMM is only Stmm which runs with optee RPBM AFAIK. Moreover, kernel side, since it calls via SetVariable runtime service, kernel doesn't need to know what is backend side implementation (FF-A or SPM_MM) Doesn't it?

But there are recently shipped platforms using SPM_MM and we need to be able to service them for years to come.

That is what i afraid of...

In edk2, the long term support branch is master, for better or worse. I would propose creating a similar plan for supporting SPM_MM in edk2's mainline for a number of years, but marking it as deprecated (or at least documenting) and eventually drop the support.

@samimujawar, If recently some of platform is shipped using SPM_MM I think we couldn't drop the SPM_MM support rihgt now, But we need to think as @os-d suggested.

What do you think?

[LeviYeoReum]

Hi @apalos and @os-d

Thanks @ardbiesheuvel. @LeviYeoReum how is this relevant to a TF-A decision? Isn't that going to completely break the EFI variable store on an RPMB via OP-TEE? If so I don't think we can just get rid of it. There's a few companies using it already and there's no alternative that they can replace it with.
The Arm SP that plans to replace this is also missing Linux kernel patches to enable SetVariable at Runtime which is needed by distros.

AFAIK, RPMB via OP-TEE doesn't use the SPM_MM but use FF-A direct message.

IIRC it the FF-A messaging in only limited to the RPMB read/write ops. SPM is still needed to communicate with StMM. Unless something changed recently and I missed it.

Just for confirmation.
I think I miss something for RPMB platform. AFAIK, it'll work with optee and StandaloneMm is just TA application in RPMB.
Do you mean BL31 loads OPTEE (S-EL1, BL32) via SPM_MM?
If so, I don't think this is not a problem since the TA app for StandaloneMm is loaded according to FF-A boot protocol.

[...]

[apalos]

Hi @apalos and @os-d

Thanks @ardbiesheuvel. @LeviYeoReum how is this relevant to a TF-A decision? Isn't that going to completely break the EFI variable store on an RPMB via OP-TEE? If so I don't think we can just get rid of it. There's a few companies using it already and there's no alternative that they can replace it with.
The Arm SP that plans to replace this is also missing Linux kernel patches to enable SetVariable at Runtime which is needed by distros.

AFAIK, RPMB via OP-TEE doesn't use the SPM_MM but use FF-A direct message.

IIRC it the FF-A messaging in only limited to the RPMB read/write ops. SPM is still needed to communicate with StMM. Unless something changed recently and I missed it.

Just for confirmation. I think I miss something for RPMB platform. AFAIK, it'll work with optee and StandaloneMm is just TA application in RPMB. \

It's not a TA, it looks like one. The stmm_sp.c is responsible for launching it and it's completely sandboxed from the rest of the system (including TAs)

Do you mean BL31 loads OPTEE (S-EL1, BL32) via SPM_MM? If so, I don't think this is not a problem since the TA app for StandaloneMm is loaded according to FF-A boot protocol.

No. Looking at the optee history your commit (OP-TEE/optee_os@aa6d7fc) changed the MM parts I was worried about.
Specifically ARM_SMC_MM_RET_NOT_SUPPORTED, ARM_SMC_MM_RET_NOT_SUPPORTED etc are not used anymore in optee. However, they are still defined in stmm_sp.h (i'll send a patch to remove them).

With this change in edk2 though you also need

diff --git a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
index dfe758fd8a48..339d1b0c66ac 100644
--- a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
+++ b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
@@ -16,7 +16,7 @@
 #include <Library/PcdLib.h>

 #include <IndustryStandard/ArmFfaSvc.h>
-#include <IndustryStandard/ArmMmSvc.h>
 #include <Protocol/FirmwareVolumeBlock.h>
 #include <Protocol/SmmFirmwareVolumeBlock.h>
 #include <Guid/VariableFormat.h>

in edk2-platforms

[...]