linux-kernel - Re: [PATCH v5 6/6] x86/kvm: Add kexec support for SEV Live Migration.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210818000436.GA31519@ashkalra_ubuntu_server>
Date:   Wed, 18 Aug 2021 00:04:36 +0000
From:   Ashish Kalra <ashish.kalra@....com>
To:     Steve Rutherford <srutherford@...gle.com>
Cc:     pbonzini@...hat.com, seanjc@...gle.com, tglx@...utronix.de,
        mingo@...hat.com, hpa@...or.com, joro@...tes.org, bp@...en8.de,
        thomas.lendacky@....com, x86@...nel.org, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, brijesh.singh@....com
Subject: Re: [PATCH v5 6/6] x86/kvm: Add kexec support for SEV Live Migration.

Hello Steve,

On Tue, Aug 17, 2021 at 03:50:22PM -0700, Steve Rutherford wrote:
> On Tue, Jun 29, 2021 at 8:14 AM Ashish Kalra <Ashish.Kalra@....com> wrote:
> >
> > From: Ashish Kalra <ashish.kalra@....com>
> >
> > Reset the host's shared pages list related to kernel
> > specific page encryption status settings before we load a
> > new kernel by kexec. We cannot reset the complete
> > shared pages list here as we need to retain the
> > UEFI/OVMF firmware specific settings.
> >
> > The host's shared pages list is maintained for the
> > guest to keep track of all unencrypted guest memory regions,
> > therefore we need to explicitly mark all shared pages as
> > encrypted again before rebooting into the new guest kernel.
> >
> > Signed-off-by: Ashish Kalra <ashish.kalra@....com>
> > ---
> >  arch/x86/kernel/kvm.c | 25 +++++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > index a014c9bb5066..a55712ee58a1 100644
> > --- a/arch/x86/kernel/kvm.c
> > +++ b/arch/x86/kernel/kvm.c
> > @@ -869,10 +869,35 @@ static void __init kvm_init_platform(void)
> >         if (sev_active() &&
> >             kvm_para_has_feature(KVM_FEATURE_MIGRATION_CONTROL)) {
> >                 unsigned long nr_pages;
> > +               int i;
> >
> >                 pv_ops.mmu.notify_page_enc_status_changed =
> >                         kvm_sev_hc_page_enc_status;
> >
> > +               /*
> > +                * Reset the host's shared pages list related to kernel
> > +                * specific page encryption status settings before we load a
> > +                * new kernel by kexec. Reset the page encryption status
> > +                * during early boot intead of just before kexec to avoid SMP
> > +                * races during kvm_pv_guest_cpu_reboot().
> > +                * NOTE: We cannot reset the complete shared pages list
> > +                * here as we need to retain the UEFI/OVMF firmware
> > +                * specific settings.
> > +                */
> > +
> > +               for (i = 0; i < e820_table->nr_entries; i++) {
> > +                       struct e820_entry *entry = &e820_table->entries[i];
> > +
> > +                       if (entry->type != E820_TYPE_RAM)
> > +                               continue;
> > +
> > +                       nr_pages = DIV_ROUND_UP(entry->size, PAGE_SIZE);
> > +
> > +                       kvm_hypercall3(KVM_HC_MAP_GPA_RANGE, entry->addr,
> > +                                      nr_pages,
> > +                                      KVM_MAP_GPA_RANGE_ENCRYPTED | KVM_MAP_GPA_RANGE_PAGE_SZ_4K);
> > +               }
> > +
> >                 /*
> >                  * Ensure that _bss_decrypted section is marked as decrypted in the
> >                  * shared pages list.
> > --
> > 2.17.1
> >
> I believe this entire series has been reviewed. Is there any appetite
> to queue these for 915?
> They may need to be resent, since I'm not sure there is a single patch
> series that contains all the patches.
> 

I believe that there are couple or more patches still pending an ACK.

Patch#1 of this series which basically inverts the KVM hypercall from
VMCALL to VMMCALL probably needs an ack from either Sean or 
Paolo.

While Patch #4 was ack'ed by Boris, it still has a dependency on Patch
#1. 

Patch #5 & #6 need to be ack'ed by Boris, again have dependency on Patch
#1.

I am more than happy to send this guest kernel and guest API patch-set
for live migration again.

Please note that this guest kernel and guest API patch-set which is
essentially guest hypercall invocations are needed for both in-guest
migration and PSP based migration as they are used for tracking guest
page(s) encryption status.

Thanks,
Ashish