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.133.124]) by mx.groups.io with SMTP id smtpd.web10.47209.1682329548747005401 for ; Mon, 24 Apr 2023 02:45:49 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Inaypkc1; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682329547; 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: in-reply-to:in-reply-to:references:references; bh=jUemocQrCZe2qUnTD8fboJZ2LKD/astQqqANj3+AlSg=; b=Inaypkc1kM1Iti7MVzEkZ3M71O6xuBXkHn2zqj5MtImwwKgE7Nc26YcUadygw0/z1OJ6Ii i5ol0U2+Fsgm/78AXSoqrJjSkg16BhCT7/ir7ogYmaZ6gPb/z2V4KxKhVt7lS/sz2QvLUa z9GiO3wuG3IpT6yHg8Fsi0P51yFVZm8= 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-642-9vOUav4DOnCKrGWH3RlsOg-1; Mon, 24 Apr 2023 05:45:44 -0400 X-MC-Unique: 9vOUav4DOnCKrGWH3RlsOg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D2F023C02585; Mon, 24 Apr 2023 09:45:43 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.246]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 99B5C49AF0; Mon, 24 Apr 2023 09:45:43 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 626F61800632; Mon, 24 Apr 2023 11:45:42 +0200 (CEST) Date: Mon, 24 Apr 2023 11:45:42 +0200 From: "Gerd Hoffmann" To: Tom Lendacky Cc: "Xu, Min M" , joeyli , "devel@edk2.groups.io" , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Michael Roth Subject: Re: [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest Message-ID: References: <2xjjrifeaa7khaha4se7gs3hmtdz2kkg2dv4t7njwf5z5mbn2f@qb5s2k7c6225> <03fed1d7-cbd8-ee45-ebd8-8ecf60971e61@amd.com> <0da93279-d397-c067-cc9f-7abfc9935eea@amd.com> MIME-Version: 1.0 In-Reply-To: <0da93279-d397-c067-cc9f-7abfc9935eea@amd.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 21, 2023 at 03:49:27PM -0500, Tom Lendacky wrote: > On 4/21/23 04:18, Gerd Hoffmann wrote: > > > > Hmm, good question. Can the guest figure what memory ranges are part > > > > of the launch measurement? > > > > > > > > I have a patch here (attached below) which refines flash detection and > > > > can detect whenever varstore flash is writable or not. I suspect that > > > > doesn't help much though as flash probing requires mappings already > > > > being correct. > > > > > > Sorry for the delay, but, yeah, doesn't help. SEV and SEV-ES assert and > > > SEV-SNP terminates because of accessing a shared page (in the RMP) as a > > > private page (we don't support the generated 0x404 error code in the #VC > > > handler). > > > > Can you try this? > > https://github.com/kraxel/edk2/commits/devel/secure-boot-pcd > > It works for the split vars/code launch, but fails for the combined > vars/code launch: > > EMU Variable FVB Started > EMU Variable FVB: Using pre-reserved block at 7FE7C000 > EMU Variable FVB: Basic FV headers were invalid > EMU Variable FVB: SecureBoot: restore FV from ROM > EMU Variable FVB: Basic FV headers were invalid > ASSERT [EmuVariableFvbRuntimeDxe] /root/kernels/ovmf-gerd-build-X64/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c(781): ((BOOLEAN)(0==1)) > > So the mapping isn't correct at this point either. Log looks like this for me, using grep -Ei '(fvb|flash|amdsev)' Loading driver at 0x0003F022000 EntryPoint=0x0003F0245B5 AmdSevDxe.efi Loading driver at 0x0003F6E4000 EntryPoint=0x0003F6E7035 FvbServicesRuntimeDxe.efi QEMU Flash: Attempting flash detection at FFC00010 QemuFlashDetected => FD behaves as ROM QemuFlashDetected => No QEMU flash was not detected. Writable FVB is not being installed. Loading driver at 0x0003F6D3000 EntryPoint=0x0003F6D55B9 EmuVariableFvbRuntimeDxe.efi EMU Variable FVB Started EMU Variable FVB: Using pre-reserved block at 3FEF4000 EMU Variable FVB: Basic FV headers were invalid Installing FVB for EMU Variable support So AmdSevDxe is loaded first, next comes FvbServicesRuntimeDxe, finally EmuVariableFvbRuntimeDxe. So AmdSev should have (in theory, in practice obviously not ...) setup everything at that point I assume? Failing that FvbServicesRuntimeDxe might do it as well, there actually is some code doing so to fixup things after calling SetMemorySpaceAttributes (see MarkIoMemoryRangeForRuntimeAccess). Maybe that should also be called before QemuFlashInitialize() so the SEV settings are correct when OVMF goes do flash detection? take care, Gerd