On Fri, 8 Mar 2024 at 18:36, David Matlack <dmatlack@xxxxxxxxxx> wrote: > 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. Yes, there's also a sense in which ASI is a "smaller hammer" in that it _only_ protects against hardware-bug exploits. > it just prevents speculation of guest memory through the > direct map. (Although, this is not _all_ it does, because when returning to the restricted address space, i.e. right before VM Enter, we have an opportunity to flush _data buffers_ too. So ASI also mitigates Meltdown-style attacks, e.g. L1TF, where the speculation-related stuff all happens on the attacker side) On Sat, 9 Mar 2024 at 03:46, Manwaring, Derek <derekmn@xxxxxxxxxx> wrote: > 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? I might be misunderstanding you here: I guess you mean using memfd_secret as a way for userspace to communicate about which parts of userspace memory are "secret"? If I didn't misunderstand: we have not looked into this so far because we actually just consider _all_ userspace/guest memory to be "secret" from the perspective of other processes/guests. > Based on > Sean's earlier reply to James it sounds like the vision of guest_memfd > aligns with ASI's goals. But yes, the more general point seems to make sense, I think I need to research this topic some more, thanks!
