Messages in this thread | | | Date | Fri, 24 Feb 2023 10:08:28 -0800 | Subject | Re: [PATCH v10 12/26] gunyah: vm_mgr: Add/remove user memory regions | From | Elliot Berman <> |
| |
On 2/24/2023 2:19 AM, Fuad Tabba wrote: > Hi, > > On Tue, Feb 14, 2023 at 9:26 PM Elliot Berman <quic_eberman@quicinc.com> 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?
Thanks, Elliot
> > Some comments inline below... > > Cheers, > /fuad > > [1] https://lore.kernel.org/kvmarm/20220519134204.5379-1-will@kernel.org/ > [2] https://lore.kernel.org/kvmarm/20220519134204.5379-34-will@kernel.org/ > [3] https://lore.kernel.org/all/20221202061347.1070246-1-chao.p.peng@linux.intel.com/ > [4] https://lore.kernel.org/lkml/20230127112932.38045-1-steven.price@arm.com/ > [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>
| |