On Tue, May 30, 2023, Rick P Edgecombe wrote:
On Fri, 2023-05-26 at 17:22 +0200, Micka�l Sala�n wrote:
Can the guest kernel ask the host VMM's emulated devices to DMA into
the protected data? It should go through the host userspace mappings I
think, which don't care about EPT permissions. Or did I miss where you
are protecting that another way? There are a lot of easy ways to ask
the host to write to guest memory that don't involve the EPT. You
probably need to protect the host userspace mappings, and also the
places in KVM that kmap a GPA provided by the guest.
Good point, I'll check this confused deputy attack. Extended KVM
protections should indeed handle all ways to map guests' memory. I'm
wondering if current VMMs would gracefully handle such new restrictions
though.
I guess the host could map arbitrary data to the guest, so that need to be
handled, but how could the VMM (not the host kernel) bypass/update EPT
initially used for the guest (and potentially later mapped to the host)?
Well traditionally both QEMU and KVM accessed guest memory via host
mappings instead of the EPT.�So I'm wondering what is stopping the
guest from passing a protected gfn when setting up the DMA, and QEMU
being enticed to write to it? The emulator as well would use these host
userspace mappings and not consult the EPT IIRC.
I think Sean was suggesting host userspace should be more involved in
this process, so perhaps it could protect its own alias of the
protected memory, for example mprotect() it as read-only.
Ya, though "suggesting" is really "demanding, unless someone provides super
strong
justification for handling this directly in KVM". It's basically the same
argument
that led to Linux Security Modules: I'm all for KVM providing the framework and
plumbing, but I don't want KVM to get involved in defining policy, thread
models, etc.