
Intel X86 Encoder Decoder - luu
https://intelxed.github.io/
======
monocasa
I wonder if this was released due to Xen's recent x86 instruction emulation
bugs.

[http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-9932](http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-9932)

[http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-9383](http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2016-9383)

~~~
Sephr
Those CVEs are private. Could you provide a public source?

~~~
Fnoord
Relevant Xen Security Advisory

[https://xenbits.xen.org/xsa/advisory-200.html](https://xenbits.xen.org/xsa/advisory-200.html)

[https://xenbits.xen.org/xsa/advisory-195.html](https://xenbits.xen.org/xsa/advisory-195.html)

All XSA

[https://xenbits.xen.org/xsa/](https://xenbits.xen.org/xsa/)

------
derefr
Seems like this would make one able to write the object-code codegen phase of
a compiler at a rather higher level (at least if you're only targeting x86, or
are willing to write similar libraries for your other arch targets.)

Or, to put it another way: looks like a good library for adding "just a bit of
JIT" to an interpreter, without going full LLVM.

------
dreamcompiler
"As new instructions are made public"? WTF does that mean? We're not even
allowed to know the full instruction set of an X86 CPU?

~~~
dbcurtis
Not allowed yet.

Ex-Intel here. It takes years to gestate new instructions. First specs are in
controlled documents available to Intel employees only. Eventually, when
things are nailed down, preliminary specs are available under an NDA where a
VP approves/signs the Intel side of the NDA. Tool vendors will get those
specs. Finally, when the chip is announced the previously NDA documents become
public. I was a CPU designer at multiple companies, and everyone follows a
similar process.

~~~
derefr
You're just talking about the design phase of a new ISA extension. I think the
parent was under the impression that there were instructions _in released
processors_ that were undocumented.

~~~
dreamcompiler
That was exactly my impression. I don't have a problem with new instructions
in new processors being undocumented at first, but purposely undocumented
instructions are troubling and would push me away from Intel for new designs.

~~~
dbcurtis
So, you are the decision maker for whether or not Intel CPU's get designed
into your product? If so, I'm sure several Intel salespeople have you on speed
dial.

The 286 had purposely undocumented instructions, of this sort: "Ooops this is
b0rk3d. It will always be b0rk3d. Let's pretend it didn't happen." So for
generations there were holes in the op code map that people tip-toed around.
Especially since Intel (meaning the internal grey-beard collective) also
forgot exactly what those opcodes were and what they were supposed to do. You
care, why, exactly?

It's not like the NSA slips extra opcodes into executables that you compile
with your own compiler in order to spy on you. They have much easier ways to
spy on you.

Also, it's not like it is that hard to throw unused opcodes at the decoder and
see which ones give you the illegal instruction exception, and which ones do
something else. You now have a homework assignment. Have fun, let us know what
you find.

------
majke
This is awesome. I thought it's closed source. I wonder how close it is to the
hardware.

Can I assume that whatever is parsed by XED is going to be parsed in the same
way by real CPU's?

~~~
mjcharney
XED author here...

That's one goal certainly. Not claiming it is perfect. I have been working on
it a long time and _many_ cycles have been run on it between Pin, Intel SDE
and some internal simulators that boot OSes, etc.

------
struct
How does this compare to ARM's VIXL?

[1] [https://github.com/armvixl/vixl](https://github.com/armvixl/vixl)

------
thecompilr
About time they open sourced it. Funny how it is Python according to github :)

~~~
chubot
Why is that funny? Python seems like the perfect language for this kind of
thing. You can see the logic with minimal noise.

~~~
unwind
It's funny since it's not very accurate: the Python is used to generate C code
from tables describing instruction encodings (that's my understanding, haven't
cloned this and built it). But there is plenty of actual C code in there too,
and the resulting "thing" is a C library.

Python would _not_ be as suitable as the full implementation language, since C
is much more easily accessed from other languages, which is a good property
for a library like this.

------
jonjohn84
Looks handy. Thanks for posting, Dan.

------
dsfyu404ed
Something that is universal is not remarkable. People will not make as much
use of an unremarkable opportunity as they will of a remarkable one.

