[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7b6d4c14-ebde-1bc3-04de-59cae9d4b7be@quicinc.com>
Date: Fri, 24 Feb 2023 10:08:28 -0800
From: Elliot Berman <quic_eberman@...cinc.com>
To: Fuad Tabba <tabba@...gle.com>
CC: Alex Elder <elder@...aro.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
Murali Nalajala <quic_mnalajal@...cinc.com>,
Trilok Soni <quic_tsoni@...cinc.com>,
Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
Carl van Schaik <quic_cvanscha@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
"Arnd Bergmann" <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Jonathan Corbet <corbet@....net>,
"Bagas Sanjaya" <bagasdotme@...il.com>,
Catalin Marinas <catalin.marinas@....com>,
Jassi Brar <jassisinghbrar@...il.com>,
<linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
"Chao Peng" <chao.p.peng@...ux.intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
Quentin Perret <qperret@...gle.com>,
Will Deacon <will@...nel.org>,
"smoreland@...gle.com" <smoreland@...gle.com>
Subject: Re: [PATCH v10 12/26] gunyah: vm_mgr: Add/remove user memory regions
On 2/24/2023 2:19 AM, Fuad Tabba wrote:
> Hi,
>
> On Tue, Feb 14, 2023 at 9:26 PM Elliot Berman <quic_eberman@...cinc.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>
Powered by blists - more mailing lists