Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
Subject: Re: [PATCH v5.5 01/30] KVM: Ensure local memslot copies operate on
 up-to-date arch-specific data
To:     Sean Christopherson <seanjc@google.com>
Cc:     James Morse <james.morse@arm.com>,
        Alexandru Elisei <alexandru.elisei@arm.com>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Atish Patra <atish.patra@wdc.com>,
        David Hildenbrand <david@redhat.com>,
        Cornelia Huck <cohuck@redhat.com>,
        Claudio Imbrenda <imbrenda@linux.ibm.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu,
        linux-mips@vger.kernel.org, kvm@vger.kernel.org,
        kvm-ppc@vger.kernel.org, kvm-riscv@lists.infradead.org,
        linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
        Ben Gardon <bgardon@google.com>, Marc Zyngier <maz@kernel.org>,
        Huacai Chen <chenhuacai@kernel.org>,
        Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
        Paul Mackerras <paulus@ozlabs.org>,
        Anup Patel <anup.patel@wdc.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Christian Borntraeger <borntraeger@de.ibm.com>,
        Janosch Frank <frankja@linux.ibm.com>,
        Paolo Bonzini <pbonzini@redhat.com>
References: <20211104002531.1176691-1-seanjc@google.com>
 <20211104002531.1176691-2-seanjc@google.com>
Message-ID: <6407c2d3-854b-edf6-9990-b54a5baedd0a@oracle.com>
Date:   Tue, 9 Nov 2021 01:37:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
In-Reply-To: <20211104002531.1176691-2-seanjc@google.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZlptTTZ2Umpld0lLNW5xdkJRSEdack54THZuZllkOWhUN3YwTlJBVVVheTNv?=
 =?utf-8?B?SW5BRUt1dUdOS3J3N2pWV2lFaktlSFhsT0M0V3U0bFNkY3NqdXZyNHdzT0pD?=
 =?utf-8?B?K3I3STU5ZURFSno0ZUdVT0hBS0owQ3g5b3pYV0htcUVRS3NFTUZ0TjIrSkgv?=
 =?utf-8?B?S3lkc25iZFVOaXhPYWpLeGhkTEJSbU40RzU2V0tXY05scVhxc3R0LzNvMEZW?=
 =?utf-8?B?NlYvci95NWozWkdRbitHcDZqbEwzZ2EyTGZuenlKem9Vc3RrU0U2QlVTVW1E?=
 =?utf-8?B?SFoyaHhIZnJ4V25LV3o4Tm9KclFpYkdrdEJtNFJoc0lZaXgycHJRVGcrTXVF?=
 =?utf-8?B?djRGRnpvbHZVL29ab3FmS2pkd0NpMGRiWUtPMElpcmdqTXlGSC9qQ080U2kr?=
 =?utf-8?B?TUZWSEhNY3paTVFBa0JqRFpwRXR1c2doT05BN1hERXYySEExOWdBQ1VReVRs?=
 =?utf-8?B?Skd0WlBWMDNteUt4UkNnMEpLQ1dUR3dPYlJTT3pBZVFEZXpDRXVhRTI2VjA5?=
 =?utf-8?B?MmwyS3BXN3hHb2ZjSDhEM0RMak9ndjZYMUwyYlNHNG11Nm5Oci9seTZFNW8y?=
 =?utf-8?B?TEtxMXVIbWtHVmFaTlZvZkMzbFgycDAwSmpsVmZNamdUOWErTzdRSisxb0NH?=
 =?utf-8?B?ZUx5eUtabUc5bjNOT0pFbUFFZCs2OGt1bFRZMXhoR0lHSXVuQUVHSkppeDUr?=
 =?utf-8?B?bzhhWEhSaStaNUVVZ1pGRFdabmhOaGFuZktWZDU5MDJsc2V2YWsvd08yRzla?=
 =?utf-8?B?NU1NZ0lJUWZjd1B4a0dSQ0haNzlsRVZZTzNKaDU0YURUTXc0MG8xclpiNGZM?=
 =?utf-8?B?RmhPdDFPaTFBZ3cxaytZSU9BMm41ZmxUTGVhaXQ4LzFFRUlEUUxKb3hHWGxK?=
 =?utf-8?B?WmI1WDFScVE0MG1Hd0x1cmpQNEkrY2FheWsrYzZUU3ZuS0U5NHpsSWVZMXlV?=
 =?utf-8?B?N0FwMmZpYWVQSFBmMXlPUzV6eW05WTBvZCtJcyttcFQyRU9rRHdna1Vkdm43?=
 =?utf-8?B?Nk9EdEVGbG80Q2kyZm1GdTRrNHNJLzVoQkxreWFaZXZXYXFQVjNTeTlhaXVa?=
 =?utf-8?B?RWRNZk1IK1J0Y05sanlzQWFpUDQyR1dqQmVQL2JMek5VaDVPSG1OdHBORlJG?=
 =?utf-8?B?VTJmblFwaUFySzRHeXJDL0pBZlk0S09FL2RSeWRzNGtJK2EzVUNwVXRqN0RX?=
 =?utf-8?B?RFZid2dkTVNzcWZIWmRZSzczdlZYYytKQ3ZxOWtDa3lHQlVmc3J5Z3h3d0Rk?=
 =?utf-8?B?MDlYNFdtVEhtRW1LNlpLc3I0YkNpU1RNSTRCUzBzVWt0dTZHTlJ5cVhYNG1X?=
 =?utf-8?B?S3JOWGNhdUZ5NnkzZmFDTTlOODM2OGtJSzQ4bnhlRFF1RVN5djhOTzByQ25C?=
 =?utf-8?B?dlUvbGZkSnpuYkpIWnY1K0pNLzBLeG1sRGdEc0lyYUF0V3k5eXJ0VTNKbjVK?=
 =?utf-8?B?bjVrWWxpSG1oejg3MnpvRlNpV0t0WDV6ekZLcHBvTjhYQVhuYTBRQXo1bHdU?=
 =?utf-8?B?dXM4MjhGR2M2TnNSQnBCeCtIQ0hSNEZlV0FiTjM1cjlEbGUyWDBFRi9RU2JO?=
 =?utf-8?B?L0tGbGt1Y1Fia3ZuaUlFRWZSdjYzb3MyUnhXQ3F2bWM5Z01WazJFMkFTOXMv?=
 =?utf-8?B?RVNhS2R4bytFZkljV0kvWjdSV1BFN2JXRmlXb0ZzMGo3Z0cyZ3V6NHZBRVR2?=
 =?utf-8?B?WFZYbmxrRE0xSGVxL0J2SDBWSTE4NC9TOFJvcWlaMlI5L21ZaVYwVWRHMnhs?=
 =?utf-8?B?UWtYazJJZmgyUDRDRzVzNzkxT2pxUGg3WmVJQUs5NXlxSEc4bDVGVjF0T1VP?=
 =?utf-8?B?NTMzVVEvdDNkVDB1bkR0eUJYaERvWUdBTUU2Yk5XdFZUTkNBMDQxMjIrUnJ5?=
 =?utf-8?B?a0hJQUVsVnh4d1ZwY0h4WHJaVWhUTWg2UlNWUnJQRkhoTkpiNjhRUk5KOVFL?=
 =?utf-8?B?REFFOGpEMWlWNUFhOWFrdzFQa1hvMmI1WXpXUTVqMndMdEFUajBCOUxOaDRm?=
 =?utf-8?B?SHlGTkp0bFpaTkNTMmExYkl5Sk9xSVJibmFCOXlXVkhOUkc5NnNvak1iNURB?=
 =?utf-8?B?cXRsdzV0NHBMZ1VmTVJvcUNpb2hVYUk1d0NPL1FCU3Z3SE1ocmZ5QjJsUldQ?=
 =?utf-8?B?MVJHa3FTR2dJa1UxeW81cWFHZG41VkFvVkNUV0dNZEo2ajhvdnV3QVhmYTRW?=
 =?utf-8?B?c3RqNy9PY3dIanBXTzM5UEZjM3ZESEFzMVZnZzh2NHQwYmdtczhYcHBRUGJz?=
 =?utf-8?B?aTFVNWQzc21NSldjK0hDVS9KL2FBPT0=?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a67fd2f-1042-4ab2-a50a-08d9a3192c6a
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4008.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2021 00:37:56.6121
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: T8Sgq2D4wB4OLEiSjxHj3cGYAOaePMQA4hTgkaaKU49jgDrYhsbE9h2ptg/XaHlNVSXigd1hsvvVp5EnQYceKIGJuyYZnZ7No0U2JigijJ8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB4972
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10162 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0
 suspectscore=0 bulkscore=0 spamscore=0 phishscore=0 malwarescore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2110150000 definitions=main-2111090001
X-Proofpoint-ORIG-GUID: Xz8M8vPiB_eV3KtkHDt6Yc-FAqcv5_mA
X-Proofpoint-GUID: Xz8M8vPiB_eV3KtkHDt6Yc-FAqcv5_mA
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 04.11.2021 01:25, Sean Christopherson wrote:
> When modifying memslots, snapshot the "old" memslot and copy it to the
> "new" memslot's arch data after (re)acquiring slots_arch_lock.  x86 can
> change a memslot's arch data while memslot updates are in-progress so
> long as it holds slots_arch_lock, thus snapshotting a memslot without
> holding the lock can result in the consumption of stale data.
> 
> Fixes: b10a038e84d1 ("KVM: mmu: Add slots_arch_lock for memslot arch fields")
> Cc: stable@vger.kernel.org
> Cc: Ben Gardon <bgardon@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>   virt/kvm/kvm_main.c | 47 ++++++++++++++++++++++++++++++---------------
>   1 file changed, 31 insertions(+), 16 deletions(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 3f6d450355f0..99e69375c4c9 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1531,11 +1531,10 @@ static struct kvm_memslots *kvm_dup_memslots(struct kvm_memslots *old,
>   
>   static int kvm_set_memslot(struct kvm *kvm,
>   			   const struct kvm_userspace_memory_region *mem,
> -			   struct kvm_memory_slot *old,
>   			   struct kvm_memory_slot *new, int as_id,
>   			   enum kvm_mr_change change)
>   {
> -	struct kvm_memory_slot *slot;
> +	struct kvm_memory_slot *slot, old;
>   	struct kvm_memslots *slots;
>   	int r;
>   
> @@ -1566,7 +1565,7 @@ static int kvm_set_memslot(struct kvm *kvm,
>   		 * Note, the INVALID flag needs to be in the appropriate entry
>   		 * in the freshly allocated memslots, not in @old or @new.
>   		 */
> -		slot = id_to_memslot(slots, old->id);
> +		slot = id_to_memslot(slots, new->id);
>   		slot->flags |= KVM_MEMSLOT_INVALID;
>   
>   		/*
> @@ -1597,6 +1596,26 @@ static int kvm_set_memslot(struct kvm *kvm,
>   		kvm_copy_memslots(slots, __kvm_memslots(kvm, as_id));
>   	}
>   
> +	/*
> +	 * Make a full copy of the old memslot, the pointer will become stale
> +	 * when the memslots are re-sorted by update_memslots(), and the old
> +	 * memslot needs to be referenced after calling update_memslots(), e.g.
> +	 * to free its resources and for arch specific behavior.  This needs to
> +	 * happen *after* (re)acquiring slots_arch_lock.
> +	 */
> +	slot = id_to_memslot(slots, new->id);
> +	if (slot) {
> +		old = *slot;
> +	} else {
> +		WARN_ON_ONCE(change != KVM_MR_CREATE);
> +		memset(&old, 0, sizeof(old));
> +		old.id = new->id;
> +		old.as_id = as_id;
> +	}
> +
> +	/* Copy the arch-specific data, again after (re)acquiring slots_arch_lock. */
> +	memcpy(&new->arch, &old.arch, sizeof(old.arch));

Had "new" been zero-initialized completely in __kvm_set_memory_region()
for safety (so it does not contain stack garbage - I don't mean just the
new.arch field in the "if (!old.npages)" branch in that function but the
whole struct) this line would be needed only in the "if (slot)" branch
above (as Ben said).

Also, when patch 7 from this series removes this memcpy(),
kvm_arch_prepare_memory_region() does indeed receive this field
uninitialized - I know only x86 and ppcHV care
and kvm_alloc_memslot_metadata() or kvmppc_core_prepare_memory_region_hv()
then overwrites it unconditionally but it feels a bit wrong.

I am almost certain that compiler would figure out to only actually
zero the fields that wouldn't be overwritten immediately anyway.

But on the other hand, this patch is only a fix for code that's going
to be replaced anyway so perfection here probably isn't that important.

Thanks,
Maciej