From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web10.981.1606332013604108710 for ; Wed, 25 Nov 2020 11:20:13 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=csFZPdCB; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606332012; 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=vGXNKpXK57mtNTC9X+D6bC6sFjVhRXp0uN1TuMrW5Xw=; b=csFZPdCBfuw35V5QrATK5Zg8EzAJpjyhN3Y7NZdKTeGjjxUW/ABt8bnLlJRyn4sPUEEo0I Xk5M9zsnd6Fwi4QqZqREISCaX8CXr8u/b8p0slbL8yU5Jg9jj/8loqPsekfeS3cl81d1Gq pwVf1qDlaw3OU40HdvCONaOZBzqT8J4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-500-BrQAKDqpOR-j20yvm46obw-1; Wed, 25 Nov 2020 14:20:08 -0500 X-MC-Unique: BrQAKDqpOR-j20yvm46obw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 52DB31E7DC; Wed, 25 Nov 2020 19:20:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-239.ams2.redhat.com [10.36.112.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id 267EE5D6AC; Wed, 25 Nov 2020 19:20:02 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 2/6] OvmfPkg/AmdSev: add Grub Firmware Volume Package To: jejb@linux.ibm.com, 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)" 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> <74d01a4212b95e7100b9b959fe1dd3ada0a42a68.camel@linux.ibm.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 25 Nov 2020 20:20:02 +0100 MIME-Version: 1.0 In-Reply-To: <74d01a4212b95e7100b9b959fe1dd3ada0a42a68.camel@linux.ibm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/25/20 19:17, James Bottomley wrote: > 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; > } > ... yes. :) Since you got to writing this up and testing it first, can you please file a new TianoCore BZ about the issue (kernel crash log welcome), and post this patch to edk2-devel stand-alone? One request for the commit message: right after "Fix this by making it AllocateRuntimePool", please add: "For SMM drivers, the platform DSC is responsible for resolving the MemoryAllocationLib class to the SmmMemoryAllocationLib instance. In the SmmMemoryAllocationLib instance, AllocatePool() and AllocateRuntimePool() are implemented identically. Therefore this change is a no-op when the RegisterVariablePolicy() function is built into an SMM driver. The fix affects runtime DXE drivers only." Thanks! Laszlo