From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 02 Oct 2019 08:55:18 -0700 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4E6883F3B; Wed, 2 Oct 2019 15:55:17 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-71.rdu2.redhat.com [10.10.120.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5BBA352FB; Wed, 2 Oct 2019 15:55:15 +0000 (UTC) Subject: Re: [edk2-devel] [RFC PATCH v2 08/44] OvmfPkg: Create GHCB pages for use during Pei and Dxe phase To: "Lendacky, Thomas" , "devel@edk2.groups.io" Cc: Jordan Justen , Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , "Singh, Brijesh" References: <9799d415f652618c8a960cdb0040918185588652.1568922728.git.thomas.lendacky@amd.com> <7aac09f5-8494-3fba-b114-b2b070b6e959@redhat.com> <964e94f7-fbd3-efa4-d309-1ef9e52fcfd0@amd.com> From: "Laszlo Ersek" Message-ID: <53d0996a-9e80-04e0-27cb-d57ab7ee3e29@redhat.com> Date: Wed, 2 Oct 2019 17:55:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <964e94f7-fbd3-efa4-d309-1ef9e52fcfd0@amd.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 02 Oct 2019 15:55:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/02/19 16:43, Lendacky, Thomas wrote: > On 10/2/19 5:23 AM, Laszlo Ersek wrote: >> On 09/19/19 21:52, Lendacky, Thomas wrote: >>> @@ -38,6 +44,34 @@ AmdSevEsInitialize ( >>> >>> PcdStatus = PcdSetBoolS (PcdSevEsActive, 1); >>> ASSERT_RETURN_ERROR (PcdStatus); >>> + >>> + // >>> + // Allocate GHCB pages. >>> + // >>> + GhcbPageCount = mMaxCpuCount; >>> + GhcbBase = AllocatePages (GhcbPageCount); >> >> Yes, AllocatePages() looks safe, per >> . >> >>> + ASSERT (GhcbBase); >> >> (3) I don't really like using *only* an ASSERT for stopping, when we run >> out of resources in a place like this (i.e. where there's no way to >> recover, or to report the issue nicely). I'd suggest throwing in an >> explicit check and a CpuDeadLoop(), in addition to the ASSERT. Anyway, >> not really important, up to you. > > Ok, let me think about that. If ASSERT is enabled, you'll get the ASSERT > message (since the SEC GHCB is in place and OVMF is running in 64-bit > mode). If ASSERT is not enabled, then the ZeroMem will segfault on a NULL > pointer, which will give a bit more info than the CpuDeadLoop() which > would look more like a hang. I don't insist on "strengthening" the ASSERT(). For technical correctness though: accessing page#0 has -- by default -- no ill effects in the firmware. Page#0 is normal RAM, and mapped as such (by default). MdeModulePkg offers null pointer detection; see "PcdNullPointerDetectionPropertyMask". It's a debug feature (not a production feature), to my understanding anyway. It's disabled by default (per DEC file), and OVMF does not enable it. See also commit 90f3922b018e ("OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing", 2017-10-11). Thanks! Laszlo