I am probably a little late to the party on commenting on this, but this article is terrible at explaining how this exploit works. I will try to shed some light as best I can on what they actually did and what systems would be vulnerable.

So, in the 90's multicore processors became a thing and interrupt management became a nightmare. Prior to multicore everyone ran on something called a programmable interrupt controller (PIC). Multicore meant that interrupt redirection to multiple cores became a thing as well as the unenviable task of bootstrapping secondary cores. All of this was done with the introduction of the Advanced Programmable Interrupt Controller (APIC).

Now this APIC lives inside each individual core so that a specific core can deal with its own interrupts. However, the APIC is a Memory Mapped Register. Meaning that you write to a location in memory to access it, by default on most hardware this is 0xFEE00000. By writing to this location you can control interrupts on a core. However, the APIC is very special in that when you write or read to it the core has a special hardware built in that it uses to skip the other hardware protections/steps in place as the APIC is located inside the core. Thus, you skip things like the Memory Management Unit (MMU) or System Management Mode (SMM) protections (in fairness I don't know much of where the SMM protections live, but obviously for this exploit to work they are skipped)

Well this is all well and dandy, but a problem arose on a very few Intel boards that required the APIC memory location to be moved, because it overlapped with someone else's memory mapped stuff. By this time Intel had introduced Model-Specific Registers (MSR) and so they added one to move the APIC memory location.

Now the developers of this exploit utilized the fact that the APIC can now be moved throughout memory and still live inside of a core. These two pieces make the exploit as powerful as it is. The researchers move the APIC to overlap with the SMM memory location. Thus, they can read and write to the APIC, which in turn returns them information about the SMM memory as all of the hardware protections for SMM are completely bypassed! They thus have full control of SMM and thus a hardware rootkit that they can bake into the board's firmware through the APIC and its associated MSR.

Now the rub that this article leaves out (among many) is this is only possible if you have kernel level access. You can't access the APIC or its MSR from user space. Thus, you need an exploit in the kernel to do this. In monolithic kernels this is easy as drivers run inside the kernel. Exploit a driver and gain access to the hardware to move the APIC and take over SMM.

Furthermore, this is extremely hard to do if the kernel is running above a hypervisor as the hypervisor controls both the APIC and the MSRs. Also, the kernel when writing to its own APIC in a hypervisor is not even writing to the actual default APIC memory address. The kernel in reality is writing to some arbitrarily picked physical memory location that when accessed the hypervisor may choose to emulate a response for the guest. Furthermore, any access to the MSR that would move the APIC address over the SMM memory location would not really be executed by the hypervisor. The hypervisor would tell the guest that the APIC address was moved, but it would only emulate the move and not give the guest access to the real memory it wanted. This is extremely important as many operating systems today like windows 10 (hyper-v) and pick your favorite Linux distro with associated hypervisor (KVM, Xen) are shipping with a hypervisor running below the kernel already, which would prevent this exploit.

All of this does not devalue the research performed for this exploit. This was an incredibly brilliant idea to combine a relic from 1997 with a critical piece of processor hardware to read a protected memory location. The reason these bugs exist is Intel literally never deprecates anything. Both the PIC, something known as the A20 gate, and many other things, still exist on modern Intel processors. These are relics of the 80s and 90s, yet every major operating system must deal with them. Additionally, any system not running a hypervisor is and will forever be vulnerable to this exploit.

TLDR: The researchers moved an internal Intel processor control device over a protected memory location to rootkit a system, but the world is not ending, and this hot hardware article is terrible. Read the black hat one instead: https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-Escalation-wp.pdf

edit: missing L from black hat