Hi All,


We are working on enabling the Secure Storage of Variables for Secure UEFI.

Let me give you a brief idea of what we are doing.



We need StandAlone Management Mode to run in the Secure Environment.

For that in EDK2 we already have the MmCommunicationDxe Runtime Driver
which communicates with StMM running in Secure Partition in Secure World.

But this driver is based on SPM (Secure Partition Manager) running in the
ATF.



As we are aware that ATF can run either in SPM mode or SPD mode, Both are
mutually exclusive.

So we cannot have both the StMM running in Secure Partition as well as
OP-TEE or any other Secure OS running in Secure World.



On many systems, there are many other secure operations needed to be done
that can be done by Secure OS only.

So in these systems we need to make the StMM and Secure OS work together.



As part of doing this only, we have created a kind of Secure Partition
within OP-TEE in which StMM can work as a kind of TA, and other TAs cannot
interfere with the working of this Secure Partition.

Other TAs can run in parallel to StMM on top of OP-TEE, We can get the work
done by StMM by OP-TEE SMC calls only.

It will be like this as shown in the below image.



Secure World

+-----------------------------------------------------------+

| +-----------------------+ +------------------------+ |

| | | | +--------------------+ | |

| | | | | | | |

| | Trusted Application | | | | | |

| | | | | | | |

| | | | | StMM | | |

| +-----------------------+ | | | | |

| | | | | |

| | | | | |

| | +--------------------+ | |

| | | |

| OP-TEE | | |

| | | |

| | Secure Partition | |

| | | |

| | | |

| | | |

| +------------------------+ |

+-----------------------------------------------------------+



So with this approach of running StMM in an exclusive secure partition with
OP-TEE, StMM and TAs can work together.

In this way StMM binary which is compiled is also environment-agnostic,
Same StMM binary can work whether it is running as part of OP-TEE or
Standalone in Secure Word.

If OP-TEE is responsible for running StMM, firmware implementations, like
U-Boot, can use it to store UEFI variables.


Now for implementing the whole system of Secure Variable Storage for Secure
UEFI.



We need to make changes in MmCommunicationDxe Runtime Driver and OpteeLib

Let's discuss one by one the changes:

- MmCommunicationDxe – Currently it is based on SPM SMC calls that get
landed into ATF and do the required work.
- Now since StMM is running as part of OP-TEE, we need to change
these into OP-TEE SMC calls.
- OpteeLib – Currently OpteeLib cannot be used with the Runtime Drivers.
- We need to change its configuration so that it can be used with a
Runtime Driver.



So for making these changes we have following approaches:

- MmCommunicationDxe
- We can have the code for SPM SMC calling and OPTEE SMC calling in
the same driver under some compile time flags, but it will make the code
nasty.
- Another approach can be writing a new driver under the name of
MmCommunicationOpteeDxe in ArmPkg/Drivers/.
- OpteeLib
- We can make necessary changes to make it work with Runtime Driver.
- Other approach we can make Runtime Driver of Optee also in
ArmPkg/Drivers/



So please review the mail and approaches for making the changes and let us
know your views.


Regards,

Sahil Malhotra

Sorry for garbled ASCII diagram, Attached the image here.

Thanks
Sahil

Hi Ard,

Thanks for taking out time to review the proposal.

Please find my comments inline with *[Sahil]*

I'd prefer a separate MmCommunicationOpteeDxe driver, and an updated
OpteeLib that can be used both at boot time and at runtime.
*[Sahil] - Thanks for your input, will work accordingly and send an RFC
soon.*

So I would assume such an approach would permit any standalone MM driver
to be incorporated into the secure side payload, and be invoked using
MmCommunicate as usual?
*[Sahil] - Yes, you are right.*

Regards,
Sahil Malhotra

On Mon, 18 May 2020 at 14:27, Ard Biesheuvel <ard.biesheuvel@...> wrote:

On 5/18/20 10:53 AM, Ilias Apalodimas wrote:

+cc Ard


On Thu, 14 May 2020 at 17:57, Sahil Malhotra <sahil.malhotra@...
<mailto:sahil.malhotra@...>> wrote:

Hi All,


We are working on enabling the Secure Storage of Variables for
Secure UEFI.

Let me give you a brief idea of what we are doing.

We need StandAlone Management Mode to run in the Secure Environment.

For that in EDK2 we already have the MmCommunicationDxe Runtime
Driver which communicates with StMM running in Secure Partition in
Secure World.

But this driver is based on SPM (Secure Partition Manager) running
in the ATF.

As we are aware that ATF can run either in SPM mode or SPD mode,
Both are mutually exclusive.

So we cannot have both the StMM running in Secure Partition as well
as OP-TEE or any other Secure OS running in Secure World.

On many systems, there are many other secure operations needed to be
done that can be done by Secure OS only.

So in these systems we need to make the StMM and Secure OS work
together.

As part of doing this only, we have created a kind of Secure
Partition within OP-TEE in which StMM can work as a kind of TA, and
other TAs cannot interfere with the working of this Secure

Partition.

Other TAs can run in parallel to StMM on top of OP-TEE, We can get
the work done by StMM by OP-TEE SMC calls only.

It will be like this as shown in the below image.

Secure World

+-----------------------------------------------------------+

| +-----------------------+ +------------------------+ |

| | | | +--------------------+ | |

| | | | | | | |

| | Trusted Application | | | | | |

| | | | | | | |

| | | | | StMM | | |

| +-----------------------+ | | | | |

| | | | | |

| | | | | |

| | +--------------------+ | |

| | | |

| OP-TEE | | |

| | | |

| | Secure Partition | |

| | | |

| | | |

| | | |

| +------------------------+ |

+-----------------------------------------------------------+

So with this approach of running StMM in an exclusive secure
partition with OP-TEE, StMM and TAs can work together.

In this way StMM binary which is compiled is also
environment-agnostic, Same StMM binary can work whether it is
running as part of OP-TEE or Standalone in Secure Word.

If OP-TEE is responsible for running StMM, firmware implementations,
like U-Boot, can use it to store UEFI variables.


Now for implementing the whole system of Secure Variable Storage for
Secure UEFI.

We need to make changes in MmCommunicationDxe Runtime Driver and
OpteeLib

Let's discuss one by one the changes:

* MmCommunicationDxe – Currently it is based on SPM SMC calls that
get landed into ATF and do the required work.
o Now since StMM is running as part of OP-TEE, we need to
change these into OP-TEE SMC calls.
* OpteeLib – Currently OpteeLib cannot be used with the Runtime
Drivers.
o We need to change its configuration so that it can be used
with a Runtime Driver.

So for making these changes we have following approaches:

* MmCommunicationDxe
o We can have the code for SPM SMC calling and OPTEE SMC
calling in the same driver under some compile time flags,
but it will make the code nasty.
o Another approach can be writing a new driver under the name
of MmCommunicationOpteeDxe in ArmPkg/Drivers/.
* OpteeLib
o We can make necessary changes to make it work with Runtime
Driver.
o Other approach we can make Runtime Driver of Optee also in
ArmPkg/Drivers/

So please review the mail and approaches for making the changes and
let us know your views.

I'd prefer a separate MmCommunicationOpteeDxe driver, and an updated
OpteeLib that can be used both at boot time and at runtime.

So I would assume such an approach would permit any standalone MM driver
to be incorporated into the secure side payload, and be invoked using
MmCommunicate as usual?

One of the things we may need it for is capsule update.

On 5/18/20 10:53 AM, Ilias Apalodimas wrote:

+cc Ard
On Thu, 14 May 2020 at 17:57, Sahil Malhotra <sahil.malhotra@... <mailto:sahil.malhotra@...>> wrote:
Hi All,
We are working on enabling the Secure Storage of Variables for
Secure UEFI.
Let me give you a brief idea of what we are doing.
We need StandAlone Management Mode to run in the Secure Environment.
For that in EDK2 we already have the MmCommunicationDxe Runtime
Driver which communicates with StMM running in Secure Partition in
Secure World.
But this driver is based on SPM (Secure Partition Manager) running
in the ATF.
As we are aware that ATF can run either in SPM mode or SPD mode,
Both are mutually exclusive.
So we cannot have both the StMM running in Secure Partition as well
as OP-TEE or any other Secure OS running in Secure World.
On many systems, there are many other secure operations needed to be
done that can be done by Secure OS only.
So in these systems we need to make the StMM and Secure OS work
together.
As part of doing this only, we have created a kind of Secure
Partition within OP-TEE in which StMM can work as a kind of TA, and
other TAs cannot interfere with the working of this Secure Partition.
Other TAs can run in parallel to StMM on top of OP-TEE, We can get
the work done by StMM by OP-TEE SMC calls only.
It will be like this as shown in the below image.
Secure World
+-----------------------------------------------------------+
|   +-----------------------+    +------------------------+ |
|   |                       |    | +--------------------+ | |
|   |                       |    | |                    | | |
|   |   Trusted Application |    | |                    | | |
|   |                       |    | |                    | | |
|   |                       |    | |      StMM          | | |
|   +-----------------------+    | |                    | | |
|                                | |                    | | |
|                                | |                    | | |
|                                | +--------------------+ | |
|                                |                        | |
|                  OP-TEE        |                        | |
|                                |                        | |
|                                |     Secure Partition   | |
|                                |                        | |
|                                |                        | |
|                                |                        | |
|                                +------------------------+ |
+-----------------------------------------------------------+
So with this approach of running StMM in an exclusive secure
partition with OP-TEE, StMM and TAs can work together.
In this way StMM binary which is compiled is also
environment-agnostic, Same StMM binary can work whether it is
running as part of OP-TEE or Standalone in Secure Word.
If OP-TEE is responsible for running StMM, firmware implementations,
like U-Boot, can use it to store UEFI variables.
Now for implementing the whole system of Secure Variable Storage for
Secure UEFI.
We need to make changes in MmCommunicationDxe Runtime Driver and
OpteeLib
Let's discuss one by one the changes:
* MmCommunicationDxe – Currently it is based on SPM SMC calls that
get landed into ATF and do the required work.
o Now since StMM is running as part of OP-TEE, we need to
change these into OP-TEE SMC calls.
* OpteeLib – Currently OpteeLib cannot be used with the Runtime
Drivers.
o We need to change its configuration so that it can be used
with a Runtime Driver.
So for making these changes we have following approaches:
* MmCommunicationDxe
o We can have the code for SPM SMC calling and OPTEE SMC
calling in the same driver under some compile time flags,
but it will make the code nasty.
o Another approach can be writing a new driver under the name
of MmCommunicationOpteeDxe in ArmPkg/Drivers/.
* OpteeLib
o We can make necessary changes to make it work with Runtime
Driver.
o Other approach we can make Runtime Driver of Optee also in
ArmPkg/Drivers/
So please review the mail and approaches for making the changes and
let us know your views.

I'd prefer a separate MmCommunicationOpteeDxe driver, and an updated OpteeLib that can be used both at boot time and at runtime.

So I would assume such an approach would permit any standalone MM driver to be incorporated into the secure side payload, and be invoked using MmCommunicate as usual?

One of the things we may need it for is capsule update.

Hi Sahil,

This proposal interests us too. Got a question for you. I assume that OPTEE-STMM interfaces will be based on SPCI specifications, both in secure and non-secure side. Is that assumption right?

Hi,

Currently it is not based on SPCI interface, but discussions have started
in that direction also.

But I think from non-secure world it will be simple OP-TEE communication
like it happens between a CA and TA now, but on secure side, OPTEE-STMM
communication may be based on SPCI interface.

Regards,
Sahil Malhotra

So if its not based on SPCI interface currently, what is the propose plan for interface. I think if we implement SPCI based interface, this UEFI-MM solution can also be leveraged on the platforms which do not have OP_TEE and platforms based on ARMv8.4. Also can we get involved into those discussions u are referring to below.

Thanks,
Mayur