3 ms·
Prior to the introduction of SMM, Ring 0 (CPL0) was full privilege. The ability to kick the CPU into ICE mode, even if there was some way to actually do somethi
by amluto 4y ago
Prior to the introduction of SMM, Ring 0 (CPL0) was full privilege. The ability to kick the CPU into ICE mode, even if there was some way to actually do something in ICE mode [0] would have been, at most, a way to get at some Intel secret sauce. At attack against the system owner wasn’t in the cards, because the system owner never had any protection from CPL 0 code in the first place. (Unless the system could be induced to self destruct, but even a pretty good self destruct was likely possible from CPL 0 by destroying CMOS or potentially overwriting firmware.)
Even with the addition of SMM, this wouldn’t have been a very big deal - SMM was mostly a kludge to allow system vendors to provide value-added (supposedly) features, and an SMM break would just allow reverse engineering of or interference with these.
On a modern system, it’s a bigger deal. An attack against the ME is every bit as bad as it sounds. Even an attack against SMM breaks Secure Boot and protections against malicious firmware updates [1], which, in turn, could break some TPM protections.
[0] Maybe with cache poisoning? If the instruction after STOREALL could be fetched from cache and regular ring 0 could poison that cache, code execution in ICE mode might be possible.
[1] This is IMO a terrible design on Intel’s part. For some reason, UEFI secure variables are nearly universally implemented by protecting a region of flash from writes originating outside SMM mode. Once in SMM mode, they can be freely overwritten (at least unless SMM itself implements a protected kernel, which is the new hotness). Coming up with simpler and more secure designs is not terribly hard IMO.
- rep_lodsb 4y ago>Maybe with cache poisoning? If the instruction after STOREALL could be fetched from cache and regular ring 0 could poison that cache, code execution in ICE mode might be possible. The 286 had no internal cache (in the sense of CPUs today). It did have a queue of prefetched instruction bytes, as well as another queue of up to 3 decoded instructions. But that gets flushed by STOREALL, since it effectively returns the CPU to the same state as after a reset, only with the ICE mode flip-flop set. (Normal breakpoints, or any control transfer at all, also have to clear the queues, else the CPU would first execute whatever it had prefetched before continuing with code from the new location!) And yes, in my experiments with this I did try to stuff something in the prefetch queue anyway, as well as setting the IDT limit to zero and enabling the trap flag in the hope that it would cause a triple-fault while in ICE mode. No such luck. What might be possible is some external hardware that pushes opcode bytes onto the bus with the right timing. I'm not enough of a hardware person to design something like this, and don't think the DMA controller could be (ab)used for that purpose.
- anyfoo 4y agoEven with cheap modern equipment it should be no problem to manipulate the bus of something as glacially slow as a 286. With common bus frequencies, you don't even need to be really careful with the PCB layout, and e.g. a Zynq (FPGA+ARM SoC) is probably total overkill already but convenient and fun. But the unbonded pads that you mention are a far greater concern to me...
- amluto 4y agoFrom an extremely cursory read of old webpages, it sounds like the main problem is that the signal that initiates an ICE bus transaction (ICES1# & ICES0# which, by analogy to S0 and S1 are active-low and initiate bus cycles) are unbonded. I bet a good enough guess could be made from the address and data lines to feed instructions and data to the CPU in ICE mode. Distinguishing memory reads from writes could be interesting.
- rep_lodsb 4y agoIf every instruction is prefixed with F1, the only thing going through the ICE bus would be opcode fetches.
- deleted 4y ago[deleted]