之前介紹了CCA設(shè)計(jì)的一個(gè)目的是讓hypervisor可以創(chuàng)建和調(diào)度RME虛擬機(jī)和vCPU，并且給它分配內(nèi)存等資源，但是一旦這些資源分配給RME虛擬機(jī)之后，hypervisor就失去了訪(fǎng)問(wèn)這些RME所有的內(nèi)存內(nèi)容的權(quán)限。這是通過(guò)EL3的monitor軟件修改GPT表項(xiàng)實(shí)現(xiàn)的。從而實(shí)現(xiàn)虛擬機(jī)的機(jī)密計(jì)算。

Arm和開(kāi)源社區(qū)提供一個(gè)參考設(shè)計(jì)，其中包括包括：

１. Linux kernel KVM模塊的支持：

• 支持由RME通過(guò)RMI接口創(chuàng)建，運(yùn)行虛擬機(jī)vCPU，可以服務(wù)RME虛擬的RIS host call
• 增加了KVM UABI用于管理Realms
• 增加了Linux kernel作為CCA的Host, 也可以做為CCA的Guest（運(yùn)行于RME虛擬機(jī)，支持RSI接口）

目前運(yùn)行hypervisor的host Linux運(yùn)行在non secure EL2, 并且運(yùn)行于VHE模式。

２. 開(kāi)源的RMM實(shí)現(xiàn)：TF-RMM，主要是服務(wù)host hypervisor發(fā)過(guò)來(lái)的RMI請(qǐng)求，創(chuàng)建在Realm狀態(tài)下對(duì)應(yīng)host Linux KVM里struct kvm的虛擬機(jī)的描述和狀態(tài)，和對(duì)應(yīng)host Linux vCPU的虛擬CPU狀態(tài)和上下文的結(jié)構(gòu)，并且負(fù)責(zé)Realm中vCPU的context的save/restore. RMM還負(fù)責(zé)通過(guò)Realm的stage 2實(shí)現(xiàn)多個(gè)Realm虛擬機(jī)間的隔離。

３. 擴(kuò)展現(xiàn)有的 Arm Trusted Firmware，使它支持RME引入的４個(gè)secure狀態(tài)和它們間切換時(shí)的context swithing，增加了RMI調(diào)用的支持和GPT頁(yè)表的管理。

TF-RMM采用了類(lèi)似Hafnium, OPTEE的工作方式，主要目的是將原來(lái)在host Linux kernel做的部分事情（如和vCPU context，stage 2頁(yè)表配置相關(guān)的）通過(guò)RMI調(diào)用轉(zhuǎn)到Realm world實(shí)現(xiàn)，這部分事情放在host Linux中的話(huà)，可以導(dǎo)致host可以獲得修改VM的信息和控制VM的執(zhí)行。但是TF-RMM和Hafnium, OPTEE一樣沒(méi)有調(diào)度和復(fù)雜的內(nèi)存管理功能，TF-RMM的執(zhí)行主要是服務(wù)Host Linux的RMI調(diào)用和Guest Linux的RSI調(diào)用。

概況

Host Linux支持創(chuàng)建普通的虛擬機(jī)和Realm虛擬機(jī)，現(xiàn)有的KVM API還是可以使用。Host Linux通過(guò)KVM_CAP_ARM_RME告訴user space的VMM，平臺(tái)是否支持RME的KVM。如果要?jiǎng)?chuàng)建Realm虛擬機(jī)，VMM可以通過(guò)kvm module的ioctl KVM_ENABLE_CAP調(diào)用并傳入.cap = KVM_CAP_ARM_RME參數(shù)。Host Linux kernel為之創(chuàng)建的struct kvm結(jié)構(gòu)中的kvm->arch.is_realm記錄，后面kernel通過(guò)kvm_is_realm（kvm）檢查是否為Realm VM. KVM_CAP_ARM_RME會(huì)導(dǎo)致KVM調(diào)用kvm_create_realm->realm_create_rd->rmi_realm_create 這會(huì)引起RMI Realm.Create的SMC調(diào)用，ATF會(huì)將這個(gè)調(diào)用dispatch給TF-RMM處理，TF-RMM會(huì)為之創(chuàng)建Realm Descriptor (RD，struct rd)的結(jié)構(gòu)，對(duì)應(yīng)于host Linux kernel的struct kvm結(jié)構(gòu)。TF-RMM的rmm_handler通過(guò)一下handler來(lái)服務(wù)這些RMI調(diào)用：

static const struct smc_handler smc_handlers[] = {
    HANDLER(VERSION,        0, 0, smc_version,         true, true),
    HANDLER(FEATURES,        1, 1, smc_read_feature_register, true,  true),
    HANDLER(GRANULE_DELEGATE,    1, 0, smc_granule_delegate,     false, true),
    HANDLER(GRANULE_UNDELEGATE,    1, 0, smc_granule_undelegate,     false, true),
    HANDLER(REALM_CREATE,        2, 0, smc_realm_create,         true,  true),
    HANDLER(REALM_DESTROY,        1, 0, smc_realm_destroy,     true,  true),
    HANDLER(REALM_ACTIVATE,        1, 0, smc_realm_activate,     true,  true),
    HANDLER(REC_CREATE,        3, 0, smc_rec_create,         true,  true),
    HANDLER(REC_DESTROY,        1, 0, smc_rec_destroy,         true,  true),
    HANDLER(REC_ENTER,        2, 0, smc_rec_enter,         false, true),
    HANDLER(DATA_CREATE,        5, 0, smc_data_create,         false, false),
    HANDLER(DATA_CREATE_UNKNOWN,    3, 0, smc_data_create_unknown,     false, false),
    HANDLER(DATA_DESTROY,        2, 0, smc_data_destroy,         false, true),
    HANDLER(RTT_CREATE,        4, 0, smc_rtt_create,         false, true),
    HANDLER(RTT_DESTROY,        4, 0, smc_rtt_destroy,         false, true),
    HANDLER(RTT_FOLD,        4, 0, smc_rtt_fold,         false, true),
    HANDLER(RTT_MAP_UNPROTECTED,    4, 0, smc_rtt_map_unprotected,     false, false),
    HANDLER(RTT_UNMAP_UNPROTECTED,    3, 0, smc_rtt_unmap_unprotected, false, false),
    HANDLER(RTT_READ_ENTRY,        3, 4, smc_rtt_read_entry,     false, true),
    HANDLER(PSCI_COMPLETE,        2, 0, smc_psci_complete,     true,  true),
    HANDLER(REC_AUX_COUNT,        1, 1, smc_rec_aux_count,     true,  true),
    HANDLER(RTT_INIT_RIPAS,        3, 0, smc_rtt_init_ripas,     false, true),
    HANDLER(RTT_SET_RIPAS,        5, 0, smc_rtt_set_ripas,     false, true)

然后VMM通過(guò)KVM_CREATE_VCPU的kvm ioctl調(diào)用kvm_vm_ioctl_create_vcpu ->kvm_arch_vcpu_create創(chuàng)建了vCPU之后，對(duì)于Realm VMh還需要通過(guò)KVM_ARM_VCPU_FINALIZE kvm_arch_vcpu_ioctl系統(tǒng)調(diào)用， kvm_arm_vcpu_finalize kvm_create_rec－>rmi_rec_create, 通過(guò)RMI REC_CREATE調(diào)用（通過(guò)SMC指令）到ATF，ATF再將此調(diào)用dispatch到TF-RMM，TF-RMM通過(guò)smc_rec_create在Realm狀態(tài)創(chuàng)建對(duì)應(yīng)于host Linux KVM struct kvm_vcpu的struct rec結(jié)構(gòu)體。Host kernel KVM通過(guò)vcpu_is_rec()檢查vCPU是否運(yùn)行在Realm中。

struct rec {
    struct granule *g_rec;    /* the granule in which this REC lives */
    unsigned long rec_idx;    /* which REC is this */
    bool runnable;

    unsigned long regs[31];

    /*
     * PAuth state of Realm.
     * Note that we do not need to save NS state as EL3 will save this as part of world switch.
     */
    struct pauth_state pauth;

    unsigned long pc;
    unsigned long pstate;

    struct sysreg_state sysregs;
    struct common_sysreg_state common_sysregs;

    struct {
        unsigned long start;
        unsigned long end;
        unsigned long addr;
        enum ripas ripas;
    } set_ripas;
    /*
     * Common values across all RECs in a Realm.
     */
    struct {
        unsigned long ipa_bits;
        int s2_starting_level;
        struct granule *g_rtt;
        struct granule *g_rd;
        bool pmu_enabled;
        unsigned int pmu_num_cnts;
        bool sve_enabled;
        uint8_t sve_vq;
    } realm_info;

    struct {
        /*
         * The contents of the *_EL2 system registers at the last time
         * the REC exited to the host due to a synchronous exception.
         * These are the unsanitized register values which may differ
         * from the value returned to the host in rec_exit structure.
         */
        unsigned long esr;
        unsigned long hpfar;
        unsigned long far;
    } last_run_info;

    /* Pointer to per-cpu non-secure state */
    struct ns_state *ns;

    struct {
        /*
         * Set to 'true' when there is a pending PSCI
         * command that must be resolved by the host.
         * The command is encoded in rec- >regs[0].
         *
         * A REC with pending PSCI is not schedulable.
         */
        bool pending;
    } psci_info;

    /* Number of auxiliary granules */
    unsigned int num_rec_aux;

    /* Addresses of auxiliary granules */
    struct granule *g_aux[MAX_REC_AUX_GRANULES];
    struct rec_aux_data aux_data;

    unsigned char rmm_realm_token_buf[SZ_1K];
    size_t rmm_realm_token_len;

    struct token_sign_ctx token_sign_ctx;

    /* Buffer allocation info used for heap init and management */
    struct {
        struct buffer_alloc_ctx ctx;
        bool ctx_initialised;
    } alloc_info;

    struct {
        unsigned long vsesr_el2;
        bool inject;
    } serror_info;

    /* True if host call is pending */
    bool host_call;
};

然后VMM通過(guò)KVM_RUN 的ioctl運(yùn)行vCPU，對(duì)于Realm VM, 這是通過(guò)kvm_arch_vcpu_ioctl_run ->kvm_rec_enter->rmi_rec_enter，rmi_rec_enter通過(guò)RMI REC_ENTER的調(diào)用（通過(guò)SMC指令）到ATF，ATF將它dispatch到TF-RMM，TF-RMM調(diào)用smc_rec_enter，然后通過(guò)rec_run_loop將物理CPU的執(zhí)行轉(zhuǎn)交給Realm EL0&EL1的Realm VM。

完整的vCPU運(yùn)轉(zhuǎn)圖如下：

由此看出，對(duì)于host Linux KVM, 與正常的KVM VM, pKVM VM類(lèi)似，Realm虛擬機(jī)的vCPU的創(chuàng)建是由host Linux上的VMM管理的，每個(gè)Realm vCPU對(duì)于host Linux來(lái)說(shuō)也只是VM進(jìn)程的一個(gè)線(xiàn)程，也是由host Linux負(fù)責(zé)調(diào)度的。只是Realm vCPU運(yùn)行于Realm EL0&EL1狀態(tài)。但是Realm VM和Realm vCPU的信息host Linux是看不到的，這點(diǎn)與正常的KVM VM不同。

從上圖也可以看出，Realm vCPU執(zhí)行的進(jìn)入和退出需要經(jīng)過(guò)更長(zhǎng)的路徑，如進(jìn)入vCPU的執(zhí)行需要經(jīng)過(guò)host Linux KVM->ATF->TF-RMM->Realm VM,每個(gè)步驟都涉及到context save/restore. 但根據(jù)初步的研究發(fā)現(xiàn)，這個(gè)過(guò)程中帶來(lái)的overhead并不是很明顯。

Stage 2 table的管理

RMM的stage 2用于Realm VM之間的隔離。在TF-RMM中維護(hù)一個(gè)RTT，相當(dāng)于Normal KVM VM中的stage 2頁(yè)表，對(duì)于Realm VM, 這是由TF－RMM管理的RTT.
Realm VM的IPA空間包括一個(gè)受保護(hù)的地址范圍(PAR)，RMM確保只能將其映射到Realm PAS。

對(duì)于在PAR內(nèi)的訪(fǎng)問(wèn)，RMM保證給Realm的機(jī)密性和完整性；在PAR之外，hypervisor可以自由地映射N(xiāo)S PAS內(nèi)存頁(yè)或模擬訪(fǎng)問(wèn)。這為在Realm VM上運(yùn)行的OS提供了一個(gè)可靠的機(jī)制來(lái)確定它是訪(fǎng)問(wèn)自己的私有內(nèi)存，還是可以與不受信任的其他部分共享的內(nèi)存。

在Realm創(chuàng)建期間，hypervisor可以將一個(gè)內(nèi)存頁(yè)分配給Realm，在PAR內(nèi)的特定IPA處，并從NS內(nèi)存頁(yè)復(fù)制數(shù)據(jù)到它。IPA和數(shù)據(jù)經(jīng)過(guò)加密哈希，哈希包含在Realm的認(rèn)證令牌中。認(rèn)證令牌允許Realm的所有者推理其初始狀態(tài)和內(nèi)容。一旦Realm被激活，只能將內(nèi)存添加到其他未使用的IPA。

hypervisor可以隨時(shí)從Realm回收內(nèi)存。RMM在回收內(nèi)存頁(yè)并將其返回給hypervisor之前將此內(nèi)存頁(yè)清零。后續(xù)訪(fǎng)問(wèn)Realm回收內(nèi)存的IPA會(huì)導(dǎo)致RMM的stage 2異常，這會(huì)阻止Realm進(jìn)一步執(zhí)行并保持Arm CCA的完整性保證。

在Host Linux KVM中它可以請(qǐng)求map或是unmap Realm VM的stage 2映射，讓RMM管理Realm stage 2頁(yè)表，但它不能獲取修改到Realm RMM的stage 2頁(yè)表內(nèi)容。例如Host Linux KVM可以通過(guò)unmap_stage2_range來(lái)請(qǐng)求unmap一些stage 2映射，這個(gè)過(guò)程是：

unmap_stage2_range- >__unmap_stage2_range- >kvm_realm_unmap_range- >realm_tear_down_rtt_range,

在這里會(huì)通過(guò)RMI的RTT_DESTROY，RTT_CREAT調(diào)用（通過(guò)SMC指令）到ATF, ATF再將它dispatch到TF-RMM的smc_rtt_create，smc_rtt_create進(jìn)行RMM RTT頁(yè)表操作。

中斷處理

目前沒(méi)有GIC沒(méi)有專(zhuān)門(mén)對(duì)Realm VM的虛擬中斷支持，因此Realm VM的中斷需要在host Linux kernel中通過(guò)其vgic中斷產(chǎn)生虛擬中斷。

由代碼可知，RMM在rec_run_loop中準(zhǔn)備運(yùn)行Realm時(shí)（參見(jiàn)前面Realm vCPU運(yùn)行流程圖），它調(diào)用restore_realm_state

static void restore_realm_state(struct rec *rec)
{
    write_cnthctl_el2(rec- >sysregs.cnthctl_el2);
    isb();

    restore_sysreg_state(&rec- >sysregs);

    write_elr_el2(rec- >pc);
    write_spsr_el2(rec- >pstate);
    write_hcr_el2(rec- >sysregs.hcr_el2);

設(shè)置Realm EL2的HCR_EL2寄存器的值為

HCR_FLAGS     (HCR_FWB | HCR_E2H | HCR_RW | HCR_TSC | HCR_AMO |HCR_BSU_IS | HCR_IMO | HCR_FMO | HCR_PTW | HCR_SWIO | HCR_VM | HCR_TID3 | HCR_TEA | HCR_API | HCR_APK)

這個(gè)設(shè)置中HCR_IMO, HCR_FMO讓當(dāng)運(yùn)行在Realm EL0&EL1 （Realm VM)時(shí)產(chǎn)生的IRQ和FIQ會(huì)route到Realm EL2 (RMM)中處理。
RMM對(duì)于這些route到Realm EL2的處理為

el2_irq_lel:
    stp    x0, x1, [sp, #-16]!
    mov    x0, #ARM_EXCEPTION_IRQ_LEL
    b    realm_exit
ENDPROC(el2_sync_lel)

el2_fiq_lel:
    stp    x0, x1, [sp, #-16]!
    mov    x0, #ARM_EXCEPTION_FIQ_LEL
    b    realm_exit
ENDPROC(el2_sync_lel)

realm_exit使執(zhí)行回到handle_realm_exit，然后繼續(xù)退回到ATF，ATF繼續(xù)退回到Host Linux KVM, 再在host Linux kernel里進(jìn)行這個(gè)物理中斷的處理，如果要產(chǎn)生一個(gè)虛擬中斷給Realm VM，host Linux kernel利用其GIC driver的vGIC產(chǎn)生一個(gè)虛擬中斷，然后通過(guò)ATF進(jìn)入到RMM，RMM再回到Realm VM的執(zhí)行，這是Realm VM就能處理這個(gè)pending的虛擬中斷。

ATF的支持

ATF對(duì)CCA支持主要包括：
１. 加載RMM Image和啟動(dòng)RMM

２. 負(fù)責(zé)Root，Non Secure，Secure和Realm四個(gè)secure world的切換，增加了RMM的dispatcher

３. 管理GPT頁(yè)表

Host Linux KVM可以通過(guò)alloc_delegated_page ，free_delegated_page 等函數(shù)來(lái)請(qǐng)求ATF改變一個(gè)物理內(nèi)存頁(yè)在GPT頁(yè)表中的PAS, 這是通過(guò)host Linux kvm調(diào)用rmi_granule_delegate， rmi_granule_undelegate也就是RMI GRANULE_UNDELEGATE ，RMI GRANULE_UNDELEGATE的RMI調(diào)用(通過(guò)SMC指令)，這會(huì)進(jìn)入到ATF的rmmd_rmi_handler進(jìn)行處理，它將這個(gè)RMI請(qǐng)求forward到RMM中處理，RMM處理之后，RMM可以調(diào)用RMM_GTSI_DELEGATE或SMC_RMM_GTSI_UNDELEGATE調(diào)用（通過(guò)SMC）回到ATF，在ATF中的rmmd_rmm_el3_handler中調(diào)用gpt_delegate_pas或是gpt_undelegate_pas來(lái)修改GPT頁(yè)表，最終修改了此物理頁(yè)對(duì)應(yīng)的PAS。

不受信任的hypervisor總能停止調(diào)度一個(gè)Realm，并總是可以回收分配給Realm的內(nèi)存，但在任何情況下，它都不能訪(fǎng)問(wèn)Realm的CPU或內(nèi)存狀態(tài)。這是通過(guò)一個(gè)簡(jiǎn)單但功能強(qiáng)大delegate(分批/委托)來(lái)實(shí)現(xiàn)的。hypervisor將內(nèi)存delegate給Realm world，和回收到non secure world。所有由Realms使用的內(nèi)存首先必須由hypervisor delegate；RMM本身不管理Realm的內(nèi)存池。

一旦內(nèi)存被delegate給Realm world，hypervisor可以請(qǐng)求RMM將其用于各種目的，例如保存Realm的元數(shù)據(jù)或數(shù)據(jù)。當(dāng)一個(gè)內(nèi)存頁(yè)被delegate給Realm world但未被RMM使用時(shí)，RMM確保該內(nèi)存頁(yè)清零，從而降低了內(nèi)存頁(yè)被重用或回收時(shí)意外信息泄露風(fēng)險(xiǎn)。

RMM為hypervisor提供了一個(gè)Realm管理接口(RMI)，要求RMM delegate內(nèi)存、創(chuàng)建Realms、執(zhí)行Realms和為Realms分配內(nèi)存。每一個(gè)RMI命令都是作為一個(gè)SMC實(shí)現(xiàn)的，所以當(dāng)hypervisor調(diào)用該命令時(shí)，它會(huì)陷入到EL3 Monitor，然后切換執(zhí)行到Realm world的RMM來(lái)處理命令。在RMI命令完成后，RMM向EL3 Monitor發(fā)出一個(gè)SMC，將執(zhí)行切換回NS world的hypervisor。

為了維護(hù)Realms的安全保證，RMM必須知道系統(tǒng)上每個(gè)內(nèi)存頁(yè)的狀態(tài)，它通過(guò)維護(hù)自己的內(nèi)存頁(yè)狀態(tài)表(GST)來(lái)實(shí)現(xiàn)，以跟蹤每個(gè)內(nèi)存頁(yè)的delegate狀態(tài)和使用情況。當(dāng)hypervisor delegate一個(gè)內(nèi)存頁(yè)時(shí)，RMM檢查其GST，以確認(rèn)內(nèi)存頁(yè)尚未被delegate，RMM然后向EL3 Monitor發(fā)出一個(gè)SMC請(qǐng)求更改Realm PAS。

EL3 Monitor檢查該內(nèi)存頁(yè)當(dāng)前是否位于NS PAS，然后更新GPT將其移至Realm PAS。最后，RMM更新其GST以記錄該內(nèi)存頁(yè)已被delegate。如果hypervisor試圖delegate已被delegate的內(nèi)存頁(yè)，或回收RMM正在使用的內(nèi)存頁(yè)，RMM會(huì)返回一個(gè)錯(cuò)誤代碼給不受信任的hypervisor。與GPT不同，GST不是由硬件檢查的，而只是一個(gè)軟件記錄機(jī)制。

目前的限制

1. 目前沒(méi)有GIC沒(méi)有專(zhuān)門(mén)對(duì)Realm VM的虛擬中斷支持，因此Realm VM的中斷需要在host Linux kernel中通過(guò)其vgic中斷產(chǎn)生虛擬中斷。未來(lái)的GIC會(huì)支持Realm虛擬中斷的注入
2. 暫時(shí)沒(méi)有 Device Assignment的支持，隨著SMMU的進(jìn)化和軟件的開(kāi)放，后面會(huì)支持
3. 目前在arm構(gòu)架上的KVM有四種不同的支持方式：armv7-a/armv8.0-a的KVM支持方式，自armv8.1-a開(kāi)始支持的VHE方式，Google推的pKVM方式，Realm支持的方式。軟件構(gòu)架上需要提供更c(diǎn)lear的實(shí)現(xiàn)。