Do UEFI DXE Drivers operate in real-mode? What about "ring -2" or "ring -3" code?

Question

I asked a question referencing a mode sometimes referred to as ring -2 (System Management Mode) which can be exploited to create rootkits. There's also even a rootkit candidate referred to as ring -3 (Intel Management Engine). Alternatively, there's this presentation which explains a rootkit based on software-based installation of malicious UEFI DXE Drivers.

An answerer on that question I asked argues essentially that rings other than 0-3 are silly, not real, and that System Management mode is just real-mode. I tried to verify this, but nowhere within any of the Wikipedia entries about real-mode, System Management Mode, Intel Management Engine, or UEFI is there mention of whether they're running in real-mode or ring 0 or what. So I'm trying to sort out the differences.

• Does a UEFI DXE driver run in real-mode or ring 0?
• Does System Management Mode ("ring -2") run in real-mode or ring 0?
• Does Intel Management Engine ("ring -3") run in real-mode or ring 0?

I do understand that these -2 and -3 modes aren't actual privilege rings, but rather refer to some special privilege gained, such as running when the computer is powered down in the case of -3. I'm just trying to clarify terminology and which things run with which privileges.

Answer 1

UEFI drivers can run in either protected mode or long mode, depending on their images. You should know that EFI images are Portable Executables. They have the same file format to EXEs, DLLs, SYSes, etc.. This means UEFI driver can run in protected mode if it a PE32 image. It can run in long mode if it is a PE32+ image.
You should understand there are two kinds of memories defined in UEFI: boot-service memory and runtime memory. OS loader can destroy boot-service memory once it has completed its initialization (i.e.: it no longer needs any boot services provided by the firmware). Runtime memories, however, will be preserved. No software other than runtime drivers are supposed to have access to the runtime memories, although the processor does not prevent other software from tampering them.
Anyway, in a word, codes that reside in runtime memories will run in Ring 0. OS loaders can enumerate the address map in order to know where are runtime memories so that OS will not touch them. If OS suspects there are some rootkits, OS can of course scan runtime memories to check them out.
Extra topic: although secure boot does not prevent codes from allocating runtime memories, signing authorities - for example, Microsoft - would typically refuse to sign such image. It is safe to assume no codes can reside in runtime memory when secure boot is configured with proper trusted keys.

System Management Mode, often abbreviated as SMM, operates in an isolated mode than ordinary x86 processor modes. This means SMM can run in real mode, protected mode and long mode. Processor will enter SMM when an SMI (System Management SMI) arrives. Each time the processor enters the SMM, it will be initialized to real mode. You can run 64-bit codes in SMM, but the entry of SMM must first switch the processor to long mode.
SMM is referred as Ring -2 because default treatment of SMIs will temporarily turn off the virtualization, which is often referred as Ring -1, before the entrance and restart virtualization after the processor left SMM. However, if SMM is not locked before hypervisor started its operation, hypervisors can containerize SMM and thus monitor SMI handlers. Perhaps you might want to call such hypervisors as Ring -3?
SMM is a special because certain operations to external hardware can only be recognized in SMM. Therefore, motherboard firmware would typically lock the SMM resources so that out-of-SMM codes cannot tamper with it.
Implementations of SMM differ among x86 vendors.

Intel ME is not a part of CPU. Instead, it is an external hardware with its own processing unit. Most implementations of motherboards would put ME in southbridge. In other words, it is funny to name its operation as Ring -3 because it is not CPU at all.
Intel ME is networked in that it is designed for out-of-band IT management operations (for example, power on the computer from remote).
Typically, ME cannot access memories not allocated by the firmware.
Early implementations of ME can be tampered by redirecting the ME's memory access to somewhere else through Intel VT-d. From now on, this method is no longer effective. Also, ME is protected by digital signature, so tampering the ME firmware image cannot insert your code into it. ME will be damaged instead.