Privilege escalation vulnerability on 64-bit Intel CPU hardware • Hacker News Board

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#21

Post by mikeash » Mon, Jul 02, 2012, 4:51 PM UTC

cperciva wrote: post #19

mikeash wrote: post #17

Earlier quoted context omitted.

Presumably they should have at least read it after the Intel manuals shipped. (And did Intel really ship x86-64 CPUs without corresponding manuals? Weird if so.) Now, not doing so is a completely understandable mistake, but still a mistake.

And did Intel really ship x86-64 CPUs without corresponding manuals? Weird if so. 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).

Right, I know about that, but I still would have expected them to put out their own manuals for their CPUs which implemented that architecture.

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#22

Post by j_s » Mon, Jul 02, 2012, 5:06 PM UTC

mikeash wrote: post #17

cperciva wrote: post #15

Earlier quoted context omitted.

How precisely should OS developers have read the fine print in Intel's 1500 page manual which hadn't yet been published when support for SYSCALL/SYSRET was implemented ?

Presumably they should have at least read it after the Intel manuals shipped. (And did Intel really ship x86-64 CPUs without corresponding manuals? Weird if so.) Now, not doing so is a completely understandable mistake, but still a mistake.

I believe the point was that the software worked 100% correctly. Your point seems to be that the software should have been updated to support Intel CPUs when they were released.

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.

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#23

Post by wwkeyboard » Mon, Jul 02, 2012, 5:09 PM UTC

spullara wrote: post #18

They don't have AWS on the list. Were they not notified or were they not affected? Are they vulnerable now?

I believe they use Xen. (and so thinks wikipedia http://en.wikipedia.org/wiki/Amazon_Web_Services)

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#24

Post by tedunangst » Mon, Jul 02, 2012, 5:13 PM UTC

cperciva wrote: post #15

mikeash wrote: post #14

Earlier quoted context omitted.

I'd say blame accumulates pretty well on both sides, here. Certainly Intel should not have gratuitously changed their behavior from AMD's. On the other hand, OS code often needs to deal with CPU-specific behavior, and they definitely should have read that fine print in the middle of the 1500 page manual when implementing this code, especially when the 1500 page manual's index points to exactly that fine print for thi…

How precisely should OS developers have read the fine print in Intel's 1500 page manual which hadn't yet been published when support for SYSCALL/SYSRET was implemented ?

Well, you didn't really need to read the fine print to do the right thing. AMD's manual also says noncanonical addresses are bad. You're correct that it was unwise for Intel to change the error behavior, but it's also unwise for the OS to depend on that error behavior when it's possible to avoid the error entirely.

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.

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#25

Post by j_s » Mon, Jul 02, 2012, 5:17 PM UTC

mikeash wrote: post #14

cperciva wrote: post #9

Earlier quoted context omitted.

Intel's position is disingenuous at best. The SYSRET instruction was introduced by AMD long before Intel added support for it, so it was entirely natural for people to expect that Intel's implementation would be consistent with AMD's specification. 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 ma…

I'd say blame accumulates pretty well on both sides, here. Certainly Intel should not have gratuitously changed their behavior from AMD's. On the other hand, OS code often needs to deal with CPU-specific behavior, and they definitely should have read that fine print in the middle of the 1500 page manual when implementing this code, especially when the 1500 page manual's index points to exactly that fine print for thi…

Pointing to the manual sets a terrible precedent.

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?

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#26

Post by j_s » Mon, Jul 02, 2012, 5:19 PM UTC

mspeed wrote: post #2

This is old news.

While perhaps a link would have been better, this was fixed in Linux in 2006.

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#27

Post by mikeash » Mon, Jul 02, 2012, 6:57 PM UTC

j_s wrote: post #25

mikeash wrote: post #14

Earlier quoted context omitted.

I'd say blame accumulates pretty well on both sides, here. Certainly Intel should not have gratuitously changed their behavior from AMD's. On the other hand, OS code often needs to deal with CPU-specific behavior, and they definitely should have read that fine print in the middle of the 1500 page manual when implementing this code, especially when the 1500 page manual's index points to exactly that fine print for thi…

Pointing to the manual sets a terrible precedent. 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 st…

Of course we can agree that it's not a step in the right direction. I said pretty explicitly that blame falls on both sides here.

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#28

Post by mikeash » Mon, Jul 02, 2012, 6:59 PM UTC

j_s wrote: post #22

mikeash wrote: post #17

Earlier quoted context omitted.

Presumably they should have at least read it after the Intel manuals shipped. (And did Intel really ship x86-64 CPUs without corresponding manuals? Weird if so.) Now, not doing so is a completely understandable mistake, but still a mistake.

I believe the point was that the software worked 100% correctly. Your point seems to be that the software should have been updated to support Intel CPUs when they were released. 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)…

This isn't "every single program", it's only OS system call code. My understanding is that code in the kernel sometimes needs adjustment for new CPUs, due to errata or just plain old changes.

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#29

Post by Someone » Mon, Jul 02, 2012, 8:17 PM UTC

j_s wrote: post #25

mikeash wrote: post #14

Earlier quoted context omitted.

I'd say blame accumulates pretty well on both sides, here. Certainly Intel should not have gratuitously changed their behavior from AMD's. On the other hand, OS code often needs to deal with CPU-specific behavior, and they definitely should have read that fine print in the middle of the 1500 page manual when implementing this code, especially when the 1500 page manual's index points to exactly that fine print for thi…

Pointing to the manual sets a terrible precedent. 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 st…

Of course people porting software will have to read. How else do you expect them to figure out the do's and don'ts of a new CPU?

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...)

Re: Privilege escalation vulnerability on 64-bit Intel CPU hardware

#30

Post by j_s » Mon, Jul 02, 2012, 10:00 PM UTC

mikeash wrote: post #28

j_s wrote: post #22

Earlier quoted context omitted.

I believe the point was that the software worked 100% correctly. Your point seems to be that the software should have been updated to support Intel CPUs when they were released. 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)…

This isn't "every single program", it's only OS system call code. My understanding is that code in the kernel sometimes needs adjustment for new CPUs, due to errata or just plain old changes.

Nice quote there; I said "every single program using the instruction".