Hi, On Fri, Feb 24, 2023 at 6:08 PM Elliot Berman <quic_eberman@xxxxxxxxxxx> wrote: > > > > On 2/24/2023 2:19 AM, Fuad Tabba wrote: > > Hi, > > > > On Tue, Feb 14, 2023 at 9:26 PM Elliot Berman <quic_eberman@xxxxxxxxxxx> wrote: > >> > >> > >> When launching a virtual machine, Gunyah userspace allocates memory for > >> the guest and informs Gunyah about these memory regions through > >> SET_USER_MEMORY_REGION ioctl. > > > > I'm working on pKVM [1], and regarding the problem of donating private > > memory to a guest, we and others working on confidential computing > > have faced a similar issue that this patch is trying to address. In > > pKVM, we've initially taken an approach similar to the one here by > > pinning the pages being donated to prevent swapping or migration [2]. > > However, we've encountered issues with this approach since the memory > > is still mapped by the host, which could cause the system to crash on > > an errant access. > > > > Instead, we've been working on adopting an fd-based restricted memory > > approach that was initially proposed for TDX [3] and is now being > > considered by others in the confidential computing space as well > > (e.g., Arm CCA [4]). The basic idea is that the host manages the guest > > memory via a file descriptor instead of a userspace address. It cannot > > map that memory (unless explicitly shared by the guest [5]), > > eliminating the possibility of the host trying to access private > > memory accidentally or being tricked by a malicious actor. This is > > based on memfd with some restrictions. It handles swapping and > > migration by disallowing them (for now [6]), and adds a new type of > > memory region to KVM to accommodate having an fd representing guest > > memory. > > > > Although the fd-based restricted memory isn't upstream yet, we've > > ported the latest patches to arm64 and made changes and additions to > > make it work with pKVM, to test it and see if the solution is feasible > > for us (it is). I wanted to mention this work in case you find it > > useful, and in the hopes that we can all work on confidential > > computing using the same interfaces as much as possible. > > Thanks for highlighting the memfd_restricted changes to us! We'll > investigate how/if it can suit Gunyah usecases. It sounds like you > might've made memfd_restricted changes as well? Are those posted on the > mailing lists? Also, are example userspace (crosvm?) changes posted? I have posted kvmtool changes to make it work with memfd_restricted and pKVM as an RFC [1] (git [2]). I haven't posted the arm64 port, but it's in a git repo [3]. Chao has a repository with qemu support (TDX) as well [4]. Eventually, we're likely to have crosvm support as well. If you're interested, I can keep you CCed on anything we post upstream. Cheers, /fuad [1] https://lore.kernel.org/all/20221202174417.1310826-1-tabba@xxxxxxxxxx/ [2] https://android-kvm.googlesource.com/kvmtool/+/refs/heads/tabba/fdmem-v10-core [3] https://android-kvm.googlesource.com/linux/+/refs/heads/tabba/fdmem-v10-core [4] https://github.com/chao-p/qemu/tree/privmem-v10 > > Thanks, > Elliot > > > > > Some comments inline below... > > > > Cheers, > > /fuad > > > > [1] https://lore.kernel.org/kvmarm/20220519134204.5379-1-will@xxxxxxxxxx/ > > [2] https://lore.kernel.org/kvmarm/20220519134204.5379-34-will@xxxxxxxxxx/ > > [3] https://lore.kernel.org/all/20221202061347.1070246-1-chao.p.peng@xxxxxxxxxxxxxxx/ > > [4] https://lore.kernel.org/lkml/20230127112932.38045-1-steven.price@xxxxxxx/ > > [5] This is a modification we've done for the arm64 port, after > > discussing it with the original authors. > > [6] Nothing inherent in the proposal to stop migration and swapping. > > There are some technical issues that need to be resolved. > > > > <snip> > <snip, looking at comments in parallel>
