Share via

SMIs Are EEEEVIL (Part 1)

  • Article

As a quick introduction, SMIs were introduced to the x86 world by the 386SL. It was created to allowed systems designers to have access to the CPU while unspecified software of any type was running. The reasons for this are obvious when you look at the market the 386SL was aimed it. It was Intel's first attempt at a truly mobile CPU. SMIs allowed the BIOS to control various aspects of power management on the CPU, regardless of what kind of OS was running on top of it. That was a good thing in the days when DOS still ruled the land. DOS knew as much about power management as your average light bulb, and letting the system designer control how and when devices were turned on and off seemed like a great solution. The problem is how it was implemented

To implement SMI, Intel created a new interrupt pin on their CPU, appropriately named the SMI# pin. When this pin was asserted, (turned on, essentially) the system would halt everything it was doing, save state, and transition into System Management Mode (SMM). SMM is essentially another entire operating mode for the CPU, just like Real Mode, V86 Mode, and Protected Mode. The big difference here is that this mode can't be signaled from software, and everything that happens is 100% transparent to software. Once the system enters into SMM mode, it's truly like time stands still. Everything you know about the state of the system can change from underneath you from one instruction to the next. This includes every part of the OS, which generally assumes, (rightfully so) that things will always be a certain way until it says otherwise.

As you can imagine, this requires the systems programmer to get everything right, or disaster can ensue. Needless to say, the reason I am writing about it is because it often does. I'll go into some of the weirdness you can see, and what you might do about it in part 2.

Comments