On Fri, Mar 8, 2024 at 8:25 AM Brendan Jackman <jackmanb@xxxxxxxxxx> wrote: > > Hi James > > On Fri, 8 Mar 2024 at 16:50, Gowans, James <jgowans@xxxxxxxxxx> 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. > > > ... what’s the best way to solve getting guest RAM out of > > the direct map? > > 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]. > > The sense in which it's a bigger hammer is that it doesn't only > support removing guest memory from the direct map, but rather > arbitrary data from arbitrary kernel mappings. I'm not sure if ASI provides a solution to the problem James is trying to solve. ASI creates a separate "restricted" address spaces where, yes, guest memory can be not mapped. But any access to guest memory is still allowed. An access will trigger a page fault, the kernel will switch to the "full" kernel address space (flushing hardware buffers along the way to prevent speculation), and then proceed. i.e. ASI doesn't not prevent accessing guest memory through the direct map, it just prevents speculation of guest memory through the direct map. 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. For that goal, I have been thinking about guest_memfd as a solution. Yes guest_memfd today is backed by pages of memory that are mapped in the direct map. But what we can do is add the ability to back guest_memfd by pages of memory that aren't in the direct map. I haven't thought it fully through yet but something like... Hide the majority of RAM from Linux (I believe there are kernel parameters to do this) and hand it off to guest_memfd to allocate from as a source of guest memory. Then the only way to access guest memory is to mmap() a guest_memfd (e.g. for PV userspace devices).
