Consult for Secure Monitor SBI Extension

[Li, Yong]

Hi Anup,

 

I’m somehow trying to see the possibility to add Secure Monitor extension to the SBI,  and then based on this SBI extension, add the function ids for MM interface.

The initial patch in edk2 is like this.

https://github.com/tianocore/edk2-staging/commit/a47ab1bf25b0bebe75efccfc63db23ebff4ee68e

 

Then by going through the mail thread, it looks like there already some proposals intended to add this SBI extension were there even back to 2019, but then no progress from 2021

https://lists.riscv.org/g/tech-unixplatformspec/topic/sbi_introduce_trusted/81704113?p=

Do you know more detail of the progress about this ?  And is this still a reasonable approach ? 

 

Or can we add the MM functions to the TEE API in this case in short-term, how do you think ? Thanks !.

https://github.com/keystone-enclave/keystone/blob/master/sm/spec/v1.0.md

https://penglai-doc.readthedocs.io/en/latest/Penglai-manual/Penglai-Opensbi-Extension-API.html

 

Thanks,

Yong Li

 

[Anup Patel]

Hi Yong Li,

On Thu, Aug 17, 2023 at 8:52 AM Li, Yong <yon...@intel.com> wrote:
>
> Hi Anup,
>
>
>
> I’m somehow trying to see the possibility to add Secure Monitor extension to the SBI, and then based on this SBI extension, add the function ids for MM interface.
>
> The initial patch in edk2 is like this.
>
> https://github.com/tianocore/edk2-staging/commit/a47ab1bf25b0bebe75efccfc63db23ebff4ee68e
>
>
>
> Then by going through the mail thread, it looks like there already some proposals intended to add this SBI extension were there even back to 2019, but then no progress from 2021
>
> https://lists.riscv.org/g/tech-unixplatformspec/topic/sbi_introduce_trusted/81704113?p=
>
> Do you know more detail of the progress about this ? And is this still a reasonable approach ?

There was no concret SBI TEE proposal which defines a detailed calling
convention between TEE and OS.

>
>
>
> Or can we add the MM functions to the TEE API in this case in short-term, how do you think ? Thanks !.
>
> https://github.com/keystone-enclave/keystone/blob/master/sm/spec/v1.0.md
>
> https://penglai-doc.readthedocs.io/en/latest/Penglai-manual/Penglai-Opensbi-Extension-API.html

As suggested previously, another option is to use RPMI [1] messaging
between TEE and OS where the TEE could be either:
1) Running as separate domain under OpenSBI
OR
2) Running on a separate microcontroller on the SoC

Basically, we can define a RPMI service group for MM (management mode)
communication.
The OS can use SBI RPMI Proxy (RPMP) calls [2] to send RPMI MM
messages through the SBI implementation.

[1] - https://docs.google.com/document/d/199ar3Ddd-FlzP1FR3HOkbBf1BNvLUPvJ/edit?usp=sharing
[2] - https://docs.google.com/document/d/1Z1YbGIex47lkRZM-1favv8WVNPQEmNbJiO6qvM91Qvo/edit?usp=sharing

Regards,
Anup

>
>
>
> Thanks,
>
> Yong Li
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V Firmware Exchange" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org.
> To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/BY5PR11MB386176C181A8A4921FF61D6AFB1AA%40BY5PR11MB3861.namprd11.prod.outlook.com.

[Li, Yong]

Thank you Anup, did not get that wording and the link during the last time fw meeting,
and will got through the documents and go back to you.

[Li, Yong]

Hi Anup,

 

1.

I worked together with StarFive who is also working with you on the existing RPMI spec and Penglai team in China who is familiar with the OpenSBI domain,

we added a MM RPMI service group for MM (management mode) communication.

Please help review the changes we made in chapter 4.10 in https://docs.google.com/document/d/18lupciraX5_EVtNS984apTTO3Sti6ln3BqMzgTSfYHE

 

2.

Based on the new MM RPMI service group defined above and a current assumption that MM supports to run in the same hart/cpu, we can have the High Level RPMI based Management Mode Architecture as below. In which the “Secure Domain Manager” is responsible to do the domain isolation and also takes the mail-box transport role which is in original RPMI based system architecture and PoC.

Please confirm the design

 

3.

At the same time Penglai team also finished the MM PoC based on your latest RPMI PoC code to OpenSBI (They ported some context switch related code from their Enclave code),  which proved the above high level design for MM is workable and can work together with the existing RPMI services which are based on the mail-box physical transport layer. 

The code changes are as below:

edk2: https://github.com/ventanamicro/edk2/tree/dev-upstream => https://github.com/yli147/edk2/tree/dev-standalonemm-rmpi

opensbi: https://github.com/ventanamicro/opensbi/tree/dev-upstream => https://github.com/Penglai-Enclave/opensbi/commits/dev-standalonemm-rpmi

qemu: https://github.com/ventanamicro/qemu/tree/dev-upstream => https://github.com/yli147/qemu/commits/dev-standalonemm-rmpi

The build steps: https://wiki.riseproject.dev/display/HOME/EDK2_00_02_04+Evaluate+with+OpenSBI

 

The boot flow: Boot ROM -> QEMU/U-Boot SPL -> OpenSBI –> StandaloneMM ->EDK II -> Linux kernel

 

    

The detail MM communication flow is as below:

1. OpenSBI + StandaloneMM and EDK II are loaded by U-Boot SPL/QEMU
2. OpenSBI initialize StandaloneMM
3. OpenSBI pass execution control to EDK II
4. When EDK II (S-mode) need to access secure variables, it invokes Management Mode Service through SBI call (RPMI)
5. OpenSBI (M-mode) trap the SBI call, perform CPU/PMP context switch to secure domain and pass execution control to StandaloneMM
6. StandaloneMM parse the RPMI payload message in designated shared memory to check the request access passed from EDK II
7. After performing the required secure services, StandaloneMM write the response back to the designated shared memory and return to OpenSBI
8. OpenSBI restore the context switch back to non-secure domain and return back to EDK II
9. EDK II read the StandaloneMM’s response from designated shared memory

 

Please review the code for detail, especially the OpenSBI code here https://github.com/Penglai-Enclave/opensbi/commits/dev-standalonemm-rpmi

 

4.

One more thing,  the current RPMI based MM spec, design and PoC are all for non-virtualization platforms. Although the function is working,

as Tuan pointed out and emphasized in a separate mail, if we use RPMI + MM,  we also need implement the security isolation code fully in OpenSBI,

and give the proof of the security be taken care for MM, this key part is not ready and to be designed and documented.

 

5.

Finally, there are also discussion on CoVE/Salus based MM scenario (Thanks Sharma for the input), but on virtualization platform there are still a lot of uncertainty thing,

may need deep dive from base requirement and use cases first..

So here I’d prefer we discuss this RPMI MM proposal on non-virtualization platform at first.

 

Thanks for going through this email and look for your feedback.

 

Thanks,

Yong Li

 

-----Original Message-----
From: Anup Patel <an...@brainfault.org>
Sent: Thursday, August 17, 2023 8:58 PM
To: Li, Yong <yon...@intel.com>
Cc: Anup Patel <apa...@ventanamicro.com>; fw-ex...@riscv.org; Tuan Phan <tp...@ventanamicro.com>
Subject: Re: Consult for Secure Monitor SBI Extension

 

Hi Yong Li,

 

On Thu, Aug 17, 2023 at 8:52 AM Li, Yong <yon...@intel.com> wrote:

> 

> Hi Anup,

> 

> 

> 

> I’m somehow trying to see the possibility to add Secure Monitor extension to the SBI,  and then based on this SBI extension, add the function ids for MM interface.

> 

> The initial patch in edk2 is like this.

> 

> https://github.com/tianocore/edk2-staging/commit/a47ab1bf25b0bebe75efc

> cfc63db23ebff4ee68e

> 

> 

> 

> Then by going through the mail thread, it looks like there already

> some proposals intended to add this SBI extension were there even back

> to 2019, but then no progress from 2021

> 

> https://lists.riscv.org/g/tech-unixplatformspec/topic/sbi_introduce_tr

> usted/81704113?p=

> 

> Do you know more detail of the progress about this ?  And is this still a reasonable approach ?

 

There was no concret SBI TEE proposal which defines a detailed calling convention between TEE and OS.

 

> 

> 

> 

> Or can we add the MM functions to the TEE API in this case in short-term, how do you think ? Thanks !.

> 

> https://github.com/keystone-enclave/keystone/blob/master/sm/spec/v1.0.

> md

> 

> https://penglai-doc.readthedocs.io/en/latest/Penglai-manual/Penglai-Op

> ensbi-Extension-API.html

 

As suggested previously, another option is to use RPMI [1] messaging between TEE and OS where the TEE could be either: