Let the Host manage RTT following CCA's original design

[zpzigi754]

According to CCA's spec, RTT (Realm Translation Table == Realm's stage 2 table) should be managed by the Host. The Host determines where RTT is located, how it is modified, etc. Especially, the Host reads the contents and conducts different actions according to the contents (PTE's state).

However, in the current design of islet, RMM manages RTT independently of the Host. RMM randomly chooses the location of RTT in the heap, and fills the contents against the Host's intention which makes it hard for the Host to manage the RTT (table construction time, table location, and table contents are all different).

My suggestion is adopting the CCA's original design (letting the Host manage RTT).

The expected benefits are

1. reduced development/maintenance cost
   : less debugging time would be required from the less divergence

2. take advantage of the rigorous design of CCA (some of which were formally verified)

3. not using several heuristics to avoid issues caused from the difference

Furthermore, the existing testing tools (tf-a-tests and ACS) assume CCA's original design. In order for them to work correctly (instead of showing bogus results), I think that we should follow the original design.

[jinbpark]

Agreed, following the original design first and then doing our own design (our current impl) which might be far from the original one, when it gets actually needed.

Apart from that, what I really want to get into and spend time on is a security analysis based on who manages RTT. I think, currently, it seems that we adopt our current design for efficiency and ease of implementation but not for security.

My key question is "managing RTT inside RMM" is more secure than "managing RTT in Host"?, if so, why? That is a very much about offensive research question.

[bokdeuk-jeong]

I disagree the idea due to the reasons below:

1. Why do you put more values on the development convenience than the confidentiality of realm?
   • I think exposing less information that only matters in realm world is better.
   • We are creating a platform for confidential computing. This should always come first when we make descisions.
2. CCA rigorious design. Formal verification
   • It depends on what properties are fomally verfied. Does it verify that there is no risk of any information leakage? I might have missed it, but I couldn't find such verfication result from the two papers.
3. Could you inquire ARM why it chose such design?

[zpzigi754]

According to DEN-0096 1.3. CCA Security guarantee,

Arm CCA has been designed to provide specific security guarnatees to both Realms and to the hosting 
environment. The guarantees, of course, assume a correct implementation of CCA. 

This means that if we do not conform to the correct implementation of CCA, we might fail to provide its original security guarantees summarized as minimal chain of trust, attestable trust and certifiable. I do not put much values on the development convenience, rather I put more values on the conformance of the original spec, as I see our project as a safe alternative of the reference implementation.

A core design principle of CCA is the split of responsibility between an untrusted hypervisor and RMM, where the untrusted hypervisor allocates memory and RMM provides integrity and confidentiality guarantees.

I think that exposing 2nd-level page table construction/manipulation APIs to the Host is for allowing the Host to retain its ability to dynamically allocate memory to or free memory from a Realm VM.

Also, this design decision (exposing page table API to the Host) is amenable for machine-checkable verification. For example, a formally verified enclave system called Komodo (SOSP'17) also exposes an interface to construct enclave's page tables by the Host. If they were constructed independent of the Host, it would not be able to be verified.

I think that reducing the channels or amount of information could be a good direction, but not the ultimate goal. If RMM does everything without the aid of the Host, it would be able to remove almost all the channels. However, it would bloat RMM itself (e.g., maintaining another big hypervisor in the end).

An important thing to consider is how sensitive information can be leaked through the original design. From my point of view, manipulating RTT by the Host using the existing interface is okay. At least, it has proved the property like Realm Memory Isolation. If one can demonstrate that the original design of RTT interface is harmful (e.g., extracting a sensitive key using the interface), it
would become a good academic paper and ARM would update its spec disabling it. That's when we can change the design according to the updated spec I think.

I will try to contact a person in ARM to inquire why it chose such design.

[bokdeuk-jeong]

• CCA Security gaurantee: I have respected the idea of seperating resource management and enforcement of the resource and I still do.
  I don't think managing S2 in realm world by rmm itself doen't violate the core concept of the principle. We still let the non-sec hypervisor decide which resource to allocate.
• As you mentioned that the hypervisor in non-sec world is untrusted, why do we let it manipulate the S2 table which is solely role of the trusted rmm in an another world? Moreover, I don't like the idea that hypervisor tells RMM what vmid in realm world for a realm use and what system register settings it should have.
• Regarding the attetable and certifierable: It depens on what needs to be attested. I don't think which physical page is mapped to which IPA is included in the attestation. It even varies along with multiple VM creation even if we use the same realm image. Current attestation doesn't include which IPA is actually mapped to which physcial memory address either. It attests that the intial realm memory state saying that the realm memory contains pre-arranged contents to each designated guest physical address. However, on my second thought, it is feasible to set the page properties like cacheablity and sharablities according to the requested configuration demands from (not-hypervisor, but) the confidential app and include them to the attestation. Some application may want to control that level.
• Thanks for the paper introduction.
• Minimal chain of trust: Even non-sec hypervisor provides physical pages for S2 page tables and tells how each page table entries needs to be configured, RMM still needs the code to actually set the page table. In this scope, there isn't TCB increase. By receiving such command from non-sec, RMM has to validate them additionaly and this requires more code. Current Islet requires memory allocation and increases its own memory usage. I would say this is even.
• We are just not exposing S2 page table only. Current implementation still gives oppertunity how to utilize realm memory except which specific physical page it shoud be.
• I don't know the possiblity of sensitive information leakeage with current design. Not discovered yet doesn't mean that it is okay. I believe that system registers and the content of S2 page tables are sensitive information and would rather minize any potential risks.

Thanks for the inquiry. Although we have very different opinion, I am glad to open up this issue and have this opportunity to discuss with you all.

[jinbpark]

@zpzigi754 Is there a way to mark a discussion as done? As we now have the RTT management scheme that conforms to the ARM CCA spec, it would be better to turn this discussion to "done (or something similar state?)" with a short comment like leaving a link to a relevant PR.

[zpzigi754]

Good comment. It seems that locking or deleting is only possible for the discussions of idea category (No way to mark as done). I will leave a comment indicating the corresponding PR!
Uoops, there is a way to close the discussion that I was not aware of.

[zpzigi754]

The discussion has ended towards conforming CCA's original spec and the related PR can be viewed in #193.