static data in dxe_runtime modules

["Roman Kagan" <rkagan@virtuozzo.com>]

I'm trying to come up with a solution to the problem that OpenSSL
internally uses static variables ("per-thread" in no-threads config) to
store pointers, which remain unadjusted upon SetVirtualAddressMap and
cause the guest OS crash.

More specifically, trying to set a signed variable leads to the
following call chain:

VariableServiceSetVariable
  ProcessVarWithPk
    VerifyTimeBasedPayloadAndUpdate
      Pkcs7GetSigners
	ASN1_item_d2i
	  asn1_item_embed_d2i
	    asn1_template_ex_d2i
	      asn1_template_noexp_d2i
		asn1_item_embed_d2i
		  asn1_template_ex_d2i
		    asn1_template_noexp_d2i
		      asn1_item_embed_d2i
			asn1_template_ex_d2i
			  asn1_template_noexp_d2i
			    asn1_item_embed_d2i
			      pubkey_cb
				ERR_set_mark
				  ERR_get_state

The latter performs one-time initialization if needed, and then returns
a pointer maintained in a static array using CRYPTO_THREAD_get_local().
If a signed variable is set before SetVirtualAddressMap and (another
one) after it, the pointer is initialized while in the old mapping and
dereferenced while in the new one, crashing the OS.

The real-world reproducer: install Windows Server 2016 in a VM with
OVMF, shut it down, replace the varstore with a fresh template copy,
boot Windows, try to update, say, "dbx" from within Windows => BSOD.
The reason is that the Windows bootloader stores a secure variable
"CurrentPolicy" if it isn't there, triggering the above callchain while
still in identity mapping.
(This problem isn't widely noticed because during the installation the
bootloader stores CurrentPolicy, but the OS is soon rebooted, before it
attempts to update dbx; upon that CurrentPolicy remains in the varstore
and on further boots the bootloader skips setting it.)

What would be the best way to fix it?

One option is to audit OpenSSL and make sure it either doesn't put
pointers into static storage or properly cleans them up (and call the
cleanup function in RuntimeCryptLibAddressChangeEvent); then assume the
rest of EDKII code is safe in this regard.

Another is to assume that no static data in dxe_runtime modules should
survive SetVirtualAddressMap, and thus make
PeCoffLoaderRelocateImageForRuntime reinitialize the modules from
scratch instead of re-applying the relocations only.

I must admit I don't yet quite understand the full consequences of
either option.  Perhaps there are better ones.
Any suggestion is appreciated.

Thanks,
Roman.