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

11–20 of 113 posts

Re: Destroying x86_64 instruction decoders with differential fuzzing

#11

Post by setpatchaddress »

wvenable wrote: post #8
tyoma wrote: post #5

Earlier quoted context omitted.

Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big selling point.

There is value in the fact that the instruction set is an abstraction. CPU's built with more low-level instruction sets became obsolete faster because they couldn't adapt to new features and maintain compatibility as easily.

Sounds like survivorship bias.

x86's longevity is due to the amount of money thrown at the problem. You could surely start with a much cleaner instruction set like the M68k and wind up with a same-or-better result after spending billions on multiple projects to invent new ways of ameliorating the complexity of the ISA, some in parallel, over time.

Or you can start by eliminating most of the decode complexity and not spend those billions, like ARM.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#12

Post by jcranmer »

setpatchaddress wrote: post #11
wvenable wrote: post #8

Earlier quoted context omitted.

There is value in the fact that the instruction set is an abstraction. CPU's built with more low-level instruction sets became obsolete faster because they couldn't adapt to new features and maintain compatibility as easily.

Sounds like survivorship bias. x86's longevity is due to the amount of money thrown at the problem. You could surely start with a much cleaner instruction set like the M68k and wind up with a same-or-better result after spending billions on multiple projects to invent new ways of ameliorating the complexity of the ISA, some in parallel, over time. Or you can start by eliminating most of the decode complexity and not…

The decoder doesn't actually take all that much space in the hardware, though. It's going to be smaller than the normal OoO logic, which means it's a pretty minor tax at best for actual hardware.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#13

Post by wolfgke »

teddyh wrote: post #6
stragies wrote: post #2

From the great article: "x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..." Nice way of wording that! :) It also explains the complexity of the following 10 pages of text.

See also this old Microsoft Windows 95-era joke: “ 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. ”

> “32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.”

DOS was a 16 bit operating system. The 8088 (the processor of the IBM-PC) was an 16 bit (if you consider the instruction set) or 8 bit (if you consider the width of the data bus) processor.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#14

Post by upofadown »

>... a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA.

In fairness to the Intel of that era, they actually did a really good job with this. They gained basically zero warts from the 8080 assembler source compatibility. They mostly set out to make the best variable length 16 bit instruction set they could. They had significant competition at the time and they pretty much had to make the 8086 instruction set something very usable. The x86 instruction set horror mostly came after that.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#15

Post by api »

Tangent but: what's the additional overhead on a modern chip of parsing this crazy instruction set vs. a simpler to parse one like PPC64 or ARM64? Is it significant compared to all the other stuff that almost all modern CPUs do like out of order execution, register renaming, SIMD, virtualization, etc. etc. etc.?

I've seen many people argue that it's significant but I never see anything in depth from anyone who really knows. People just assume it is.

A counterargument I heard once is that there is kind of a fixed complexity to parsing it and that it was significant in the past but as CPU feature sizes have shrunk and transistor counts increased (Moore's law) it's stayed relatively constant and become insignificant today compared to all the other uses of die space.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#17

Post by withzombies »

stragies wrote: post #2

From the great article: "x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..." Nice way of wording that! :) It also explains the complexity of the following 10 pages of text.

ARM64 (aka AArch64) is the best version of x86 yet.

It's clean, very little warts, they learned from their mistakes with ARMv7/Thumb2 (specifically the IT instruction).

It helps that Apple controls the whole ecosystem and could seamlessly move to ARM64. The Android transition has been making progress also.

Maybe someday we'll drop 32bit and 16bit support in x86 systems (and also in "modern" programming languages!).

Re: Destroying x86_64 instruction decoders with differential fuzzing

#18

Post by woodruffw »

buckminster wrote: post #16

This is really nice. I wonder if anyone has tried fuzzing a CPU's instruction decoder? It would be surprising if they didn't have bugs.

Yep! sandsifter[1] does exactly that.

[1]: https://github.com/xoreaxeaxeax/sandsifter

Re: Destroying x86_64 instruction decoders with differential fuzzing

#19

Post by shakna »

withzombies wrote: post #17
stragies wrote: post #2

From the great article: "x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..." Nice way of wording that! :) It also explains the complexity of the following 10 pages of text.

ARM64 (aka AArch64) is the best version of x86 yet. It's clean, very little warts, they learned from their mistakes with ARMv7/Thumb2 (specifically the IT instruction). It helps that Apple controls the whole ecosystem and could seamlessly move to ARM64. The Android transition has been making progress also. Maybe someday we'll drop 32bit and 16bit support in x86 systems (and also in "modern" programming languages!).

> ARM64 (aka AArch64) is the best version of x86 yet.

Huh? Isn't that ARM and not even remotely compatible with x86?

Re: Destroying x86_64 instruction decoders with differential fuzzing

#20

Post by withzombies »

shakna wrote: post #19
withzombies wrote: post #17

Earlier quoted context omitted.

ARM64 (aka AArch64) is the best version of x86 yet. It's clean, very little warts, they learned from their mistakes with ARMv7/Thumb2 (specifically the IT instruction). It helps that Apple controls the whole ecosystem and could seamlessly move to ARM64. The Android transition has been making progress also. Maybe someday we'll drop 32bit and 16bit support in x86 systems (and also in "modern" programming languages!).

> ARM64 (aka AArch64) is the best version of x86 yet. Huh? Isn't that ARM and not even remotely compatible with x86?

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