On Tue, 2025-07-22 at 11:17 -0700, Ackerley Tng wrote: > Sounds like a malicious guest could skip unpinning private memory, and > guest_memfd's unmap will fail, leading to a KVM_BUG_ON() as Yan/Rick > suggested here [1]. > > Actually it seems like a legacy guest would also lead to unmap failures > and the KVM_BUG_ON(), since when TDX connect is enabled, the pinning > mode is enforced, even for non-IO private pages? > > I hope your team's investigations find a good way for the host to > reclaim memory, at least from dead TDs! Otherwise this would be an open > hole for guests to leak a host's memory. > > Circling back to the original topic [2], it sounds like we're okay for > IOMMU to *not* take any refcounts on pages and can rely on guest_memfd > to keep the page around on behalf of the VM? > > [1] https://lore.kernel.org/all/diqzcya13x2j.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > [2] https://lore.kernel.org/all/CAGtprH_qh8sEY3s-JucW3n1Wvoq7jdVZDDokvG5HzPf0HV2=pg@xxxxxxxxxxxxxx/ Djbw, Yilun and I had a chat yesterday. We'll investigate a way to have an operation that can't fail and will allow total cleanup and reclaim for the TD's resources, as well as a per-TDX module scoped version. If host userspace or the guest kernel does something wrong, the guest can be destroyed in the normal VM case. So we can try to use these operations as a way to save host kernel complexity for cases like that. But if an error condition might come up in normal cases (i.e. rare races, non-bugs) we need to look to other error handling solutions. We were planning to investigate first and then share back to the list. It probably deserves broader consideration beyond folks still reading deep down in this thread.
