5 ms·

Wow, the article shows that many vendors mis-read the docs: Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros...as well as VMware

by erric 8y ago

Wow, the article shows that many vendors mis-read the docs: Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros...as well as VMware and Xen. This is going to be a busy day!

tpaksoy 8y ago
Maybe the docs were written badly? If everyone makes the same mistake, then there might be something wrong in the source.
paol 8y ago
At that point can it really be attributed to "mis-reading" the docs? If every single independent implementor understood it the same way, the docs were wrong.
- Tobba_ 8y ago
  To be fair, Intel docs are so consistently gibberish that it might as well be classified a separate language (similar to english, but only a quarter the information density). In this case it seems they just didn't properly specify a piece of insane behaviour though. Hell, I'd consider it an outright CPU bug if I'm reading this right. Seemingly there's a "feature" where loading SS causes interrupts to be delayed until after the next instruction, even if the next instruction disables interrupts - so you can cause an interrupt to fire on the first instruction of the handler (where it should be impossible).
  - inetknght 8y ago
    > Intel docs are so consistently gibberish that it might as well be classified a separate language Mayhaps much like legalese.
    - deleted 8y ago
      [deleted]
  - tropo 8y ago
    Two others that look like bugs: 1. The CPU does a buffer overflow when reading the array of bits used to determine IO permission for instructions like "in" and "out". Every OS which supports the feature has to add an extra byte of 0xff beyond the end of the array. 2. Returning from a 32-bit OS to a 16-bit process will only update the low 16 bits of the stack pointer. The upper 16 bits can still be read, leaking info about the kernel stack. Linux has a complicated work-around called espfix.
Sgt_Apone 8y ago
Speaking as a technical writer, if that many vendors misinterpreted the documentation then it was the fault of the documentation.
- Someone 8y ago
  It also could be innate complexity of the thing being documented. Looking at https://software.intel.com/en-us/articles/intel-sdm https://software.intel.com/en-us/articles/intel-sdm, the combined PDF has 4.844 pages.
  - Sgt_Apone 8y ago
    I have no doubt that the complexity adds to the difficulty of documenting it. But, I still think the documentation is failing when people across the industry who should be able to parse this complexity are unable to. Complexity just isn't an excuse for broadly misunderstood documentation in my opinion.
samueloph 8y ago
I was really sad to see Debian omitted from that list, they patched it too but were described as "other Linux distros" :(
erikb 8y ago
And in Germany it's national holiday. Really great.
- jacquesm 8y ago
  Not just Germany, a very large chunk of Europe has a holiday today. Belgium, France, Netherlands, Portugal, the Nordics and Switzerland I'm sure about, there may be others.
hannob 8y ago
> Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros. Just to clarify, this is kernel code. Listing 3 different (+ "other") Linux distros as affected is kinda bogus, it's not that they all made the same mistake, they just all use the same kernel.
- sxcurry 8y ago
  Also, Apple and Microsoft are not an “OS”. This is a poorly written article unfortunately.
- confounded 8y ago
  Many of them use different versions of the same underlying Linux kernel, sometimes put together in different ways.
  - tedunangst 8y ago
    It seems improbable that there are multiple ways of putting together the kernel's handling of mov ss.
    - acdha 8y ago
      As an example, Red Hat doesn’t ship major kernel upgrades except with major releases. If you’re running RHEL 6, you’re still on a 2.6 kernel and the fact that someone patched 4.x probably doesn’t help you all that much unless you have the time to backport the change and confirm that it doesn’t break something else.
- SmellyGeekBoy 8y ago
  Not necessarily, maybe they all contributed their own (incorrect) fixes?

by erric 8y ago

tpaksoy 8y ago

Maybe the docs were written badly? If everyone makes the same mistake, then there might be something wrong in the source.

paol 8y ago

At that point can it really be attributed to "mis-reading" the docs? If every single independent implementor understood it the same way, the docs were wrong.

Tobba_ 8y ago
To be fair, Intel docs are so consistently gibberish that it might as well be classified a separate language (similar to english, but only a quarter the information density). In this case it seems they just didn't properly specify a piece of insane behaviour though. Hell, I'd consider it an outright CPU bug if I'm reading this right. Seemingly there's a "feature" where loading SS causes interrupts to be delayed until after the next instruction, even if the next instruction disables interrupts - so you can cause an interrupt to fire on the first instruction of the handler (where it should be impossible).
- inetknght 8y ago
  > Intel docs are so consistently gibberish that it might as well be classified a separate language Mayhaps much like legalese.
  - deleted 8y ago
    [deleted]
- tropo 8y ago
  Two others that look like bugs: 1. The CPU does a buffer overflow when reading the array of bits used to determine IO permission for instructions like "in" and "out". Every OS which supports the feature has to add an extra byte of 0xff beyond the end of the array. 2. Returning from a 32-bit OS to a 16-bit process will only update the low 16 bits of the stack pointer. The upper 16 bits can still be read, leaking info about the kernel stack. Linux has a complicated work-around called espfix.

Sgt_Apone 8y ago

Speaking as a technical writer, if that many vendors misinterpreted the documentation then it was the fault of the documentation.

Someone 8y ago
It also could be innate complexity of the thing being documented. Looking at https://software.intel.com/en-us/articles/intel-sdm https://software.intel.com/en-us/articles/intel-sdm, the combined PDF has 4.844 pages.
- Sgt_Apone 8y ago
  I have no doubt that the complexity adds to the difficulty of documenting it. But, I still think the documentation is failing when people across the industry who should be able to parse this complexity are unable to. Complexity just isn't an excuse for broadly misunderstood documentation in my opinion.

samueloph 8y ago

I was really sad to see Debian omitted from that list, they patched it too but were described as "other Linux distros" :(

erikb 8y ago

And in Germany it's national holiday. Really great.

jacquesm 8y ago
Not just Germany, a very large chunk of Europe has a holiday today. Belgium, France, Netherlands, Portugal, the Nordics and Switzerland I'm sure about, there may be others.

hannob 8y ago

> Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros. Just to clarify, this is kernel code. Listing 3 different (+ "other") Linux distros as affected is kinda bogus, it's not that they all made the same mistake, they just all use the same kernel.

sxcurry 8y ago
Also, Apple and Microsoft are not an “OS”. This is a poorly written article unfortunately.
confounded 8y ago
Many of them use different versions of the same underlying Linux kernel, sometimes put together in different ways.
- tedunangst 8y ago
  It seems improbable that there are multiple ways of putting together the kernel's handling of mov ss.
  - acdha 8y ago
    As an example, Red Hat doesn’t ship major kernel upgrades except with major releases. If you’re running RHEL 6, you’re still on a 2.6 kernel and the fact that someone patched 4.x probably doesn’t help you all that much unless you have the time to backport the change and confirm that it doesn’t break something else.
SmellyGeekBoy 8y ago
Not necessarily, maybe they all contributed their own (incorrect) fixes?