Re: [EXTERNAL] Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from?

["Laszlo Ersek" <lersek@redhat.com>]

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