On 2024-03-08 10:36-0700, David Matlack wrote: > On Fri, Mar 8, 2024 at 8:25 AM Brendan Jackman <jackmanb@xxxxxxxxxx> 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
