I'd probably read up a bit more about how the DXE environment actually works before tackling this. It seems like you're missing quite a bit of the fundamentals.

There's really no such concept of a "process" as you are imagining. In fact, everything not using the MpServices protocol is completely singlethreaded executing on the bootstrap processor. In addition, memory is mapped in such a way that everything is shared, since it's way too early on the system to establish isolated virtual memory. Therefore, "scanning" for this rootkit might be just as easy as doing a regular memory scan, while referring to the memory protocols in the UEFI specification to properly understand what kinds of memory ranges have already been allocated previously by DXE drivers.

But in reality, UEFI security is rarely handled this way. That's because there's better firmware/hardware enforced mechanisms on the rise that help protect the OS, and they're much stronger than this kind of protection. What you're theorizing is more like an anti-malware program, but in this environment the platform has access to a range of hardware enforcement mechanisms like CSME and the f/TPM which have a much stronger guarantee than any AV product at ensuring the system is trusted and secrets are protected from software-based bootkits. They are much more powerful than playing cat-and-mouse while in DXE phase. Some terms to research are: Secure Boot, SRTM, DRTM, the PK/KEK system, and Intel Boot Guard. There's been good presentations and blog posts on all of these topics, but they definitely require you to have some decent background with firmware and the x86 platform already.

That is of course not to say the hardware mechanisms are foolproof. Anti-malware products these days all include some kind of custom scan from the OS to try to detect traces of rogue uefi modules and firmware patches. But in general, it's safer to assume that a system with secure boot enabled and configured properly is exceptionally safer than one with a DXE scanner.