I'm super happy to see that the BSDs were contacted (with the exception of HardenedBSD).
Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
11–20 of 94 posts
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#12I'm sure the initial reaction here is going to be lamentation about the state of documentation. People will correctly point out that, if multiple entities misread the documentation, it just have been unclear. And they are right. But that doesn't make this Intel's fault alone. Clear or unclear, the documentation described behavior that was understood at the Intel organization, and the shipped product worked as describ…
It’s as simple as determining if a given program will halt.
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#13> Fixing the bug and having synchronized patches out by yesterday was an industry-wide effort, one that deserves praises, compared to the jumbled Meltdown and Spectre patching process.
Is this a fair comparison? I feel like the patching techniques must have been easier to develop than for Meltdown/Spectre. Furthermore, if this affected the same kind of people in this community, maybe this time around benefitted from the communication channels of the previous exercises.
Maybe this isn't a comparison to try and badmouth the previous iteration, and instead just tried to show a general improvement in the industry—I just find it a bit unfair.
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#14Wow, 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!
Speaking as a technical writer, if that many vendors misinterpreted the documentation then it was the fault of the documentation.
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#15I'm super happy to see that the BSDs were contacted (with the exception of HardenedBSD).
HardenedBSD would just receive it downstream from OpenBSD, wouldn't it? It's like contacting the Linux Mint group while contacting Ubuntu is sufficient.
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#16At first I thought this was an error in implementing new docs related to Meltdown/Spectre. But the original research paper:
the researcher wrote:
> Somewhere around the release of the 8086, Intel decided to add a special caveat to instructions loading the SS register...where loading SS with [`pop ss` or `move ss`] would force the processor to disable external interrupts, NMIs, and pending debug exceptions.
So it's a really, really old piece of documentation, dating from around 1980.
To call it a 'misinterpretation' rather than a vulnerability is extremely generous, given that most Intel engineers spent entire careers in the presence of code vulnerable to this 'misinterpretation' without calling the OS vendors out on their error.
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#17Wow, 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!
I was really sad to see Debian omitted from that list, they patched it too but were described as "other Linux distros" :(
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#18Wow, 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!
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.
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).
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#19I'm sure the initial reaction here is going to be lamentation about the state of documentation. People will correctly point out that, if multiple entities misread the documentation, it just have been unclear. And they are right. But that doesn't make this Intel's fault alone. Clear or unclear, the documentation described behavior that was understood at the Intel organization, and the shipped product worked as describ…
It’s as simple as determining if a given program will halt.
You forgot to include the sarcasm flag. I suppose "tag" these days, right?
Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs
#20"Both Peterson and the CERT/CC team blamed the "unclear and perhaps even incomplete documentation"
Yet the article's title makes it seems like it was the OS implementors faults instead of Intel's.
I wonder for what reasons the website tries to shift/soften Intel's fault on this?
Seems like there's a trend in news articles to have incoherent titles in relation to content lately, it's really annoying...