linux-kernel - Re: [PATCH v3 12/32] KVM: arm64: Introduce a Hyp buddy page allocator

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: <20210304153036.GA21507@willie-the-truck>
Date:   Thu, 4 Mar 2021 15:30:36 +0000
From:   Will Deacon <will@...nel.org>
To:     Quentin Perret <qperret@...gle.com>
Cc:     catalin.marinas@....com, maz@...nel.org, james.morse@....com,
        julien.thierry.kdev@...il.com, suzuki.poulose@....com,
        android-kvm@...gle.com, linux-kernel@...r.kernel.org,
        kernel-team@...roid.com, kvmarm@...ts.cs.columbia.edu,
        linux-arm-kernel@...ts.infradead.org, tabba@...gle.com,
        mark.rutland@....com, dbrazdil@...gle.com, mate.toth-pal@....com,
        seanjc@...gle.com, robh+dt@...nel.org
Subject: Re: [PATCH v3 12/32] KVM: arm64: Introduce a Hyp buddy page allocator

On Tue, Mar 02, 2021 at 02:59:42PM +0000, Quentin Perret wrote:
> When memory protection is enabled, the hyp code will require a basic
> form of memory management in order to allocate and free memory pages at
> EL2. This is needed for various use-cases, including the creation of hyp
> mappings or the allocation of stage 2 page tables.
> 
> To address these use-case, introduce a simple memory allocator in the
> hyp code. The allocator is designed as a conventional 'buddy allocator',
> working with a page granularity. It allows to allocate and free
> physically contiguous pages from memory 'pools', with a guaranteed order
> alignment in the PA space. Each page in a memory pool is associated
> with a struct hyp_page which holds the page's metadata, including its
> refcount, as well as its current order, hence mimicking the kernel's
> buddy system in the GFP infrastructure. The hyp_page metadata are made
> accessible through a hyp_vmemmap, following the concept of
> SPARSE_VMEMMAP in the kernel.
> 
> Signed-off-by: Quentin Perret <qperret@...gle.com>
> ---
>  arch/arm64/kvm/hyp/include/nvhe/gfp.h    |  55 +++++++
>  arch/arm64/kvm/hyp/include/nvhe/memory.h |  28 ++++
>  arch/arm64/kvm/hyp/nvhe/Makefile         |   2 +-
>  arch/arm64/kvm/hyp/nvhe/page_alloc.c     | 195 +++++++++++++++++++++++
>  4 files changed, 279 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/kvm/hyp/include/nvhe/gfp.h
>  create mode 100644 arch/arm64/kvm/hyp/nvhe/page_alloc.c

[...]

> +static void __hyp_attach_page(struct hyp_pool *pool,
> +			      struct hyp_page *p)
> +{
> +	unsigned int order = p->order;
> +	struct hyp_page *buddy;
> +
> +	memset(hyp_page_to_virt(p), 0, PAGE_SIZE << p->order);
> +
> +	/*
> +	 * Only the first struct hyp_page of a high-order page (otherwise known
> +	 * as the 'head') should have p->order set. The non-head pages should
> +	 * have p->order = HYP_NO_ORDER. Here @p may no longer be the head
> +	 * after coallescing, so make sure to mark it HYP_NO_ORDER proactively.
> +	 */
> +	p->order = HYP_NO_ORDER;
> +	for (; (order + 1) < pool->max_order; order++) {
> +		buddy = __find_buddy_avail(pool, p, order);
> +		if (!buddy)
> +			break;
> +
> +		/* Take the buddy out of its list, and coallesce with @p */
> +		list_del_init(&buddy->node);
> +		buddy->order = HYP_NO_ORDER;
> +		p = (p < buddy) ? p : buddy;

nit: this is min()

> +	}
> +
> +	/* Mark the new head, and insert it */
> +	p->order = order;
> +	list_add_tail(&p->node, &pool->free_area[order]);
> +}
> +
> +static void hyp_attach_page(struct hyp_page *p)
> +{
> +	struct hyp_pool *pool = hyp_page_to_pool(p);
> +
> +	hyp_spin_lock(&pool->lock);
> +	__hyp_attach_page(pool, p);
> +	hyp_spin_unlock(&pool->lock);
> +}
> +
> +static struct hyp_page *__hyp_extract_page(struct hyp_pool *pool,
> +					   struct hyp_page *p,
> +					   unsigned int order)
> +{
> +	struct hyp_page *buddy;
> +
> +	list_del_init(&p->node);
> +	while (p->order > order) {
> +		/*
> +		 * The buddy of order n - 1 currently has HYP_NO_ORDER as it
> +		 * is covered by a higher-level page (whose head is @p). Use
> +		 * __find_buddy_nocheck() to find it and inject it in the
> +		 * free_list[n - 1], effectively splitting @p in half.
> +		 */
> +		p->order--;
> +		buddy = __find_buddy_nocheck(pool, p, p->order);
> +		buddy->order = p->order;
> +		list_add_tail(&buddy->node, &pool->free_area[buddy->order]);
> +	}
> +
> +	return p;
> +}
> +
> +void hyp_put_page(void *addr)
> +{
> +	struct hyp_page *p = hyp_virt_to_page(addr);
> +
> +	if (hyp_page_ref_dec_and_test(p))
> +		hyp_attach_page(p);
> +}
> +
> +void hyp_get_page(void *addr)
> +{
> +	struct hyp_page *p = hyp_virt_to_page(addr);
> +
> +	hyp_page_ref_inc(p);
> +}
> +
> +void *hyp_alloc_pages(struct hyp_pool *pool, unsigned int order)
> +{
> +	unsigned int i = order;
> +	struct hyp_page *p;
> +
> +	hyp_spin_lock(&pool->lock);
> +
> +	/* Look for a high-enough-order page */
> +	while (i < pool->max_order && list_empty(&pool->free_area[i]))
> +		i++;
> +	if (i >= pool->max_order) {
> +		hyp_spin_unlock(&pool->lock);
> +		return NULL;
> +	}
> +
> +	/* Extract it from the tree at the right order */
> +	p = list_first_entry(&pool->free_area[i], struct hyp_page, node);
> +	p = __hyp_extract_page(pool, p, order);
> +
> +	hyp_spin_unlock(&pool->lock);
> +	hyp_page_ref_inc(p);

I find this a little scary, as we momentarily drop the lock. It think
it's ok because the reference count on the page must be 0 at this point,
but actually then I think it would be clearer to have a
hyp_page_ref_init() function which could take the lock, check that the
refcount is indeed 0 and then set it to 1.

What do you think?

Will