<aside> 💡 Due: 10/5/23 at 11:59PM

</aside>

<aside> 💡 Due: 10/12/23 at 11:59PM

</aside>

In SeKVM, the VM memory is protected from accessing by the untrusted host. However, there may be occasions when a VM wants to share some information securely to another VM. Encrypted network channel is one solution, but may not always be available to a VM, for example, a VM may disable the network due to security policy. Therefore, you are going to implement a secure communication channel using shared memory.

Problems

1. Passthrough a memory region to KCore

   Hypercall(HVC), an analogous of system call, is the interface used by the kernel and VM to communicate with the hypervisor. Implement the following hypercall to passthrough a range of memory to KCore.

   • HVC_HOST_SHMEM_REGISTER
     • base: Physical address of the beginning of the shared memory region. Must be 2MB 4KB aligned.
     • size: Size of the shared memory region. Must be 4KB aligned.
     • The shared memory region should have a dedicated ownership #define SHMEM (EL2_MAX_VMID + 2)
     • The shared memory region should be availbe to all VMs and KCore, but should never be available to the KServe after the registration.
   • You should make sure this hypercall works properly on normal kernel memory. After that, you can proceed to the next problem.
   • For testing purposes, you can allocate the memory when the kernel intializes KCore and using appropriate memory allocator such as alloc_pages.

2. Reserve the shared memory in the guest

   • To simplify the implementation, we can overload the VM’s memory for the shared memory. Implement the hypercalls to register the IPA being used for the shared memory to the KCore:
     • HVC_GET_SHMEM_SIZE
       • Return the size of the host registered shared memory for this VM.
     • HVC_GUEST_SHMEM_REGISTER
       • base: Guest physical address of the beginning of the shared memory region. Must be 4KB aligned.
     • HVC_GUEST_SHEME_UNREGISTER
   • Once the VM has registered the shared memory to KCore, KCore should unmap the previously mapped pages in the stage-2 page table of the VM if any, and map the shared memory to the address space of the VM.
   • If the VM unregisters the shared memory, KCore should unmap the shared memory from the stage-2 page table of the VM. It does not need to remap the original pages.
   • If the VM does not unregister the shared memory when powering off, KCore automatically unregisters the shared memory.

3. Guest kernel shared memory driver

   The kernel needs to manage the shared memory and provides interfaces for user to access the shared memory in the user space. One way is using a system call, but a system call normally will not allocate user space memory. Instead, you can implement a driver with mmap operations and map the driver’s memory in the kernel to the user space.

   Implement the following device driver:

   • The driver creates a “virtual” device which can be accessed from the devfs at /dev/sekvm_shmem.
   • The driver only needs to support open, release, mmap file operations.
   • mmap remaps the shared memory to the user space of the caller. You can assume only PROT_READ and PROT_WRITE will be used as the protection flag and only MAP_SHARED will be used as the mapping flag. You may find remap_pfn_range helpful.
   • Only one process is allowed to open the device and the remapped memory is unmapped on release.
   • For simplicity, you can assume each mmap will only map disjoint pages to the user space, i.e. no remapping for the same kernel memory.