Thread (71 messages) 71 messages, 15 authors, 2021-09-16

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


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 :)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help