Re: Unmapping KVM Guest Memory from Host Kernel
On 2024-05-13 13:36-0700, Sean Christopherson wrote: > Hmm, a slightly crazy idea (ok, maybe wildly crazy) would be to support > mapping > all of guest_memfd into kernel address space, but as USER=1 mappings. I.e. > don't > require a carve-out from userspace, but do require CLAC/STAC when access guest > memory from the kernel. I think/hope that would provide the speculative > execution > mitigation properties you're looking for? This is interesting. I'm hesitant to rely on SMAP since it can be enforced too late by the microarchitecture. But Canella, et al. [1] did say in 2019 that the kernel->user access route seemed to be free of any "Meltdown" effects. LASS sounds like it will be even stronger, though it's not clear to me from Intel's programming reference that speculative scenarios are in scope [2]. AMD does list SMAP specifically as a feature that can control speculation [3]. I don't see an equivalent read-access control on ARM. It has PXN for execute. Read access can probably also be controlled? But I think for the non-CoCo case we should favor solutions that are less dependent on hardware-specific protections. Derek [1] https://www.usenix.org/system/files/sec19-canella.pdf [2] https://cdrdv2.intel.com/v1/dl/getContent/671368 [3] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/software-techniques-for-managing-speculation.pdf
Re: Unmapping KVM Guest Memory from Host Kernel
On Fri, 8 Mar 2024 15:22:50 -0800, Sean Christopherson wrote: > On Fri, Mar 08, 2024, James Gowans wrote: > > We are also aware of ongoing work on guest_memfd. The current > > implementation unmaps guest memory from VMM address space, but leaves it > > in the kernel’s direct map. We’re not looking at unmapping from VMM > > userspace yet; we still need guest RAM there for PV drivers like virtio > > to continue to work. So KVM’s gmem doesn’t seem like the right solution? > > We (and by "we", I really mean the pKVM folks) are also working on allowing > userspace to mmap() guest_memfd[*]. pKVM aside, the long term vision I have > for > guest_memfd is to be able to use it for non-CoCo VMs, precisely for the > security > and robustness benefits it can bring. > > What I am hoping to do with guest_memfd is get userspace to only map memory it > needs, e.g. for emulated/synthetic devices, on-demand. I.e. to get to a state > where guest memory is mapped only when it needs to be. Thank you for the direction, this is super helpful. We are new to the guest_memfd space, and for simplicity we'd prefer to leave guest_memfd completely mapped in userspace. Even in the long term, we actually don't have any use for unmapping from host userspace. The current form of marking pages shared doesn't quite align with what we're trying to do either since it also shares the pages with the host kernel. What are your thoughts on a flag for KVM_CREATE_GUEST_MEMFD that only removes from the host kernel's direct map, but leaves everything mapped in userspace? Derek
Re: Unmapping KVM Guest Memory from Host Kernel
On 2024-03-08 10:36-0700, David Matlack wrote: > On Fri, Mar 8, 2024 at 8:25 AM Brendan Jackman wrote: > > On Fri, 8 Mar 2024 at 16:50, Gowans, James wrote: > > > Our goal is to more completely address the class of issues whose leak > > > origin is categorized as "Mapped memory" [1]. > > > > Did you forget a link below? I'm interested in hearing about that > > categorisation. The paper from Hertogh, et al. is https://download.vusec.net/papers/quarantine_raid23.pdf specifically Table 1. > > It's perhaps a bigger hammer than you are looking for, but the > > solution we're working on at Google is "Address Space Isolation" (ASI) > > - the latest posting about that is [2]. > > I think what James is looking for (and what we are also interested > in), is _eliminating_ the ability to access guest memory from the > direct map entirely. Actually, just preventing speculation of guest memory through the direct map is sufficient for our current focus. Brendan, I will look into the general ASI approach, thank you. Did you consider memfd_secret or a guest_memfd-based approach for Userspace-ASI? Based on Sean's earlier reply to James it sounds like the vision of guest_memfd aligns with ASI's goals. Derek
Re: Unmapping KVM Guest Memory from Host Kernel
On 2024-03-08 at 10:46-0700, David Woodhouse wrote: > On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote: > > I think what James is looking for (and what we are also interested > > in), is _eliminating_ the ability to access guest memory from the > > direct map entirely. And in general, eliminate the ability to access > > guest memory in as many ways as possible. > > Well, pKVM does that... Yes we've been looking at pKVM and it accomplishes a lot of what we're trying to do. Our initial inclination is that we want to stick with VHE for the lower overhead. We also want flexibility across server parts, so we would need to get pKVM working on Intel & AMD if we went this route. Certainly there are advantages of pKVM on the perf side like the in-place memory sharing rather than copying as well as on the security side by simply reducing the TCB. I'd be interested to hear others' thoughts on pKVM vs memfd_secret or general ASI. Derek
