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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0903abca-42f5-4ca7-8c81-070e7669f996@redhat.com>
Date: Fri, 22 Nov 2024 12:03:14 +0100
From: David Hildenbrand <david@...hat.com>
To: michael.day@....com, Elliot Berman <quic_eberman@...cinc.com>,
 Paolo Bonzini <pbonzini@...hat.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Sean Christopherson <seanjc@...gle.com>, Fuad Tabba <tabba@...gle.com>,
 Ackerley Tng <ackerleytng@...gle.com>, Mike Rapoport <rppt@...nel.org>,
 "H. Peter Anvin" <hpa@...or.com>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 Jonathan Corbet <corbet@....net>, Trond Myklebust <trondmy@...nel.org>,
 Anna Schumaker <anna@...nel.org>, Mike Marshall <hubcap@...ibond.com>,
 Martin Brandenburg <martin@...ibond.com>,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>
Cc: James Gowans <jgowans@...zon.com>, linux-fsdevel@...r.kernel.org,
 kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, linux-doc@...r.kernel.org, linux-nfs@...r.kernel.org,
 devel@...ts.orangefs.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 2/2] mm: guestmem: Convert address_space operations to
 guestmem library

On 21.11.24 18:40, Mike Day wrote:
> 
> 
> On 11/21/24 10:43, Elliot Berman wrote:
>> On Wed, Nov 20, 2024 at 10:12:08AM -0800, Elliot Berman wrote:
>>> diff --git a/mm/guestmem.c b/mm/guestmem.c
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..19dd7e5d498f07577ec5cec5b52055f7435980f4
>>> --- /dev/null
>>> +++ b/mm/guestmem.c
>>> @@ -0,0 +1,196 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * guestmem library
>>> + *
>>> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>>> + */
>>> +
>>> +#include <linux/fs.h>
>>> +#include <linux/guestmem.h>
>>> +#include <linux/mm.h>
>>> +#include <linux/pagemap.h>
>>> +
>>> +struct guestmem {
>>> +	const struct guestmem_ops *ops;
>>> +};
>>> +
>>> +static inline struct guestmem *folio_to_guestmem(struct folio *folio)
>>> +{
>>> +	struct address_space *mapping = folio->mapping;
>>> +
>>> +	return mapping->i_private_data;
>>> +}
>>> +
>>> +static inline bool __guestmem_release_folio(struct address_space *mapping,
>>> +					    struct folio *folio)
>>> +{
>>> +	struct guestmem *gmem = mapping->i_private_data;
>>> +	struct list_head *entry;
>>> +
>>> +	if (gmem->ops->release_folio) {
>>> +		list_for_each(entry, &mapping->i_private_list) {
>>> +			if (!gmem->ops->release_folio(entry, folio))
>>> +				return false;
>>> +		}
>>> +	}
>>> +
>>> +	return true;
>>> +}
>>> +
>>> +static inline int
>>> +__guestmem_invalidate_begin(struct address_space *const mapping, pgoff_t start,
>>> +			    pgoff_t end)
>>> +{
>>> +	struct guestmem *gmem = mapping->i_private_data;
>>> +	struct list_head *entry;
>>> +	int ret = 0;
>>> +
>>> +	list_for_each(entry, &mapping->i_private_list) {
>>> +		ret = gmem->ops->invalidate_begin(entry, start, end);
>>> +		if (ret)
>>> +			return ret;
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static inline void
>>> +__guestmem_invalidate_end(struct address_space *const mapping, pgoff_t start,
>>> +			  pgoff_t end)
>>> +{
>>> +	struct guestmem *gmem = mapping->i_private_data;
>>> +	struct list_head *entry;
>>> +
>>> +	if (gmem->ops->invalidate_end) {
>>> +		list_for_each(entry, &mapping->i_private_list)
>>> +			gmem->ops->invalidate_end(entry, start, end);
>>> +	}
>>> +}
>>> +
>>> +static void guestmem_free_folio(struct address_space *mapping,
>>> +				struct folio *folio)
>>> +{
>>> +	WARN_ON_ONCE(!__guestmem_release_folio(mapping, folio));
>>> +}
>>> +
>>> +static int guestmem_error_folio(struct address_space *mapping,
>>> +				struct folio *folio)
>>> +{
>>> +	pgoff_t start, end;
>>> +	int ret;
>>> +
>>> +	filemap_invalidate_lock_shared(mapping);
>>> +
>>> +	start = folio->index;
>>> +	end = start + folio_nr_pages(folio);
>>> +
>>> +	ret = __guestmem_invalidate_begin(mapping, start, end);
>>> +	if (ret)
>>> +		goto out;
>>> +
>>> +	/*
>>> +	 * Do not truncate the range, what action is taken in response to the
>>> +	 * error is userspace's decision (assuming the architecture supports
>>> +	 * gracefully handling memory errors).  If/when the guest attempts to
>>> +	 * access a poisoned page, kvm_gmem_get_pfn() will return -EHWPOISON,
>>> +	 * at which point KVM can either terminate the VM or propagate the
>>> +	 * error to userspace.
>>> +	 */
>>> +
>>> +	__guestmem_invalidate_end(mapping, start, end);
>>> +
>>> +out:
>>> +	filemap_invalidate_unlock_shared(mapping);
>>> +	return ret ? MF_DELAYED : MF_FAILED;
>>> +}
>>> +
>>> +static int guestmem_migrate_folio(struct address_space *mapping,
>>> +				  struct folio *dst, struct folio *src,
>>> +				  enum migrate_mode mode)
>>> +{
>>> +	WARN_ON_ONCE(1);
>>> +	return -EINVAL;
>>> +}
>>> +
>>> +static const struct address_space_operations guestmem_aops = {
>>> +	.dirty_folio = noop_dirty_folio,
>>> +	.free_folio = guestmem_free_folio,
>>> +	.error_remove_folio = guestmem_error_folio,
>>> +	.migrate_folio = guestmem_migrate_folio,
>>> +};
>>> +
>>> +int guestmem_attach_mapping(struct address_space *mapping,
>>> +			    const struct guestmem_ops *const ops,
>>> +			    struct list_head *data)
>>> +{
>>> +	struct guestmem *gmem;
>>> +
>>> +	if (mapping->a_ops == &guestmem_aops) {
>>> +		gmem = mapping->i_private_data;
>>> +		if (gmem->ops != ops)
>>> +			return -EINVAL;
>>> +
>>> +		goto add;
>>> +	}
>>> +
>>> +	gmem = kzalloc(sizeof(*gmem), GFP_KERNEL);
>>> +	if (!gmem)
>>> +		return -ENOMEM;
>>> +
>>> +	gmem->ops = ops;
>>> +
>>> +	mapping->a_ops = &guestmem_aops;
>>> +	mapping->i_private_data = gmem;
>>> +
>>> +	mapping_set_gfp_mask(mapping, GFP_HIGHUSER);
>>> +	mapping_set_inaccessible(mapping);
>>> +	/* Unmovable mappings are supposed to be marked unevictable as well. */
>>> +	WARN_ON_ONCE(!mapping_unevictable(mapping));
>>> +
>>> +add:
>>> +	list_add(data, &mapping->i_private_list);
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(guestmem_attach_mapping);
>>> +
>>> +void guestmem_detach_mapping(struct address_space *mapping,
>>> +			     struct list_head *data)
>>> +{
>>> +	list_del(data);
>>> +
>>> +	if (list_empty(&mapping->i_private_list)) {
>>> +		kfree(mapping->i_private_data);
>>
>> Mike was helping me test this out for SEV-SNP. They helped find a bug
>> here. Right now, when the file closes, KVM calls
>> guestmem_detach_mapping() which will uninstall the ops. When that
>> happens, it's not necessary that all of the folios aren't removed from
>> the filemap yet

Yes, that's the real issue. There either must be some lifetime tracking 
(kfree() after the mapping is completely unused), or you have to tear it 
all down before you mess with the mapping.

>>
>> There are a few approaches I could take:
>>
>> 1. Create a guestmem superblock so I can register guestmem-specific
>>      destroy_inode() to do the kfree() above. This requires a lot of
>>      boilerplate code, and I think it's not preferred approach.
>> 2. Update how KVM tracks the memory so it is back in "shared" state when
>>      the file closes. This requires some significant rework about the page
>>      state compared to current guest_memfd. That rework might be useful
>>      for the shared/private state machine.
>> 3. Call truncate_inode_pages(mapping, 0) to force pages to be freed
>>      here. It's might be possible that a page is allocated after this
>>      point. In order for that to be a problem, KVM would need to update
>>      RMP entry as guest-owned, and I don't believe that's possible after
>>      the last guestmem_detach_mapping().
>>
>> My preference is to go with #3 as it was the most easy thing to do.
> 
> #3 is my preference as well. The semantics are that the guest is "closing" the gmem
> object, which means all the memory is being released from the guest.

Agreed.

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ