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

61–70 of 94 posts

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

#61

Post by Someone »

Someone wrote: post #36
codedokode wrote: post #30

Earlier quoted context omitted.

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

Follow-up: not only could they, they did. https://software.intel.com/sites/default/files/managed/7c/f1..., page 4-385:

“Loading the SS register with a POP instruction suppresses or inhibits some debug exceptions and inhibits interrupts on the following instruction boundary. (The inhibition ends after delivery of an exception or the execution of the next instruction.) This behavior allows a stack pointer to be loaded into the ESP register with the next instruction (POP ESP) before an event can be delivered. See Section 6.8.3, “Masking Exceptions and Interrupts When Switching Stacks,” in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. Intel recommends that software use the LSS instruction to load the SS register and ESP together.”

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

#62

Post by mrpippy »

twunde wrote: post #11

I'm super happy to see that the BSDs were contacted (with the exception of HardenedBSD).

Definitely, it appears this is thanks to the work/awareness of Nate Warfield at MSRC

https://twitter.com/dk_effect/status/993903701419999232

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

#63

Post by Someone »

hyperman1 wrote: post #54

I wonder what happens if you execute multiple POP SS instructions. In fact, you could set up a 64K v86 mode segment containing only copies of the POP SS instruction. jmp far into it. When IP reaches the last instruction it wraps around and starts again. Will it ever be interrupted by anything? If the stack usage bothers it, just do MOV SS,AX

Intel thought of that, but doesn’t seem to give us an answer. https://software.intel.com/sites/default/files/managed/7c/f1..., page 6-8:

”If a sequence of consecutive instructions each loads the SS register (using MOV or POP), only the first is guaranteed to inhibit or suppress events in this way.”

So, we still don’t know. For all I know, it may even depend on the exact cpu used or cpu state.

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

#64

Post by dfox »

std_throwaway wrote: post #53

Is this also affecting code in 64 bit mode?

As the code in the paper is written for amd64 I would assume that it is affecting it.

In the other hand it is somewhat surprising, because loading anything into SS is mostly pointless operation.

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

#65

Post by emily-c »

A bit tangentially related, but I've always wondered why the syscall instruction doesn't use the TSS for stack switching like int does. I guess it does give you more flexibility to load rsp from gs during a cpl 3 -> cpl 0 transition rather than consulting the TSS to switch it automatically. Can anyone weigh in on this?

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

#66

Post by Sgt_Apone »

Someone wrote: post #59
Sgt_Apone wrote: post #14

Earlier quoted context omitted.

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

It also could be innate complexity of the thing being documented. Looking at https://software.intel.com/en-us/articles/intel-sdm , the combined PDF has 4.844 pages.

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.

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

#67

Post by himom »

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?

In protected mode, SS is a descriptor offset into the GDT. It doesn’t make sense to change SS very often unless there are multiple stacks. Furthermore, it doesn’t make sense to overcomplicate an already over-complicated instruction set burdened with vestigal, legacy features. And, loading SS and SP atomtically would probably create a byte pattern that’s too long to encode.

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

#68

Post by std_throwaway »

dfox wrote: post #64
std_throwaway wrote: post #53

Is this also affecting code in 64 bit mode?

As the code in the paper is written for amd64 I would assume that it is affecting it. In the other hand it is somewhat surprising, because loading anything into SS is mostly pointless operation.

This doesn't even make sense. Why would they keep a behavior that could be considered a bug when creating a new instruction set?

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

#69

Post by pritambaral »

gregkh wrote: post #25
jgtrosh wrote: post #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…

This is one of the first times that I know of that the Linux kernel and Windows kernel developers discussed a security issue together directly. So while the fix was much simpler than Meltdown/Spectre was (Linux was fixed with a patch that was written in 2015) overall, the communication between different OS kernel developers right now is very good. And yes, it is all due to the horrible Meltdown/Spectre problem and ho…

> We were not allowed to work together for that problem

How do you mean?

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

#70

Post by [deleted] »

inetknght wrote: post #33
Tobba_ wrote: post #18

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN