From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web10.29.1606328301615497485 for ; Wed, 25 Nov 2020 10:18:22 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=mrzFEyjp; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0API4ARK114533; Wed, 25 Nov 2020 13:17:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : reply-to : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=ofmEzET3RaGFH9muv6La4JWsp862HY9AjRz9Ucb/VtM=; b=mrzFEyjpn4iPZXdKTcn3z65xD4xZoCJ5kfOicaz/LqCtekaiTumdoyVbmKimpF6qO1rQ DAIfVQ9YKu6/+QXHPDLwVSi5PtzYSSzFl4FUY0GtW2Xnm35n9GbykUeKZc9VNoxfpdRL Z002+JQ9azylIpehLEtBEPFfOksgZK1daHKeujZfLLIhtYR7voi3pDAI7om9qkorkCxt fSSgE9sMYufKXbd4x64rpQmPdT0TnaOx8T4YoRHqGP8EhM6T0ItXrzXdTPOIFIH91wXq 24fg5HHTOeH0K3Rj0akn14hLnBZWbN0IVxW9cKkjTE7jsPYQHig2ih2OGsxkBUZe6GT5 MQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 351pmx4nx8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Nov 2020 13:17:58 -0500 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0API6sDR129628; Wed, 25 Nov 2020 13:17:58 -0500 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com with ESMTP id 351pmx4nwu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Nov 2020 13:17:58 -0500 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0APICfJ2002815; Wed, 25 Nov 2020 18:17:57 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma04wdc.us.ibm.com with ESMTP id 34xth99dmc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Nov 2020 18:17:57 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0APIHjNe61931784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Nov 2020 18:17:45 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3D33C7805C; Wed, 25 Nov 2020 18:17:54 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A06BE78060; Wed, 25 Nov 2020 18:17:51 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.194.234]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 25 Nov 2020 18:17:51 +0000 (GMT) Message-ID: <74d01a4212b95e7100b9b959fe1dd3ada0a42a68.camel@linux.ibm.com> Subject: Re: [edk2-devel] [PATCH v2 2/6] OvmfPkg/AmdSev: add Grub Firmware Volume Package From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Laszlo Ersek , devel@edk2.groups.io, Bret Barkelew , "Liming Gao (Byosoft address)" Cc: dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com, ashish.kalra@amd.com, brijesh.singh@amd.com, tobin@ibm.com, david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com, frankeh@us.ibm.com, "Dr . David Alan Gilbert" , "Ard Biesheuvel (ARM address)" Date: Wed, 25 Nov 2020 10:17:50 -0800 In-Reply-To: <1064db1d53315987bf8bb478894a07bda8d90a96.camel@linux.ibm.com> References: <20201120184521.19437-1-jejb@linux.ibm.com> <20201120184521.19437-3-jejb@linux.ibm.com> <28e99174-79b3-e805-b977-5fed0071a702@redhat.com> <06b9425507ab8c1b35d377cf9bba155b0cc44147.camel@linux.ibm.com> <3b7899fa-fa52-7652-2d2a-d4ec67ece34d@redhat.com> <1c871b56-f459-5ac4-3b8d-a55d978eac06@redhat.com> <93fdaca88b53d400670b338a06fd1410c1445a39.camel@linux.ibm.com> <082a97c2-9a49-acf6-fd7c-70ee6b61c000@redhat.com> <5b9b21c3eb37ba7024c1cb85ead267867b323c7d.camel@linux.ibm.com> <1064db1d53315987bf8bb478894a07bda8d90a96.camel@linux.ibm.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737 definitions=2020-11-25_10:2020-11-25,2020-11-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 bulkscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011250110 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2020-11-25 at 09:09 -0800, James Bottomley wrote: > On Wed, 2020-11-25 at 08:02 -0800, James Bottomley wrote: > > On Wed, 2020-11-25 at 15:01 +0100, Laszlo Ersek wrote: > > > This upgrade gave me kernel 5.8.18-100.fc31.x86_64 in the guest > > > -- > > > and this one does *not* crash. From your boot log below, I see > > > your guest kernel is 5.5.0; I suggest upgrading it. > > > > Heh, that's easier said than done ... I always make my encrypted > > images too small to upgrade a kernel easily. Anyway, after doing > > the remove and add stuff dance, I finally got it upgraded to the > > latest debian testing linux-image-5.8.0-3 it's still crashing > > although with a slightly different traceback. It looks like there > > might be something additional in the fedora 5.8 kernel that fixes > > this. I'm going to try out upstream kernels next. > > I've got the upstream kernel booting through OVMF with a qemu -kernel > command line. I also have a fix: it's not to delete the dummy > variable which was part of the ancient x86 anti bricking code (which > is also why arm64 doesn't have the problem). OK, found the problem: the memory the variable policy itself is stored in doesn't survive into the linux runtime. It looks to be pretty generic except you need a way of detecting the boot time memory is free. Because Linux does a remapping, we see this. I'm not sure how you'd construct a regression test for something like this, though. I propose this as the fix ... at least it gets my SEV kernels booting again. James ---8>8>8><8<8<8---- >>From b33aa8bd8ded4c7cfec67c2d5aa5e23271c75f51 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Wed, 25 Nov 2020 10:10:30 -0800 Subject: [PATCH 1/1] VariablePolicyLib: Fix Runtime panic in ValidateSetVariable The current variable policy is allocated by AllocatePool, which is boot time only. This means that if you do any variable setting in the runtime, the policy has been freed. Ordinarily this isn't detected because freed memory is still there, but when you boot the Linux kernel, it's been remapped so the actual memory no longer exists in the memory map causing a page fault. Fix this by making it AllocateRuntimePool. Signed-off-by: James Bottomley --- MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c b/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c index 5029ddb96adb..12944ac7ea81 100644 --- a/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c +++ b/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.c @@ -411,7 +411,7 @@ RegisterVariablePolicy ( } // Reallocate and copy the table. - NewTable = AllocatePool( NewSize ); + NewTable = AllocateRuntimePool( NewSize ); if (NewTable == NULL) { return EFI_OUT_OF_RESOURCES; } -- 2.26.2