Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs • Hacker News Board

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

#91

Post by tropo » Fri, May 11, 2018, 11:59 PM UTC

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…

Two others that look like bugs:

1. The CPU does a buffer overflow when reading the array of bits used to determine IO permission for instructions like "in" and "out". Every OS which supports the feature has to add an extra byte of 0xff beyond the end of the array.

2. Returning from a 32-bit OS to a 16-bit process will only update the low 16 bits of the stack pointer. The upper 16 bits can still be read, leaking info about the kernel stack. Linux has a complicated work-around called espfix.

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

#92

Post by Vogtinator » Sat, May 12, 2018, 10:13 PM UTC

Tobba_ wrote: post #52

simion314 wrote: post #29

Earlier quoted context omitted.

If you can't trust the CPU documentation how can you test that addition works? even if you could test all possible combinations of terms to add and verify the results there may be a hidden flag somewhere that when flipped will change how addition works.

On that subject, I'm curious whether there is any CPU out there that sets the overflow flag incorrectly when computing (-1) - n when n is the most negative number (which negates to itself, so implementing subtraction by simply negating the RHS and adding will screw up the flags).

The ARM ARM documents sub(left, right, no carry) as add(left, ~right, carry set), which is also the most straightforward implementation if you have to account for carry anyway.

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

#93

Post by ianopolous » Mon, May 14, 2018, 8:27 AM UTC

caf wrote: post #83

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

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.

Agreed, but that's just saying that combining two or more simple things results in a more complex thing. All platforms I know of describe each individual instruction and its consequences, and leave you to deduce the consequences of combining them.

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

#94

Post by ysleepy » Tue, May 15, 2018, 9:01 PM UTC

adrianratnapala wrote: post #81

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 sai…

I stumbled on a blogpost by bunnie huang which describes a liability angle, which I found to be plausible: https://www.bunniestudios.com/blog/?p=5127 - worth a read.