Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory
From: "Andy Lutomirski" <luto@kernel.org>
Date: 2021-09-02 20:42:59
Also in:
kvm, linux-coco, lkml
From: "Andy Lutomirski" <luto@kernel.org>
Date: 2021-09-02 20:42:59
Also in:
kvm, linux-coco, lkml
On Thu, Sep 2, 2021, at 12:07 PM, Dave Hansen wrote:
On 9/2/21 11:57 AM, Sean Christopherson wrote:quoted
On Thu, Sep 02, 2021, Andy Lutomirski wrote:quoted
On 9/2/21 2:27 AM, Joerg Roedel wrote:quoted
On Wed, Sep 01, 2021 at 09:07:59AM -0700, Andy Lutomirski wrote:quoted
In principle, you could actually initialize a TDX guest with all of its memory shared and all of it mapped in the host IOMMU.Not sure how this works in TDX, but in SEV code fetches are always treated as encrypted. So this approach would not work with SEV, not to speak about attestation, which will not work with this approach either :)Oof.TDX is kinda similar. _All_ accesses are private if paging is disabled because the shared bit is either bit 48 or bit 51 in the GPA, i.e. can't be reached if paging is disabled. The vCPU is hardcoded to start in unpaged protected mode, so at least some amount of guest memory needs to be private.That's a rule we should definitely add to our page table checker. Just like how we can look for W+X, we should also look for Shared+X.
The only case I can thing of where the TDX vs SEV rule matters is for some mildly crazy user who wants to run user code out of an unencrypted DAX device (or virtio-fs, I guess). We can save that for another year :)