linux-kernel - Re: [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YC6o4YwTAOU7UE1u@google.com>
Date:   Thu, 18 Feb 2021 09:50:25 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     "Kalra, Ashish" <Ashish.Kalra@....com>
Cc:     "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "rkrcmar@...hat.com" <rkrcmar@...hat.com>,
        "joro@...tes.org" <joro@...tes.org>, "bp@...e.de" <bp@...e.de>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "srutherford@...gle.com" <srutherford@...gle.com>,
        "venu.busireddy@...cle.com" <venu.busireddy@...cle.com>,
        "Singh, Brijesh" <brijesh.singh@....com>
Subject: Re: [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES_LIST
 ioctl

On Thu, Feb 18, 2021, Kalra, Ashish wrote:
> From: Sean Christopherson <seanjc@...gle.com> 
> 
> On Thu, Feb 18, 2021, Kalra, Ashish wrote:
> > From: Sean Christopherson <seanjc@...gle.com>
> > 
> > On Wed, Feb 17, 2021, Kalra, Ashish wrote:
> > >> From: Sean Christopherson <seanjc@...gle.com> On Thu, Feb 04, 2021, 
> > >> Ashish Kalra wrote:
> > >> > From: Brijesh Singh <brijesh.singh@....com>
> > >> > 
> > >> > The ioctl is used to retrieve a guest's shared pages list.
> > >> 
> > >> >What's the performance hit to boot time if KVM_HC_PAGE_ENC_STATUS 
> > >> >is passed through to userspace?  That way, userspace could manage 
> > >> >the set of pages >in whatever data structure they want, and these get/set ioctls go away.
> > >> 
> > >> What is the advantage of passing KVM_HC_PAGE_ENC_STATUS through to 
> > >> user-space ?
> > >> 
> > >> As such it is just a simple interface to get the shared page list 
> > >> via the get/set ioctl's. simply an array is passed to these ioctl 
> > >> to get/set the shared pages list.
> >> 
> >> > It eliminates any probability of the kernel choosing the wrong data 
> >> > structure, and it's two fewer ioctls to maintain and test.
> >> 
> >> The set shared pages list ioctl cannot be avoided as it needs to be 
> >> issued to setup the shared pages list on the migrated VM, it cannot be 
> >> achieved by passing KVM_HC_PAGE_ENC_STATUS through to user-space.
> 
> >Why's that?  AIUI, KVM doesn't do anything with the list other than pass it
> >back to userspace.  Assuming that's the case, userspace can just hold onto
> >the list >for the next migration.
> 
> KVM does use it as part of the SEV DBG_DECTYPT API, within sev_dbg_decrypt()
> to check if the guest page(s) are encrypted or not, and accordingly use it to
> decide whether to decrypt the guest page(s) and return that back to
> user-space or just return it as it is.

Why is handling shared memory KVM's responsibility?  Userspace shouldn't be
asking KVM to decrypt memory it knows isn't encrypted.  My understanding is that
bogus decryption won't harm the kernel, it will only corrupt the guest.  In
other words, patch 16 can be dropped if managing the set of shared pages is
punted to userspace.