Re: [PATCH v3 0/9] Generalize memory encryption models

[Christian Borntraeger]

On 19.06.20 04:05, David Gibson wrote:
> A number of hardware platforms are implementing mechanisms whereby the
> hypervisor does not have unfettered access to guest memory, in order
> to mitigate the security impact of a compromised hypervisor.
> 
> AMD's SEV implements this with in-cpu memory encryption, and Intel has
> its own memory encryption mechanism.  POWER has an upcoming mechanism
> to accomplish this in a different way, using a new memory protection
> level plus a small trusted ultravisor.  s390 also has a protected
> execution environment.
> 
> The current code (committed or draft) for these features has each
> platform's version configured entirely differently.  That doesn't seem
> ideal for users, or particularly for management layers.
> 
> AMD SEV introduces a notionally generic machine option
> "machine-encryption", but it doesn't actually cover any cases other
> than SEV.
> 
> This series is a proposal to at least partially unify configuration
> for these mechanisms, by renaming and generalizing AMD's
> "memory-encryption" property.  It is replaced by a
> "host-trust-limitation" property pointing to a platform specific
> object which configures and manages the specific details.
> 
> For now this series covers just AMD SEV and POWER PEF.  I'm hoping it
> can be extended to cover the Intel and s390 mechanisms as well,
> though.

Let me try to summarize what I understand what you try to achieve:
one command line parameter for all platforms that 

common across all platforms:
- disable KSM
- by default enables iommu_platform


per platform:
- setup the necessary encryption scheme when appropriate
- block migration
-....


The tricky part is certainly the per platform thing. For example on
s390 we just have a cpumodel flag that provides interfaces to the guest
to switch into protected mode via the ultravisor. This works perfectly
fine with the host model, so no need to configure anything.  The platform
code then disables KSM _on_switchover_ and not in general. Because the 
guest CAN switch into protected, but it does not have to.

So this feels really hard to do right. Would a virtual BoF on KVM forum
be too late? We had a BoF on protected guests last year and that was
valuable.