Re: [PATCH 10/12] mm: x86: Invoke hypercall when page encryption status is changed

[Brijesh Singh]

On 2/19/20 8:12 PM, Andy Lutomirski wrote:
> > On Feb 19, 2020, at 5:58 PM, Steve Rutherford <srutherford@xxxxxxxxxx> wrote:
> >
> > ïOn Wed, Feb 12, 2020 at 5:18 PM Ashish Kalra <Ashish.Kalra@xxxxxxx> wrote:
> > > From: Brijesh Singh <brijesh.singh@xxxxxxx>
> > >
> > > Invoke a hypercall when a memory region is changed from encrypted ->
> > > decrypted and vice versa. Hypervisor need to know the page encryption
> > > status during the guest migration.
> >
> > One messy aspect, which I think is fine in practice, is that this
> > presumes that pages are either treated as encrypted or decrypted. If
> > also done on SEV, the in-place re-encryption supported by SME would
> > break SEV migration. Linux doesn't do this now on SEV, and I don't
> > have an intuition for why Linux might want this, but we will need to
> > ensure it is never done in order to ensure that migration works down
> > the line. I don't believe the AMD manual promises this will work
> > anyway.
> >
> > Something feels a bit wasteful about having all future kernels
> > universally announce c-bit status when SEV is enabled, even if KVM
> > isn't listening, since it may be too old (or just not want to know).
> > Might be worth eliding the hypercalls if you get ENOSYS back? There
> > might be a better way of passing paravirt config metadata across than
> > just trying and seeing if the hypercall succeeds, but I'm not super
> > familiar with it.
>
> I actually think this should be a hard requirement to merge this. The host needs to tell the guest that it supports this particular migration strategy and the guest needs to tell the host that it is using it.  And the guest needs a way to tell the host that itâs *not* using it right now due to kexec, for example.
>
> Iâm still uneasy about a guest being migrated in the window where the hypercall tracking and the page encryption bit donât match.  I guess maybe corruption in this window doesnât matter?

I don't think there is a corruption issue here. Let's consider the below
case:

1) A page is transmitted as C=1 (encrypted)

2) During the migration window, the page encryption bit is changed
 to C=0 (decrypted)

3) #2 will cause a change in page table memory, thus dirty memory
 the tracker will create retransmission of the page table memory.

4) The page itself will not be re-transmitted because there was
 no change to the content of the page.

On destination, the read from the page will get the ciphertext.

The encryption bit change in the page table is used on the next access.
The user of the page needs to ensure that data is written with the
correct encryption bit before reading.

thanks