Question of Salus development plan about deployment model 1/2

[GooTal]

Hi,

In README, we noticed that the initial prototype of salus runs in HS mode. And the Host runs in VS mode.

  +---U-mode--+ +-----VS-mode-----+ +-VS-mode-+
  |           | |                 | |         |
  |           | | +---VU-mode---+ | |         |
  |   Salus   | | | VMM(crosvm) | | |  Guest  |
  | Delegated | | +-------------+ | |         |
  |   Tasks   | |                 | |         |
  |           | |    Host(linux)  | |         |
  +-----------+ +-----------------+ +---------+
        |                |               |
   TBD syscall   SBI (COVH-API)    SBI(COVG-API)
        |                |               |
  +-------------HS-mode-----------------------+
  |       Salus                               |
  +-------------------------------------------+
                         |
                        SBI
                         |
  +----------M-mode---------------------------+
  |       Firmware(OpenSBI)                   |
  +-------------------------------------------+

Have you considered the isolated secure/insecure plan, running Host in HS mode, togther with salus? As the following prototype：

                           +-------VS-mode------+
                           |                    |
                           |       Guest        |
                           |                    |
                           +--------------------+
                               |            ↑
                          4.SBI(COVG)  3.SBI(COVH)
                               ↓            |
+---------HS-mode---+      +--HS-mode-----------+
|    Host(linux)    |      |       Salus        |
+-------------------+      +--------------------+
   |            ↑              |            ↑
1.SBI(COVH)  6.SBI(COVG)  5.SBI(COVG)   2.SBI(COVH)
   ↓            |              ↓            |
+---------------------M-mode--------------------+
|           Firmware(OpenSBI)                   |
+-----------------------------------------------+

The process describes as follows，also described from COVE spec in the following pic :

1.Host ecalls to OpenSBI.(TEECALL)

2.OpenSBI identifies COVH ecall messages, then transfers the message to Salus.

3.Salus identifies TEERET message from OpenSBI, and might run Guest in VS mode.

4.Guest might trap into Salus, with COVG message.

5.Salus finishes COVH processing, returns message to Host, and transfers the control flow to Opensbi.

6.OpenSBI transfers the control flow to Opensbi, with messages. (TEERET)

The pics from here: TCB Isolation for VM workloads using Supervisor Domains, TSM operation: Interruptible and non-reentrant TSM model according to the deployment model 1.

The later prototype got some advantages:

1. Insecure / Secure domain isolation. Host could run just in insecure domain as if no other domains provided. Confidential VMs could run in secure domain, with safety guarantee from MTT/IOMTT etc.
2. No virtualization performance lost for Host. Host still runs above OpenSBI in S(HS) mode. And no need to run host in VS mode with virtualization performance lost.
   3.Non-confidential VMs still run VS mode, hosted by Host(Linux). There is no need to run Non-confidential VMs in nested virtualization mode with performance lost.

Do you think the later plan is needed for salus?

We'd like to know if you're already developing the later plan.

If so, we may hope to join the development.
If not, we may put some effort into the later one. Very glad if you could offer some help.

[atishp04]

We would definitely like to see deployment model 1 implemented. However, nobody within Rivos is actively working on it due to lack of resources and Smmt Qemu patches. I am assuming your plan is to use Smmt extension for M-mode.
@Zhu632cui632 seems to have some old implementation. Please send a PR or share your implementation once it is ready.

[GooTal]

@atishp04 Thanks for your reply and the implementation of model 2. It's very helpful in deploying model 1.

Things just get started. It seems many interfaces implemented in salus (model 2) requires refactoring to implement model 1. And i could see some challenges:

1. The CoVE interfaces are handled by TSM in a virtualized way. Understanding and refactoring the code and spec correctly.
2. Some interfaces requires adjustment in TSM-driver, we hope to use Smmtt extension.
3. Well, green hand on Rust.

We'll share our code once it`s ready, but maybe a little longer due to the company`s confidentiality terms.
Hope to be in touch for discussions, thanks.

@Zhu632cui632 hi Zhu, can you share your old implementation. I found this one:rivosinc/linux#6. Much thanks if you could share any other PRs.

[dgreid]

Thanks @GooTal, The key is going to be to get the qemu smmt patches posted ASAP, we'll need those to get started on the salus side. Anything you can to speed that up will be a great help.

[GooTal]

Hi, in model 1, can nacl still be used to support message passing among multi domains?

The memory shared between TVM & host is referred to as non-confidential memory regions.
In model 1, tsm_get_info messages can be transfered from the non-confidential shared memory between TVM & host. What kind of message passing protocal should be used to transfer messages between two domains?

In salus(model 2), nacl is used to transfer messages in a single confidential domain, which is totally ok. NACL is designed for transferring messages between M/S modes, not for multi domains.

But in model 1, can nacl still be used to support message passing among multi domains?

[atishp04]

CoVE just uses the CSR and GPR feature from NACL. IMO, we should move to SBI MPXY rather than NACL. SBI MPXY is a natural fit for both deployment models. For MPXY, we need to define a CoVE specific protocol and define the message format for the required GPR & CSRs. It will be extensible in the future as well.