linux-kernel - Re: [RFC PATCH 9/9] kvm_main.c: handle atomic memslot update

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: <7e64d472-fbce-6640-033a-51b8906b7924@intel.com>
Date:   Tue, 13 Sep 2022 10:30:43 +0800
From:   "Yang, Weijiang" <weijiang.yang@...el.com>
To:     Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        <kvm@...r.kernel.org>
CC:     Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Hildenbrand <david@...hat.com>,
        "Maxim Levitsky" <mlevitsk@...hat.com>, <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 9/9] kvm_main.c: handle atomic memslot update


On 9/9/2022 6:45 PM, Emanuele Giuseppe Esposito wrote:
> When kvm_vm_ioctl_set_memory_region_list() is invoked, we need
> to make sure that all memslots are updated in the inactive list
> and then swap (preferreably only once) the lists, so that all
> changes are visible immediately.
[...]
> +static int kvm_vm_ioctl_set_memory_region_list(struct kvm *kvm,
> +		       struct kvm_userspace_memory_region_list *list,
> +		       struct kvm_userspace_memory_region_entry __user *mem_arg)
> +{
> +	struct kvm_userspace_memory_region_entry *mem, *m_iter;
> +	struct kvm_userspace_memory_region *mem_region;
> +	struct kvm_internal_memory_region_list *batch, *b_iter;
> +	int i, r = 0;
> +	bool *as_to_swap;
> +
> +	/* TODO: limit the number of mem to a max? */
> +
> +	if (!list->nent)
> +		return r;
> +
> +	mem = vmemdup_user(mem_arg, array_size(sizeof(*mem), list->nent));
> +	if (IS_ERR(mem)) {
> +		r = PTR_ERR(mem);
> +		goto out;
> +	}

IMO, it's more natural to dup the user memory at the first place, i.e., 
kvm_vm_ioctl,

it also makes the outlets shorter.


[...]