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

71–80 of 94 posts

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

#71

Post by an_account_name »

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

They might be clear today. Were they always? There are literally decades of timeline to examine here.

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

#72

Post by twunde »

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 a separate OS forked from FreeBSD with its own kernel development. While the BSDs may share some code, they're essentially all different OS'. There is no upstream like Linux has. As a side-note after Spectre/Meltdown, Shawn Webb complained in a NYCBUG thread about getting not being able to get access to these embargoed vulnerabilities.

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

#73

Post by dooglius »

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

Tested it: you get an interrupt after only skipping one instruction

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

#74

Post by hyperman1 »

dooglius wrote: post #73
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

Tested it: you get an interrupt after only skipping one instruction

Thanks, both dooglius and Someone. One learns something everyday.

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

#75

Post by confounded »

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.

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

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

#76

Post by monocasa »

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

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

#77

Post by ithkuil »

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…

They also had a more recent chance to clean up this with the which to 64 bit

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

#78

Post by tedunangst »

confounded wrote: post #75
hannob wrote: post #56

Earlier quoted context omitted.

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

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.

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

#79

Post by ianopolous »

an_account_name wrote: post #71
ianopolous wrote: post #31

Earlier quoted context omitted.

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

They might be clear today. Were they always? There are literally decades of timeline to examine here.

They were clear in 2006 when I was reading them. All the emulator implementors were very aware of it. Many old operating systems won't boot without the delay.
Post reply on HN