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

61–70 of 113 posts

Re: Destroying x86_64 instruction decoders with differential fuzzing

#61

Post by wtarreau »

DannyB2 wrote: post #39
upofadown wrote: post #14

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

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.

segment registers were a cheap MMU before its age. It was the only way to run code without relocation tables at various addresses. Mind you that at this era the whole operating system fitted in 40kB of RAM! My old turbo-pascal 3.0 editor+compiler was something around 37 kB! Just try to write a hello world of that size nowadays! It's pointless to criticize the past based on 10000 times more powerful hardware nowadays, which doesn't even deliver the same work faster due to the tremendous waste of resource caused by laziness and incompetence.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#62

Post by weinzierl »

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…

> Segmentation is really nice, and should have been carried on, IMO.

Are you serious and are you talking about x86 memory segmentation? Honest question. As far as I'm concerned thinking about CS, DS and ES still gives me shivers and I don't remember to ever have met anyone back then who loved segmentation. The only thing I hated more was the bit planes stuff on the graphics card...

Re: Destroying x86_64 instruction decoders with differential fuzzing

#63

Post by monocasa »

adwn wrote: post #52
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…

One major issue was that the segments overlapped, so two different pointers could actually point to the same address. > 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. You don't need segments for that. A flat address space where the 2 MSBs (or however many you need) of a pointer encode the context would…

I mean, that's just a reimplementation of segments.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#64

Post by monocasa »

weinzierl wrote: post #62
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…

> Segmentation is really nice, and should have been carried on, IMO. Are you serious and are you talking about x86 memory segmentation? Honest question. As far as I'm concerned thinking about CS, DS and ES still gives me shivers and I don't remember to ever have met anyone back then who loved segmentation. The only thing I hated more was the bit planes stuff on the graphics card...

The 16-bit segments weren't great because you were forced to jump through all these hoops in order access the full addressable space. 32-bit segments that weren't crippled led to a lot of really interesting applications that weren't able to be replicated with what we have now. Hence why there's this gap of amd64 CPUs where there's no virtualization support in long mode but 32bit OSes could on the same chips.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#65

Post by wolfgke »

unlinked_dll wrote: post #33
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.

x86 hasn't really proven that it scales down well for mobile devices either.

Intel produced SoCs for mobile devices, concretely Speatrum SC9853i and Spreadtrum SC9861G-IA.

If you want to scale even further down, consider Intel Quark (https://en.wikipedia.org/wiki/Intel_Quark). For an analysis why it failed in the market, consider http://linuxgizmos.com/who-killed-the-quark/

To me, it seems that the central reason why these chips failed commercially is that at the lower end, SoCs offer a much thinner margins than CPUs for laptops, desktop PCs and servers.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#66

Post by jabl »

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…

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

There are ways to make page table swapping cheaper. E.g. SPARC and S390 always had separate page tables for user and kernel space, with an "ASID (address space identifier)" to avoid having to flush them when switching.

I believe decently modern x86 CPU's also have this in the form of "PCID".

Re: Destroying x86_64 instruction decoders with differential fuzzing

#67

Post by wolfgke »

snvzz wrote: post #50
upofadown wrote: post #14

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

z80 and 8086 were both garbage, next to the 68000. It's sad x86 survived this far and is still so popular. Hopefully RISC-V will put an end to this hell.

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

Re: Destroying x86_64 instruction decoders with differential fuzzing

#68

Post by jabl »

darkmighty wrote: post #30
jcranmer wrote: post #12

Earlier quoted context omitted.

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.

Instruction complexities can be used to save bandwidth/delay (and related energy consumption) at the cost of decoder size. Communication limitations are increasingly dominant in processors afaik; so the analysis is not so simple as to decoder size either.

Compressed RISC ISA's (e.g. RISC-V C extension) achieve density comparable to x86, with a much simpler decoder.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#69

Post by wolfgke »

roca wrote: post #56
rayiner wrote: post #38

Earlier quoted context omitted.

Itanium was one of those scenarios where theory blew up in practice. In theory it’s great for software to have complete control of instruction ordering. In practice, software simply doesn’t have enough information at compile time to do that. As proven by the fact that even Itanium moved to an OOO architecture in Paulson. It comes down to memory latency. Even an L3 cache hit these days is 30-40 cycles. It’s hard to pr…

Right. Generally, memory accesses in real-world software are unpredictable enough (no matter how good the compiler is) that single-threaded execution is always going to get a big boost from OOO. An interesting question is why Intel believed otherwise when they created IA64. I think there's a strong case that publication bias and other pathologies of academic compuer science destroyed billions of dollars in value, and…

> An interesting question is why Intel believed otherwise when they created IA64.

For numerics code, VLIW can indeed offer huge advantages. Unluckily, computer programs from different areas have quite a different structure and thus do not profit from VLIW so much.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#70

Post by monocasa »

jabl wrote: post #66
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…

> 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. There are ways to make page table swapping cheaper. E.g. SPARC and S390 always had separate page tables for user and kernel space, with an "ASID (address space identifier)" to avoid having to flush them when switching. I believe decently modern x86 CPU's…

Even with ASIDs, it's still orders of magnitude more expensive to round trip through the kernel rather than call (even far call).
Post reply on HN