All of lore.kernel.org
 help / color / mirror / Atom feed
From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: kvm@vger.kernel.org, cohuck@redhat.com, borntraeger@de.ibm.com,
	thuth@redhat.com, pasic@linux.ibm.com, david@redhat.com,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 02/13] KVM: s390: pv: leak the ASCE page when destroy fails
Date: Thu, 29 Jul 2021 14:54:14 +0200	[thread overview]
Message-ID: <20210729145414.62b568cf@p-imbrenda> (raw)
In-Reply-To: <21eb4861-f118-cf3b-409e-ea31694582a5@linux.ibm.com>

On Thu, 29 Jul 2021 12:41:05 +0200
Janosch Frank <frankja@linux.ibm.com> wrote:

> On 7/28/21 4:26 PM, Claudio Imbrenda wrote:
> > When a protected VM is created, the topmost level of page tables of
> > its ASCE is marked by the Ultravisor; any attempt to use that
> > memory for protected virtualization will result in failure.
> > 
> > Only a successful Destroy Configuration UVC will remove the marking.
> > 
> > When the Destroy Configuration UVC fails, the topmost level of page
> > tables of the VM does not get its marking cleared; to avoid issues
> > it must not be used again.
> > 
> > Since the page becomes in practice unusable, we set it aside and
> > leak it.
> > 
> > Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> > ---
> >  arch/s390/kvm/pv.c | 53
> > +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 52
> > insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/s390/kvm/pv.c b/arch/s390/kvm/pv.c
> > index e007df11a2fe..1ecdc1769ed9 100644
> > --- a/arch/s390/kvm/pv.c
> > +++ b/arch/s390/kvm/pv.c
> > @@ -155,6 +155,55 @@ static int kvm_s390_pv_alloc_vm(struct kvm
> > *kvm) return -ENOMEM;
> >  }
> >  
> > +/*
> > + * Remove the topmost level of page tables from the list of page
> > tables of
> > + * the gmap.
> > + * This means that it will not be freed when the VM is torn down,
> > and needs
> > + * to be handled separately by the caller, unless an intentional
> > leak is
> > + * intended.
> > + */
> > +static void kvm_s390_pv_remove_old_asce(struct kvm *kvm)
> > +{
> > +	struct page *old;
> > +
> > +	old = virt_to_page(kvm->arch.gmap->table);
> > +	list_del(&old->lru);
> > +	/* in case the ASCE needs to be "removed" multiple times */
> > +	INIT_LIST_HEAD(&old->lru);
> > +}
> > +
> > +/*
> > + * Try to replace the current ASCE with another equivalent one.
> > + * If the allocation of the new top level page table fails, the
> > ASCE is not
> > + * replaced.
> > + * In any case, the old ASCE is removed from the list, therefore
> > the caller
> > + * has to make sure to save a pointer to it beforehands, unless an
> > + * intentional leak is intended.
> > + */
> > +static int kvm_s390_pv_replace_asce(struct kvm *kvm)
> > +{
> > +	unsigned long asce;
> > +	struct page *page;
> > +	void *table;
> > +
> > +	kvm_s390_pv_remove_old_asce(kvm);
> > +
> > +	page = alloc_pages(GFP_KERNEL_ACCOUNT, CRST_ALLOC_ORDER);
> > +	if (!page)
> > +		return -ENOMEM;
> > +	list_add(&page->lru, &kvm->arch.gmap->crst_list);
> > +
> > +	table = page_to_virt(page);
> > +	memcpy(table, kvm->arch.gmap->table, 1UL <<
> > (CRST_ALLOC_ORDER + PAGE_SHIFT));  
> 
> Don't we want to memcpy first and then add it to the list?
> The gmap is still active per-se so I think we want to take the
> guest_table_lock for the list_add here.

doesn't really make a difference, it is not actually used until a few
lines later

also, the list is only ever touched here, during guest creation and
destruction; IIRC in all those cases we hold kvm->lock

> > +
> > +	asce = (kvm->arch.gmap->asce & ~PAGE_MASK) | __pa(table);
> > +	WRITE_ONCE(kvm->arch.gmap->asce, asce);
> > +	WRITE_ONCE(kvm->mm->context.gmap_asce, asce);
> > +	WRITE_ONCE(kvm->arch.gmap->table, table);  
> 
> If I remember correctly those won't need locks but I'm not 100% sure
> so please have a look at that.

it should not need locks, the VM is in use, so it can't disappear under
our feet.

> > +
> > +	return 0;
> > +}  
> 
> That should both be in gmap.c

why?

> > +
> >  /* this should not fail, but if it does, we must not free the
> > donated memory */ int kvm_s390_pv_deinit_vm(struct kvm *kvm, u16
> > *rc, u16 *rrc) {
> > @@ -169,9 +218,11 @@ int kvm_s390_pv_deinit_vm(struct kvm *kvm, u16
> > *rc, u16 *rrc) atomic_set(&kvm->mm->context.is_protected, 0);
> >  	KVM_UV_EVENT(kvm, 3, "PROTVIRT DESTROY VM: rc %x rrc %x",
> > *rc, *rrc); WARN_ONCE(cc, "protvirt destroy vm failed rc %x rrc
> > %x", *rc, *rrc);
> > -	/* Inteded memory leak on "impossible" error */
> > +	/* Intended memory leak on "impossible" error */
> >  	if (!cc)
> >  		kvm_s390_pv_dealloc_vm(kvm);
> > +	else
> > +		kvm_s390_pv_replace_asce(kvm);
> >  	return cc ? -EIO : 0;
> >  }
> >  
> >   
> 


  reply	other threads:[~2021-07-29 13:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 14:26 [PATCH v2 00/13] KVM: s390: pv: implement lazy destroy Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 01/13] KVM: s390: pv: avoid stall notifications for some UVCs Claudio Imbrenda
2021-07-29  9:58   ` Janosch Frank
2021-07-29 12:52     ` Claudio Imbrenda
2021-07-29 10:49   ` Cornelia Huck
2021-07-29 13:22     ` Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 02/13] KVM: s390: pv: leak the ASCE page when destroy fails Claudio Imbrenda
2021-07-29 10:41   ` Janosch Frank
2021-07-29 12:54     ` Claudio Imbrenda [this message]
2021-07-29 13:45       ` Janosch Frank
2021-07-28 14:26 ` [PATCH v2 03/13] KVM: s390: pv: properly handle page flags for protected guests Claudio Imbrenda
2021-07-29 11:43   ` Janosch Frank
2021-07-28 14:26 ` [PATCH v2 04/13] KVM: s390: pv: handle secure storage violations " Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 05/13] KVM: s390: pv: handle secure storage exceptions for normal guests Claudio Imbrenda
2021-07-29 12:17   ` Janosch Frank
2021-07-29 13:28     ` Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 06/13] KVM: s390: pv: refactor s390_reset_acc Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 07/13] KVM: s390: pv: usage counter instead of flag Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 08/13] KVM: s390: pv: add export before import Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 09/13] KVM: s390: pv: lazy destroy for reboot Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 10/13] KVM: s390: pv: extend lazy destroy to handle shutdown Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 11/13] KVM: s390: pv: module parameter to fence lazy destroy Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 12/13] KVM: s390: pv: add OOM notifier for " Claudio Imbrenda
2021-07-28 14:26 ` [PATCH v2 13/13] KVM: s390: pv: add support for UV feature bits Claudio Imbrenda
2021-07-29  9:52   ` Janosch Frank
2021-07-29 13:28     ` Claudio Imbrenda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210729145414.62b568cf@p-imbrenda \
    --to=imbrenda@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.