Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 01, 2021, David Hildenbrand wrote:
> > > > Well not necessarily, but it depends how clever we want to get.  If
> > > > you look over on the OVMF/edk2 list, there's a proposal to do guest
> > > > migration via a mirror VM that invokes a co-routine embedded in the
> > > > OVMF binary:
> > > 
> > > Yes, I heard of that. "Interesting" design.
> > 
> > Heh, well what other suggestion do you have?  The problem is there
> > needs to be code somewhere to perform some operations that's trusted by
> > both the guest and the host.  The only element for a confidential VM
> > that has this shared trust is the OVMF firmware, so it seems logical to
> > use it.
> 
> <offtopic>
> 
> Let me put it this way: I worked with another architecture that doesn't
> fault on access of a secure page, but instead automatically exports/encrypts

I thought s390 does fault on insecure accesses to secure pages, and it's the
kernel's fault handler that "automatically" converts the page?  E.g. trap 0x3d
-> do_secure_storage_access() -> arch_make_page_accessible().

> it so it can be swapped. It doesn't send a MCE and kills the host. It
> doesn't require fancy code in the guest firmware to export a page.
> 
> The code runs in the ultravisor -- yes, I'm talking about s390x. Now, I am
> not an expert on all of the glory details of TDX, SEV, ... to say which
> attack surface they introduced with that design, and if it can't be
> mitigated. I can only assume that there are real reasons (e.g., supporting
> an ultravisor is problematic, patents? ;) ) why x86-64 is different.
>
> So whenever I see something really complicated to work around such issues,
> it feels to me like a hardware/platform limitation is making our life hard
> and forces us to come up with such "interesting" designs.

Oh, 100% agree, the TDX "limitation" of poisoning cache line and leaving a land
mine to trip over is absolutely abhorrent.  SEV-ES and SEV aren't much better in
that they happily corrupt guest memory.  I am quite jealous of s390 behavior of
simply faulting on the actual access.

SEV-SNP does fault on the access and could do something similar to s390, but I'm
not totally convinced that's actually desirable as it has ramifications with
respect to debugging host and/or guest.  But it'd be nice to have the option...

> Sure, it's logical in this context, but it feels like "The house doesn't

Heh, for some definitions of "logical".

> have a door, so I'll have to climb through the window.". It gets the job
> done but isn't ideally what you'd want to have. If you understand what I am
> trying to say :)
> 
> </offtopic>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux