From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.54758.1673530314271256657 for ; Thu, 12 Jan 2023 05:31:54 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GECaJzsm; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673530313; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uyIwgzMrOktvbZ+D5vCx78eC/ynfwWWpVHc0RSH4ndI=; b=GECaJzsmItSRc+BeCc3ZahJ1sf5dm9l1txEUTTNK6rztasWXFKnlUPLEodQRaTt8Z9loJg JFLUsDuNFtUx0EgzPZVLdpqTOkD+2Q13V6rJ36GTSbeI4eIoWvnNKg0CbVSYmrxrldYGpT T7pdhD3JJW4yhDfBBcq76wJlJ0r7Flc= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-527-9YG4RAQOMMWf8-Fhbivb5A-1; Thu, 12 Jan 2023 08:31:50 -0500 X-MC-Unique: 9YG4RAQOMMWf8-Fhbivb5A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C1C4E1C0515D; Thu, 12 Jan 2023 13:31:49 +0000 (UTC) Received: from [10.39.192.93] (unknown [10.39.192.93]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C2B73C15BAD; Thu, 12 Jan 2023 13:31:46 +0000 (UTC) Message-ID: Date: Thu, 12 Jan 2023 14:31:44 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression To: Ard Biesheuvel , devel@edk2.groups.io, mcb30@ipxe.org Cc: Ard Biesheuvel , Brijesh Singh , Erdem Aktas , Gerd Hoffmann , James Bottomley , Jiewen Yao , Jordan Justen , Min Xu , Oliver Steffen , Sebastien Boeuf , Tom Lendacky , Michael Brown References: <20230112082845.128463-1-lersek@redhat.com> <01020185a568604c-e16d8581-963a-4ff3-8566-bf0640ad327d-000000@eu-west-1.amazonses.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/12/23 11:09, Ard Biesheuvel wrote: > On Thu, 12 Jan 2023 at 10:56, Michael Brown wrote: >> >> On 12/01/2023 08:28, Laszlo Ersek wrote: >>> In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation >>> protocol is (effectively) broken such that it suggests that switching from >>> the legacy interface to the modern interface works, but in reality the >>> switch never happens. The symptom has been witnessed when using TCG >>> acceleration; KVM seems to mask the issue. The issue persists with the >>> following (latest) stable QEMU releases: v5.2.0, v6.2.0, v7.2.0. Currently >>> there is no stable release that addresses the problem. >>> >>> The QEMU bug confuses the Present and Possible counting in function >>> PlatformMaxCpuCountInitialization(), in >>> "OvmfPkg/Library/PlatformInitLib/Platform.c". OVMF ends up with Present=0 >>> Possible=1. This in turn further confuses MpInitLib in UefiCpuPkg (hence >>> firmware-time multiprocessing will be broken). Worse, CPU hot(un)plug with >>> SMI will be summarily broken in OvmfPkg/CpuHotplugSmm, which (considering >>> the privilege level of SMM) is not that great. >>> >>> Detect the issue in PlatformMaxCpuCountInitialization(), and print an >>> error message and *hang* if the issue is present. >> >> Would this mean that OVMF would refuse to start with all current distro >> versions of qemu (when not using KVM), or am I misunderstanding? >> > > I had the same question, actually. This would be less than ideal, > especially given the fact that I didn't even notice the breakage, and > Linux happily booted on all cores. > > If this is a security issue that affects SMM, could we make this > behavior dependent on REQUIRE_SMM perhaps? Yes, we could restrict this with FeaturePcdGet (PcdSmmSmramRequire), but then all multi-processing (the MP PPI from CpuMpPei, and the MP protocol from CpuDxe) remains broken (or at least "misconfigured") in OVMF. That can have OS visible effects; for example, MSR_IA32_FEATURE_CONTROL is supposed to be configured identically on all processors, and PlatformPei uses the MP PPI (from CpuMpPei) to do that; . Is it common that people run bleeding edge OVMF (built from git checkout) on distro QEMU? Edk2's release cycle is much shorter than QEMU's, so I guess we should delay merging this until after QEMU v8 is out, at the least. But, if there won't be another stable release for, say, QEMU v6, is that reason enough to abandon this patch in OVMF? Laszlo