From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web11.8132.1588935946352379700 for ; Fri, 08 May 2020 04:05:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LnqKqq5C; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588935945; 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=HnWTXwOR5j/BRMeTkOxZBXryX4tMn50WhKSB8nCd6ik=; b=LnqKqq5CwN5BhYtTBSXeY10sXeiN/laTNmtFFQ7VnzbV7ikxuqPpnicjNlCgtiFVhYcx19 1SI2tcWm1WVJ7qadUSIJv1/5Udhl9E3nqgYm84OyGZ+DKhXo7SZZt5WlMJu3iEMxbCOynC qjCpBuTLVg1JSkxwK26D11nJsk7RlWM= 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-328-8syJVLIMOIqSYVnSp6LXVQ-1; Fri, 08 May 2020 07:05:38 -0400 X-MC-Unique: 8syJVLIMOIqSYVnSp6LXVQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 61086BFC2; Fri, 8 May 2020 11:05:36 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-60.ams2.redhat.com [10.36.114.60]) by smtp.corp.redhat.com (Postfix) with ESMTP id 346F610013BD; Fri, 8 May 2020 11:05:33 +0000 (UTC) Subject: Re: [EXTERNAL] Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from? To: Bret Barkelew , "devel@edk2.groups.io" , "afish@apple.com" , Ard Biesheuvel Cc: Daniel Schaefer , "Chang, Abner (HPS SW/FW Technologist)" , Atish Patra , Heinrich Schuchardt , Atish Patra , Alexander Graf , Anup Patel , "leif@nuviainc.com" , Jordan Justen References: <20200224221949.28826-1-atish.patra@wdc.com> <4de513ea-26fb-c830-2348-c0f57946fd3d@hpe.com> <3cb1d47e-983f-dd93-33d2-5a7896791dde@arm.com> <9B467C1E-7EAC-49D9-B646-D91E60FD7539@apple.com> From: "Laszlo Ersek" Message-ID: <6672e3c2-b1be-4c97-6d24-9ddf44991fc3@redhat.com> Date: Fri, 8 May 2020 13:05:32 +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: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/07/20 18:45, Bret Barkelew wrote: > I know I've also seen tests that randomize the driver dispatch order > to try to catch these "implementation-specific" edge cases. Perhaps we > could instrument something similar with a weekly OVMF CI test? That won't work for -- at least -- the SMM_REQUIRE build of OVMF. Consider the following FDF snippet: > !if $(SMM_REQUIRE) == TRUE > [...] > INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf > > # > # Variable driver stack (SMM) > # > INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf > INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf > INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf > INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf > > !else The pflash detection in FvbServicesSmm can only function if FvbServicesSmm is dispatched after PiSmmCpuDxeSmm. QEMU restricts pflash write accesses to such guest code that runs in SMM. And if FvbServicesSmm is dispatched before PiSmmCpuDxeSmm, then FvbServicesSmm does not run in SMM, and the pflash detection fails. ( Note: the question is not whether FvbServicesSmm runs *from SMRAM* (that's a given), but whether it runs *in SMM*. Regardless of the dispatch order, SMRAM is open (not closed) at this point, so FvbServicesSmm *can* run from SMRAM without the VCPU being in SMM. But in that case, QEMU denies pflash writes, and so the pflash detection fails. ) In 2016, there was an attempt to add a new dependency to PiSmmCpuDxeSmm, which ended up reversing the desired dispatch order between PiSmmCpuDxeSmm and FvbServicesSmm. That triggered the above problem, and we discussed it back then. At the time, I did try enforcing the right dispatch order with adding a DEPEX to FvbServicesSmm. But then the rest of the variable stack (which builds upon the SMM FVB protocol produced by FvbServicesSmm) fell apart. See my 2016 writeup here: http://mid.mail-archive.com/cc211d5f-18f3-57c8-7b4f-d4f3433898f7@redhat.com ( Alternative link: https://lists.01.org/hyperkitty/list/edk2-devel@lists.01.org/message/WE3NGL24WTEB6E56MOJMVFBOIKPLKC3Q/ ) The PiSmmCpuDxeSmm DEPEX that upset the dispatch order for OVMF got ultimately reverted in commit eadf70bdfbc1 ("UefiCpuPkg/PiSmmCpuDxeSmm: Revert 7503cd70fb86", 2016-08-19). (My understanding is that the same DEPEX ended up being injected into PiSmmCpuDxeSmm in a particular platform tree (not in edk2), via that platform's SmmCpuFeaturesLib instance -- PiSmmCpuDxeSmm consumes SmmCpuFeaturesLib.) Part of the complication is *likely* that VariableSmm only has TRUE for Depex: - VariableSmm consumes the SMM FTW protocol produced by FaultTolerantWriteSmm, but that protocol is not in the DEPEX, it's awaited with an SMM protocol notify. - VariableSmm also consumes the SMM FVB protocol produced by FvbServicesSmm, but that protocol is not waited-for in *any* way (neither DEPEX nor notify). Only attempts are made to locate it. I *guess* (but haven't tracked down) that the SMM FVB availability is inferred from the SMM FTW availability (FaultTolerantWriteSmm does have an explicit DEPEX on SMM FVB). The (working) dispatch order seen in the OVMF log file is: > Loading SMM driver at 0x0007D094000 EntryPoint=0x0007D09D0B3 PiSmmCpuDxeSmm.efi > Loading SMM driver at 0x0007D042000 EntryPoint=0x0007D047677 FvbServicesSmm.efi > Loading SMM driver at 0x0007CF68000 EntryPoint=0x0007CFF882E VariableSmm.efi > Loading SMM driver at 0x0007CE05000 EntryPoint=0x0007CE0923C SmmFaultTolerantWriteDxe.efi > Loading driver at 0x0007BAA0000 EntryPoint=0x0007BAA47E2 VariableSmmRuntimeDxe.efi Note a few things: - FaultTolerantWriteSmm calls itself "SmmFaultTolerantWriteDxe" via its BASE_NAME (functionally harmless, but confusing). - The dispatch order between PiSmmCpuDxeSmm and FvbServicesSmm is as desired. - VariableSmm and FaultTolerantWriteSmm are *already* dispatched in reverse order relative to the FDF file. This -- while not wrong -- does not seem necessary for satisfying any DEPEX, as far as I can see. This is one of those "dark corners". Thanks Laszlo