lkml.org 
[lkml]   [2021]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory


On Thu, Sep 2, 2021, at 12:07 PM, Dave Hansen wrote:
> On 9/2/21 11:57 AM, Sean Christopherson wrote:
> > On Thu, Sep 02, 2021, Andy Lutomirski wrote:
> >> On 9/2/21 2:27 AM, Joerg Roedel wrote:
> >>> On Wed, Sep 01, 2021 at 09:07:59AM -0700, Andy Lutomirski wrote:
> >>>> 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 :)

\
 
 \ /
  Last update: 2021-09-02 22:43    [W:0.077 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site