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

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

bleepingcomputer.com

Post reply on HN
Print view View original

31–40 of 94 posts

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#31

Post by ianopolous »

LeifCarrotson wrote: post #16

At first I thought this was an error in implementing new docs related to Meltdown/Spectre. But the original research paper: https://everdox.net/popss.pdf 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 pendin…

On this particular thing I think the Intel docs are clear. This is where I implemented the same in JPC:

https://github.com/ianopolous/JPC/blob/master/src/org/jpc/em...

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#32

Post by dwighttk »

The vulnerability notes[1] say Apple patched this on May 8, but my last security update was May 3 and I don't currently show any available updates... I wonder if the May 3 patch fixed this, or if my computer might not be affected.

[1]https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD...

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#33

Post by inetknght »

Tobba_ wrote: post #18
paol wrote: post #7

Earlier quoted context omitted.

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…

> Intel docs are so consistently gibberish that it might as well be classified a separate language

Mayhaps much like legalese.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#34

Post by vardump »

codedokode wrote: post #30
hyperman1 wrote: post #23

I'm trying to understand this one, even if most of my ASM knowledge is from the 8086 era. My guess: * When an interrupt, debug exception, ... occurs, the CPU pushes stuff on the stack as part of the task switch. * The stack is managed by 2 registers: SS and (e/r)SP. To change your stack, you have to change both registers. If an interrupt happens and you've changed only 1, stuff gets pushed on an invalid stack and you…

> To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to change (e/r)SP and make the stack valid again. If there is a need for an interrupt, it will be delayed for 1 instruction. I wonder, why could not they make a single instruction to change both SS and SP?

They probably could, but it would have had a large silicon cost for 1980 without performance benefit. That and ISA incompatibility.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#35

Post by tych0 »

codedokode wrote: post #30
hyperman1 wrote: post #23

I'm trying to understand this one, even if most of my ASM knowledge is from the 8086 era. My guess: * When an interrupt, debug exception, ... occurs, the CPU pushes stuff on the stack as part of the task switch. * The stack is managed by 2 registers: SS and (e/r)SP. To change your stack, you have to change both registers. If an interrupt happens and you've changed only 1, stuff gets pushed on an invalid stack and you…

> To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to change (e/r)SP and make the stack valid again. If there is a need for an interrupt, it will be delayed for 1 instruction. I wonder, why could not they make a single instruction to change both SS and SP?

You could, but it wouldn't allow them to relax the constraints here, since you'd have to recompile all the code in the world to use this new instruction before relaxing.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#36

Post by Someone »

codedokode wrote: post #30
hyperman1 wrote: post #23

I'm trying to understand this one, even if most of my ASM knowledge is from the 8086 era. My guess: * When an interrupt, debug exception, ... occurs, the CPU pushes stuff on the stack as part of the task switch. * The stack is managed by 2 registers: SS and (e/r)SP. To change your stack, you have to change both registers. If an interrupt happens and you've changed only 1, stuff gets pushed on an invalid stack and you…

> To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to change (e/r)SP and make the stack valid again. If there is a need for an interrupt, it will be delayed for 1 instruction. I wonder, why could not they make a single instruction to change both SS and SP?

They could, but attackers would still use the approach that works for them.

And they can’t really remove the old instructions because of backwards compatibility.

Whitelisting a limited set of instructions that can follow setting SS and making all others trap might be an option, though. It still would break backwards compatibility, but if the effective impact would be negligible, they could deem it acceptable.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#37

Post by rocqua »

sillysaurus3 wrote: post #5
darkerside wrote: post #2

I'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…

Why can't there be automated test suites that catch unauthorized access issues before ship (if not before merge commit)? Usually the search space is too large.

Isn't that what fuzzing is for?

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#38

Post by hyperman1 »

codedokode wrote: post #30
hyperman1 wrote: post #23

I'm trying to understand this one, even if most of my ASM knowledge is from the 8086 era. My guess: * When an interrupt, debug exception, ... occurs, the CPU pushes stuff on the stack as part of the task switch. * The stack is managed by 2 registers: SS and (e/r)SP. To change your stack, you have to change both registers. If an interrupt happens and you've changed only 1, stuff gets pushed on an invalid stack and you…

> To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to change (e/r)SP and make the stack valid again. If there is a need for an interrupt, it will be delayed for 1 instruction. I wonder, why could not they make a single instruction to change both SS and SP?

There are. I suppose LSS SP,value is possible on i386+ and there is also the task state segment which might help. But this was a hack in the original 8086, which wasnt the best processor design ever to start with. It stays there because of backward compatibility.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#39

Post by nbsd4life »

sattoshi wrote: post #15
twunde wrote: post #11

I'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.

HardenedBSD is based on FreeBSD, not OpenBSD.

Re: Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

#40

Post by tmd83 »

Can someone explain the risk factor? It cannot be remotely exploited or though browser if I'm reading it right. But a malicious program with user level access can get kernel access. So exposure to malware running on a limited account can get higher access?
Post reply on HN