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

81–90 of 94 posts

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

#81

Post by adrianratnapala »

ysleepy wrote: post #24

The x86 ISA and its implementations are now in the spotlight of the whole security research community. There is probably a lot more to come since it accumulated a lot of cruft in the name of backwards compatibility. I hope we learn a lot, and take the time to record the experience, for coming platforms like RISC-V and others. Why is there no big CAVEATs document from intel detailing weird quirks. I strongly assume th…

> I strongly assume the intel arch engineers are well aware of many of those counter-intuitive behaviours in their products.

But it is likely just kind of distributed, organic knowledge that is hard to condense into a single document. Writing and maintaining such a thing would be a significant project, and (I am speculating here) not the kind of thing that significantly burnishes anyone's performance review.

That said, the whole community of assembly-hackers has even broader knowledge of the topic, and could start such a document out in the open. And Intel engineers might likely contribute their own two cents. (Unless lawyers forbid it).

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

#82

Post by [deleted] »

std_throwaway wrote: post #68
dfox wrote: post #64

Earlier quoted context omitted.

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?

[deleted]

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

#83

Post by caf »

ianopolous wrote: post #31
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...

The interrupt shadow itself is clear.

The specific implication of that for a mov ss ; syscall pair with a hardware breakpoint set on the first instruction is a lot more subtle.

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

#84

Post by acdha »

tedunangst wrote: post #78
confounded wrote: post #75

Earlier quoted context omitted.

Many of them use different versions of the same underlying Linux kernel, sometimes put together in different ways.

It seems improbable that there are multiple ways of putting together the kernel's handling of mov ss.

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.

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

#85

Post by yuhong »

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.

I bet whitelisting only instructions that can change SP/ESP would not break the majority of x86 code. All other instructions would behave as if MOV SS had not been executed.

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

#86

Post by yuhong »

monocasa wrote: post #76
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 use the same scheme other places as well. sti hlt will hold off on enabling the interrupts until right after the hlt has started so that you don't end up in a race condition when you get an interrupt between sti and hlt. Albeit, they could have made an stiandhlt instruction here as well.

That one will take trace exceptions though.

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

#87

Post by yuhong »

hyperman1 wrote: post #49
vardump wrote: post #34

Earlier quoted context omitted.

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

The cost would not have been very big. The 8086 had microcode, and there were the very similar LDS and LES instructions. There were plenty of unused slots in the opcode table so that wasnt it the reason either. There are weird instructions aplenty like XLAT or AAA/AAS/AAD/AAM, so it wasnt as if they had a pressing silicon shortage. Maybe they dindt think about it, and fixed it with a quick hack once they got aware of…

The fun thing is the 286 didn't fix this either. This is why the MOV SS came first (in protected mode the selector may not be present for example). This was a problem for DOS where SS was often used to access the DOS data segment.

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

#88

Post by monocasa »

yuhong wrote: post #86
monocasa wrote: post #76

Earlier quoted context omitted.

They use the same scheme other places as well. sti hlt will hold off on enabling the interrupts until right after the hlt has started so that you don't end up in a race condition when you get an interrupt between sti and hlt. Albeit, they could have made an stiandhlt instruction here as well.

That one will take trace exceptions though.

Sure, that makes sense.

A trace exception shouldn't be creating work for a thread context that's ostensibly the one going to sleep with nothing to do, but an external interrupt very likely is.

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

#89

Post by SmellyGeekBoy »

hannob wrote: post #56
erric wrote: post #3

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!

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

Not necessarily, maybe they all contributed their own (incorrect) fixes?

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

#90

Post by SmellyGeekBoy »

pritambaral wrote: post #69
gregkh wrote: post #25

Earlier quoted context omitted.

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?

It was covered by NDA.
Post reply on HN