Privilege escalation vulnerability on 64-bit Intel CPU hardware
kb.cert.org
kb.cert.org
"Linux actually fixed the bug in 2006, with CVE-2006-0744. [ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0744 ] But the description says “Linux kernel before 2.6.16.5 does not properly handle uncanonical return addresses on Intel EM64T CPUs…”, which makes it sound like something Linux-specific. It’s therefore not surprising that it attracted little notice from other operating systems."
If you build a car which experiences temporal anomalies when driven at 88 miles per hour, it isn't good enough to have a line of fine print in the middle of a 1500 page manual. People expect to be able to drive a car at 88 miles per hour without ending up in the wrong century, and you should either not violate that assumption or have really big warning signs.
As I said, SYSCALL/SYSRET were introduced by AMD. Intel introduced their first x64-64 CPUs over a year after the architecture was introduced and in use (which is why FreeBSD still uses the name "amd64" for that platform).
From my perspective, Intel implemented an instruction, differently. I do not know enough about the low-level details to know best practices when detecting features supported by processors, but if the existing software is told (or figures out) "Yeah, I can do that" by/with the processor, Intel must have expected every single program using the instruction to ship an update? Nice.
This whole issue is way lower-level than anything I deal with on a regular basis so the whole time I've been looking at it from the very general perspective, eg. 'a cpu instruction' rather than 'the specific cpu instruction used by operating systems to switch to user mode on 64-bit processors, originally implemented by AMD and later implemented by Intel in accordance to the spec but differing in implementation' as happened here.
I'm not sure AMD's manual is particularly clear here either. The xen blog points out that the AMD behavior was determined by experimentation, because the manual doesn't specify when the canonical check occurs. From what I've gathered, the Intel behavior does in fact conform to the words of the AMD spec, it just doesn't mirror the implementation.
Every development team will need to carefully review every CPU manual coming out in the future, in case Intel decides to change what some other instruction does? Even when the scope is narrowed to operating systems and further to only when new features are added to one manufacturer's microprocessor from another's... ouch! At the very least, can we agree it is not a step in the right direction?
Just like software, CPU's have release notes that describe the major behavioral changes and additions. For most software, it will provide sufficient info. However, if you are writing an OS or want to wring out maximum performance, you will have to read about every single detail. For example, suppose that division gets 1 cycle cheaper, or that a pipeline gets one instruction deeper. That could shift the balance in such a way that a compiler needs to change in order to produce the best code possible.
Similarly, an OS might use a CPU feature or bug that gets changed (for an example, see the A20 line at http://en.wikipedia.org/wiki/DOS_memory_management#The_80286...)
Here's how I see this particular scenario: old software detects CPU supports [whatever] and uses it, bug-free. New processor tells old software it supports [whatever]. Old software tries [whatever], but new processor works differently - resulting in critical security vulnerability! Processor company blames software.
Processors almost never tell software anything; their manuals tell the programmers how the CPU behaves. There may be instructions that can inform code about you optional features of the instruction set, but the software has to run on the CPU before it can query the CPU for its capabilities, so it has to make some assumptions about the CPU (you could bootstrap things by having a smaller CPU boot the hardware and having that CPU query the 'real' one for its capabilities, but that just moves the problem to the smaller CPU)
So, in the end, the only way that software can know how the CPU behaves is because the programmers have read the CPU's documentation.
As to this specific case: I haven't bothered reading up on it, so I do not know what happened. It could be lack of documentation by Intel, it could be that AMDs documentation was incomplete or ambiguous and that Intel followed it, but implemented something slightly different, or it could be that Intel's documentation explicitly warned about this incompatibility with AMD devices.
And most specs leave room for different implementations, either by design or because the people writing the spec forgot or did not bother to describe a case. For a famous example, various versions of the 6502 treated undocumented opcodes differently (http://visual6502.org/wiki/index.php?title=6502_Unsupported_...) And yes, there was code that made use of these.
I looked at the AMD and Intel specs to see that both use the CPUID instruction function 80000001H to set bit 11 in EDX if SYSRET is supported. Because both AMD and Intel 64-bit processors support the same general instruction set, software written to check only bit 11 could easily run into the scenario I described. Again, I do not know best practices in detecting CPU features, but I do know software developers often tend towards the least necessary to do the the job.
yeah, ancient history