Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Privilege escalation vulnerability on 64-bit Intel CPU hardware

kb.cert.org

Post reply on HN
Print view View original

31–37 of 37 posts

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

#31

Post by j_s »

Someone wrote: post #29
j_s wrote: post #25

Earlier quoted context omitted.

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…

Thanks for sharing your perspective. I guess I don't consider running (old) software on a processor that has implemented an existing instruction set to be porting, but in this case it comes down to how software is expected to enable use of processor features at run-time (and I don't know best practices there).

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.

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

#32

Post by mikeash »

j_s wrote: post #30
mikeash wrote: post #28

Earlier quoted context omitted.

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

Sorry about that. Given that the code which uses the instruction is not a "program" per se but rather is found in OS kernels, I hope you can understand my confusion. How many x86-64 kernels existed and had to be changed at the time?

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

#34

Post by Someone »

j_s wrote: post #31
Someone wrote: post #29

Earlier quoted context omitted.

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…

Thanks for sharing your perspective. I guess I don't consider running (old) software on a processor that has implemented an existing instruction set to be porting, but in this case it comes down to how software is expected to enable use of processor features at run-time (and I don't know best practices there). Here's how I see this particular scenario: old software detects CPU supports [whatever] and uses it, bug-fre…

"New processor tells old software it supports [whatever]"

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.

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

#35

Post by j_s »

mikeash wrote: post #32
j_s wrote: post #30

Earlier quoted context omitted.

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

Sorry about that. Given that the code which uses the instruction is not a "program" per se but rather is found in OS kernels, I hope you can understand my confusion. How many x86-64 kernels existed and had to be changed at the time?

No worries!

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.

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

#36

Post by j_s »

Someone wrote: post #34
j_s wrote: post #31

Earlier quoted context omitted.

Thanks for sharing your perspective. I guess I don't consider running (old) software on a processor that has implemented an existing instruction set to be porting, but in this case it comes down to how software is expected to enable use of processor features at run-time (and I don't know best practices there). Here's how I see this particular scenario: old software detects CPU supports [whatever] and uses it, bug-fre…

"New processor tells old software it supports [whatever]" 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…

I agree with you in the general case.

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.

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

#37

Post by mikeash »

j_s wrote: post #35
mikeash wrote: post #32

Earlier quoted context omitted.

Sorry about that. Given that the code which uses the instruction is not a "program" per se but rather is found in OS kernels, I hope you can understand my confusion. How many x86-64 kernels existed and had to be changed at the time?

No worries! 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 implement…

My understanding is that instructions which are only used by OS kernels tend to be a little less stable than those used by general-purpose user programs. However, this is not exactly my area of expertise.
Post reply on HN