Daemonic Dispatches

Side channel attacks: Intel vs. AMD

Three weeks ago, Jan Beulich discovered that the FXSAVE and FXRSTOR instructions on AMD processors behave differently from the same instructions on non-AMD processors: On AMD processors, the FOP, FIP, and FDP debugging registers are normally not saved and restored. Much like the Hyper-Threading side channel, this allows programs to spy upon each other and determine the code path and location of data being accessed, even though the value of the data handled is not revealed. This issue has now been fixed in FreeBSD, NetBSD, OpenBSD, Xen, and the Linux kernel.

While these two issues are on first glance rather similar -- they both concern information leakage between processes, can only be exploited by local users, utilize low-level processor mechanics, and are specific to a particular vendor's products -- there are some important differences. When Intel implemented Hyper-Threading in the Pentium 4, simultaneous multi-threading was not a very well understood area, and the problems of information leakage were little known; while it happens that Intel processors were vulnerable, I don't think that Intel did anything wrong in producing such processors -- they were just overtaken by developing research. In contrast, AMD took instructions which had been added by Intel as part of the SSE instruction set, claimed (via the CPU feature flags) to support SSE, and then did not fully implement said instructions in order to make their processors faster. Imagine the outcry if Intel's famous FDIV bug had been implemented deliberately because division was faster if you didn't insist upon getting the right answers!

However, a far more significant difference between these two problems is how the vendors responded. When I first reported the Hyper-Threading problem to Intel, I had trouble finding anybody willing to talk to me at all. Eventually, and thanks in large part to intervention from one of Intel's customers, I was contacted by Ernie Brickell, a respected cryptographer who now works for Intel. Sadly, this communication was still almost exclusively one-way: Intel wanted to know what FreeBSD was planning on doing about the problem, and wanted to know who the other security people were with whom I was discussing the problem, but whenever I asked what Intel was planning on doing, Ernie told me that he 'would need to get permission from a room full of people' before he could tell me anything. In fact, the only thing I learned from talking to Intel was that they didn't consider such information leakage to be a problem at all.

In contrast, AMD's response was superb. In discussions on the vendor-sec mailing list prior to public disclosure of the issue, they first promptly acknowledged the issue and stated when they would make an official response available; next, when we asked to see their response before the issue was publicly disclosed, they agreed to this; and finally, in their response they not only accepted that the problem existed, but they provided considerable background information and two different ways that they problem could be fixed -- this was particularly helpful to FreeBSD, since I wrote our patch based almost entirely upon the recommendations provided by AMD.

I have no intention of getting involved in debates about which company makes the better CPUs; as far as I'm concerned, they both make great processors. As someone working in the field of computer security, however, I can say this: There's at least one area where Intel can definitely learn some lessons from AMD.