[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unmapping KVM Guest Memory from Host Kernel
From: |
Manwaring, Derek |
Subject: |
Re: Unmapping KVM Guest Memory from Host Kernel |
Date: |
Fri, 8 Mar 2024 19:45:57 -0700 |
User-agent: |
Mozilla Thunderbird |
On 2024-03-08 10:36-0700, David Matlack wrote:
> On Fri, Mar 8, 2024 at 8:25 AM Brendan Jackman <jackmanb@google.com> wrote:
> > On Fri, 8 Mar 2024 at 16:50, Gowans, James <jgowans@amazon> 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, Sean Christopherson, 2024/03/08
Re: Unmapping KVM Guest Memory from Host Kernel, Matthew Wilcox, 2024/03/09