All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janosch Frank <frankja@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>, kvm@vger.kernel.org
Cc: borntraeger@de.ibm.com, thuth@redhat.com, pasic@linux.ibm.com,
	david@redhat.com, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, scgl@linux.ibm.com,
	mimu@linux.ibm.com, nrb@linux.ibm.com
Subject: Re: [PATCH v10 01/19] KVM: s390: pv: leak the topmost page table when destroy fails
Date: Thu, 14 Apr 2022 13:30:33 +0200	[thread overview]
Message-ID: <cc057c0a-58ee-1012-34e4-575b053230db@linux.ibm.com> (raw)
In-Reply-To: <20220414080311.1084834-2-imbrenda@linux.ibm.com>

On 4/14/22 10:02, Claudio Imbrenda wrote:
> Each secure guest must have a unique ASCE (address space control
> element); we must avoid that new guests use the same page for their
> ASCE, to avoid errors.
> 
> Since the ASCE mostly consists of the address of the topmost page table
> (plus some flags), we must not return that memory to the pool unless
> the ASCE is no longer in use.
> 
> Only a successful Destroy Secure Configuration UVC will make the ASCE
> reusable again.
> 
> If the Destroy Configuration UVC fails, the ASCE cannot be reused for a
> secure guest (either for the ASCE or for other memory areas). To avoid
> a collision, it must not be used again. This is a permanent error and
> the page becomes in practice unusable, so we set it aside and leak it.
> On failure we already leak other memory that belongs to the ultravisor
> (i.e. the variable and base storage for a guest) and not leaking the
> topmost page table was an oversight.
> 
> This error (and thus the leakage) should not happen unless the hardware
> is broken or KVM has some unknown serious bug.
> 

Reviewed-by: Janosch Frank <frankja@linux.ibm.com>

> +	/*
> +	 * In case the ASCE needs to be "removed" multiple times, for example
> +	 * if the VM is rebooted into secure mode several times
> +	 * concurrently, or if s390_replace_asce fails after calling
> +	 * s390_remove_old_asce and is attempted again later. In that case
> +	 * the old asce has been removed from the list, and therefore it
> +	 * will not be freed when the VM terminates, but the ASCE is still
> +	 * in use and still pointed to.
> +	 * A subsequent call to replace_asce will follow the pointer and try
> +	 * to remove the same page from the list again.
> +	 * Therefore it's necessary that the page of the ASCE has valid
> +	 * pointers, so list_del can work (and do nothing) without
> +	 * dereferencing stale or invalid pointers.
> +	 */
> +	INIT_LIST_HEAD(&old->lru);
> +	spin_unlock(&gmap->guest_table_lock);
> +}
> +EXPORT_SYMBOL_GPL(s390_remove_old_asce);
> +
> +/**
> + * s390_replace_asce - Try to replace the current ASCE of a gmap with
> + * another equivalent one.

with a copy?

> + * @gmap the gmap
> + *
> + * If the allocation of the new top level page table fails, the ASCE is not
> + * replaced.
> + * In any case, the old ASCE is always removed from the list. Therefore the

removed from the gmap crst list

> + * caller has to make sure to save a pointer to it beforehands, unless an
> + * intentional leak is intended.
> + */
> +int s390_replace_asce(struct gmap *gmap)
> +{
> +	unsigned long asce;
> +	struct page *page;
> +	void *table;
> +
> +	s390_remove_old_asce(gmap);
> +
> +	page = alloc_pages(GFP_KERNEL_ACCOUNT, CRST_ALLOC_ORDER);
> +	if (!page)
> +		return -ENOMEM;
> +	table = page_to_virt(page);
> +	memcpy(table, gmap->table, 1UL << (CRST_ALLOC_ORDER + PAGE_SHIFT));
> +
> +	/*
> +	 * The caller has to deal with the old ASCE, but here we make sure
> +	 * the new one is properly added to the list of page tables, so that
> +	 * it will be freed when the VM is torn down.
> +	 */
> +	spin_lock(&gmap->guest_table_lock);
> +	list_add(&page->lru, &gmap->crst_list);
> +	spin_unlock(&gmap->guest_table_lock);
> +
> +	/* Set new table origin while preserving existing ASCE control bits */
> +	asce = (gmap->asce & ~_ASCE_ORIGIN) | __pa(table);
> +	WRITE_ONCE(gmap->asce, asce);
> +	WRITE_ONCE(gmap->mm->context.gmap_asce, asce);
> +	WRITE_ONCE(gmap->table, table);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(s390_replace_asce);


  reply	other threads:[~2022-04-14 11:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14  8:02 [PATCH v10 00/19] KVM: s390: pv: implement lazy destroy for reboot Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 01/19] KVM: s390: pv: leak the topmost page table when destroy fails Claudio Imbrenda
2022-04-14 11:30   ` Janosch Frank [this message]
2022-04-14 12:19     ` Claudio Imbrenda
2022-05-05 14:45   ` Thomas Huth
2022-05-06 11:30     ` Claudio Imbrenda
2022-05-16  7:22   ` Nico Boehr
2022-05-16 15:55     ` Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 02/19] KVM: s390: pv: handle secure storage violations for protected guests Claudio Imbrenda
2022-05-05 17:10   ` Thomas Huth
2022-05-06 11:33     ` Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 03/19] KVM: s390: pv: handle secure storage exceptions for normal guests Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 04/19] KVM: s390: pv: refactor s390_reset_acc Claudio Imbrenda
2022-05-16  8:04   ` Nico Boehr
2022-05-16 16:11     ` Claudio Imbrenda
2022-05-30  7:40       ` Nico Boehr
2022-05-30 10:50         ` Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 05/19] KVM: s390: pv: usage counter instead of flag Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 06/19] KVM: s390: pv: add export before import Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 07/19] KVM: s390: pv: module parameter to fence lazy destroy Claudio Imbrenda
2022-04-14  8:02 ` [PATCH v10 08/19] KVM: s390: pv: clear the state without memset Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 09/19] KVM: s390: pv: Add kvm_s390_cpus_from_pv to kvm-s390.h and add documentation Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 10/19] KVM: s390: pv: add mmu_notifier Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 11/19] s390/mm: KVM: pv: when tearing down, try to destroy protected pages Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 12/19] KVM: s390: pv: refactoring of kvm_s390_pv_deinit_vm Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 13/19] KVM: s390: pv: destroy the configuration before its memory Claudio Imbrenda
2022-05-30  7:37   ` Nico Boehr
2022-05-30 12:05     ` Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 14/19] KVM: s390: pv: cleanup leftover protected VMs if needed Claudio Imbrenda
2022-05-30  8:11   ` Nico Boehr
2022-05-30 10:43     ` Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 15/19] KVM: s390: pv: asynchronous destroy for reboot Claudio Imbrenda
2022-05-30  9:46   ` Nico Boehr
2022-05-30 11:06     ` Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 16/19] KVM: s390: pv: api documentation for asynchronous destroy Claudio Imbrenda
2022-05-30  9:47   ` Nico Boehr
2022-04-14  8:03 ` [PATCH v10 17/19] KVM: s390: pv: add KVM_CAP_S390_PROTECTED_ASYNC_DISABLE Claudio Imbrenda
2022-05-30 10:24   ` Nico Boehr
2022-04-14  8:03 ` [PATCH v10 18/19] KVM: s390: pv: avoid export before import if possible Claudio Imbrenda
2022-05-30 10:07   ` Nico Boehr
2022-05-30 11:16     ` Claudio Imbrenda
2022-04-14  8:03 ` [PATCH v10 19/19] KVM: s390: pv: support for Destroy fast UVC 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=cc057c0a-58ee-1012-34e4-575b053230db@linux.ibm.com \
    --to=frankja@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mimu@linux.ibm.com \
    --cc=nrb@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=scgl@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.