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

Destroying x86_64 instruction decoders with differential fuzzing

blog.trailofbits.com

Post reply on HN
Print view View original

91–100 of 113 posts

Re: Destroying x86_64 instruction decoders with differential fuzzing

#91

Post by beagle3 »

monocasa wrote: post #45
DannyB2 wrote: post #39

Earlier quoted context omitted.

The 8086 introduced the abomination of segment registers. That created many software limitations for much of the 80's. Compilers with 64 K limits on array sizes, or code segment sizes, and similar. By comparison the 680x0 on classic Mac was a pleasure to program. A nice large simple flat address space.

Segmentation is really nice, and should have been carried on, IMO. Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. Better segmentation support could have allowed you to sandbox memory without having to jump in and out of the kernel on transitions. Hence why VMWare, and Chrome's NaCL used segmentation har…

You are describing segmentation from the 286 protected mode and later. Real mode segmentation, originally introduced in the 8086/8088, is and always was an abomination, even if you don't compare it to the elegance of the contemporary 68000/68008.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#92

Post by souprock »

spc476 wrote: post #78
bogomipz wrote: post #27

Wow, this a wonderfully rich post! I had a question about the following statement: >"In short, it’s a mess, with each generation adding and removing functionality, reusing or overloading instructions and instruction prefixes, and introducing increasingly complicated switching mechanisms between supported modes and privilege boundaries." Can someone elaborate on how a instruction at the machine level can be "overloade…

A very simple example of this is the accumulator form of XCHG (exchange values). The accumulator form (AX/EAX/RAX is the accumulator) is encoded as: 10010rrr rrr = register 000 = AX/EAX/RAX 001 = CX/ECX/RCX 010 = DX/EDX/RDX 011 = BX/EBX/RBX 100 = SP/ESP/RSP 101 = BP/EBP/RBP 110 = SI/ESI/RSI 111 = DI/EDI/RDI More inportantly, the XCHG instruction does NOT affect the flags. So the upshot is that the instruction `XCHG a…

It gets worse with x86_64 though. Normally, an instruction that isn't 64-bit will clear the upper 32 bits of a 64-bit register. The NOP is special, because it shouldn't do anything. All the other 32-bit XCHG instructions still clear the upper 32 bits of a 64-bit register.

So the NOP really is different, and a normal XCHG EAX,EAX is not possible with the 0x90 encoding. You can get a normal XCHG EAX,EAX via the 2-byte ModRM form of the instruction.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#93

Post by tropo »

AnimalMuppet wrote: post #74
wolfgke wrote: post #67

Earlier quoted context omitted.

> z80 and 8086 were both garbage, next to the 68000. At that time, Z80 and 8088/8086 targeted very different market segments than the 68000. So, this is a quite unfair comparison.

OK, the 286 was also garbage compared to the 68000.

The 68000 has some serious design flaws in the architecture.

A notable one is the autoincrement and autodecrement of indirect memory references. This makes it difficult to get the architecture running instructions in parallel. Memory can be changing, but the address at which it changes is determined late.

It gets even more troublesome if the CPU comes with a MMU. It becomes necessary to avoid actually performing the autoincrement or autodecrement until all page faults have been resolved. (getting that VAX feel here) Remember that memory accesses can go to the same location as other memory accesses and/or to memory mapped IO, so simply rolling back the value is no good.

The situation with flags wasn't any better than x86 has, which is pretty bad. There are partial flags updates, undefined flag updates, and a mix of math flags with other types of flags.

The interrupt situation was bad. The CPU architecture specifies a small number of levels. Better designs, like x86 and PowerPC, leave that up to the interrupt controller chipset.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#94

Post by PeCaN »

cogman10 wrote: post #87
wolfgke wrote: post #29

Earlier quoted context omitted.

> I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Itanium was an architecture that was designed for "big iron", i.e. fast, powerful computers. It is thus, in my opinion, much harder to "scale down" to, say, mobile devices than x86.

I'd say the opposite is true. There isn't anything about Itanium that makes it worse for mobile. In fact, the opposite is true, it would be better for mobile because it was designed to push more of the optimizations into the compiler vs the hardware. That means less power required to do optimizations against running software. Because Itanium fits with mobile just as well as ARM does for much of the same reasons. Afte…

> There isn't anything about Itanium that makes it worse for mobile.

Shit code density?

Re: Destroying x86_64 instruction decoders with differential fuzzing

#95

Post by PeCaN »

monocasa wrote: post #37
withzombies wrote: post #20

Earlier quoted context omitted.

ARM64 is what Intel would design if they learned from the lessons of x86 and got a chance to restart.

I'm sure that's not true. I've heard a great rant from an Intel CPU engineer about how CISC is a great fit for large OoO cores. Like how memory RMW instructions can be thought of as allocating physical register file resources with no architectural register file requirements, no extra instruction stream bits required, and no confusions inside the core about register data dependencies of the instruction. It'd be fun to…

>It'd be fun to throw together a modern CISC-V or something that does a better job than x86 from an instruction encoding efficiency perspective, and see how it stacks up against modern RISCs.

It'd probably be about the same since the combination of microcode and macroop fusion makes RISC and CISC essentially the same thing internally. You're basically just trading complexity of the instruction decoder for code density.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#96

Post by monocasa »

beagle3 wrote: post #91
monocasa wrote: post #45

Earlier quoted context omitted.

Segmentation is really nice, and should have been carried on, IMO. Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. Better segmentation support could have allowed you to sandbox memory without having to jump in and out of the kernel on transitions. Hence why VMWare, and Chrome's NaCL used segmentation har…

You are describing segmentation from the 286 protected mode and later. Real mode segmentation, originally introduced in the 8086/8088, is and always was an abomination, even if you don't compare it to the elegance of the contemporary 68000/68008.

Well, and GE-645 (ie. the special purpose MULTICS machine), the iAPX 432 (that Intel chip that gets a bad rap), the Plessey 250, and the CAP computer off the top of my head.

ie. anywhere that describes the segment base, limit, and permissions on a separate privileged table.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#97

Post by snvzz »

tropo wrote: post #93
AnimalMuppet wrote: post #74

Earlier quoted context omitted.

OK, the 286 was also garbage compared to the 68000.

The 68000 has some serious design flaws in the architecture. A notable one is the autoincrement and autodecrement of indirect memory references. This makes it difficult to get the architecture running instructions in parallel. Memory can be changing, but the address at which it changes is determined late. It gets even more troublesome if the CPU comes with a MMU. It becomes necessary to avoid actually performing the…

>The 68000 has some serious design flaws in the architecture.

So do all CPUs from that era. This is why 68000 was replaced by Motorola itself. It's an abnormality x86 has been dragged this far.

>The CPU architecture specifies a small number of levels.

7 is pretty reasonable. They're autovectored, so interrupt latency is low. 68000 was often chosen for realtime applications due to this feature.

>Better designs, like x86 and PowerPC, leave that up to the interrupt controller chipset.

68000 doesn't in any way prevent having an external interrupt controller. Paula fills that role in the Amiga, providing 15 interrupts, mapped to the autovectored ones.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#98

Post by snvzz »

AnimalMuppet wrote: post #74
wolfgke wrote: post #67

Earlier quoted context omitted.

> z80 and 8086 were both garbage, next to the 68000. At that time, Z80 and 8088/8086 targeted very different market segments than the 68000. So, this is a quite unfair comparison.

OK, the 286 was also garbage compared to the 68000.

So were 386, 486 and Pentium.

At that time (Pentium), 68060 (which was also superscalar and released months earlier) would easily beat Pentium's performance at half the clock and much lower power.

Later on, x86 would surpass 68000 series, but only because Motorola never released a 68k successor for 68060. They moved on to PowerPC.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#99

Post by nipxx »

tenebrisalietum wrote: post #86
nipxx wrote: post #51

Earlier quoted context omitted.

It's alive and kicking on the Texas Instruments DSP chips. You can get incredible performance out of them, but you pay with horrible compile times. To give you a taste what these chips do: - 64 registers, 8 execution units, so 8 instruction can execute per cycle. Each instruction executes in a single cycle but may writes back the result later (multiplications do this for example). It's your responsibility to make sur…

I'm feeling extremely masochistic. What's the model number of one of these chips and/or a pointer to its instruction set reference?

For me it was the TMS320C64x+ There are newer versions of that chip out there with floating point support.

The glory instruction set reference is here:

https://www.ti.com/lit/ug/spru732j/spru732j.pdf

Re: Destroying x86_64 instruction decoders with differential fuzzing

#100

Post by burfog »

cogman10 wrote: post #87
wolfgke wrote: post #29

Earlier quoted context omitted.

> I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Itanium was an architecture that was designed for "big iron", i.e. fast, powerful computers. It is thus, in my opinion, much harder to "scale down" to, say, mobile devices than x86.

I'd say the opposite is true. There isn't anything about Itanium that makes it worse for mobile. In fact, the opposite is true, it would be better for mobile because it was designed to push more of the optimizations into the compiler vs the hardware. That means less power required to do optimizations against running software. Because Itanium fits with mobile just as well as ARM does for much of the same reasons. Afte…

Mobile is expected to run JIT translated code.

Itanium's design was finalized before JIT became important. Suddenly JIT was everywhere and spreading: Java, C# .net CLR stuff, Javascript, and more.

JIT output can not be well-optimized because that takes too long. The code must compile while the end-user waits, so there is no time to do anything good. The code will be terrible. Itanium can't handle that.

Post reply on HN