Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Old Intel instructions: MOV TRx, JMPE, FNSTDW, FSTSG, FRSTPM, LOADALL, etc #184

Open
tremalrik opened this issue Apr 28, 2021 · 1 comment
Assignees
Labels
A-decoder Area: Decoder C-enhancement Category: Enhancement of existing features P-medium Priority: Medium

Comments

@tremalrik
Copy link

Doing further digging, I've found a handful of instructions that have been supported by only a limited number of old Intel x86 processors and that Zydis doesn't recognize:

  • MOV to/from the TRx "test registers" (0F 24 /r and 0F 26 /r) (386, 486, removed from Pentium onwards)
  • JMPE: Early Itaniums were able to run x86 natively; they have the JMPE instruction to transition from x86 to the Itanium ISA. Ths instruction exists in two forms (0F 00 /6 and 0F B8 imm16/32); a more complete description of the instruction can be found in the Itanium SDM, volume 4, page 256.
  • FNSTDW AX (DF E1) and FSTSG AX (DF E2): These instructions are listed in various places as being instructions present only in the Intel 387SL coprocessor. Documentation seems hard to find; they're listed by the Potemkin Group's old OPCODE.LST, and there exists an expired-in-2013 patent that describes FNSTDW in more detail but a more official-looking data book seems nowhere to be found.

These seem kind-of straightforward, in that their encodings have never been reused for any other opcodes and will produce an UD on any modern processor.

Other instructions/opcodes are murkier:

  • FRSTPM: an instruction in the Intel 287XL coprocessor that is not present in any later processor. For this one, there exists an official-looking data book that, on its last page, lists the encoding as DB F4. For some reason, other sources, such as sandpile.org and OPCODE.LST, list its encoding as DB E5 instead. This raises the question of which one is correct, and in case of DB F4, how to handle that the encoding has been reused as "fcomi st,st(4)".
  • The 0F A6 and 0F A7 opcodes. These have been assigned twice by Intel, first as XBTS/IBTS in early 386, then as CMPXCHG in early 486. The XBTS/IBTS instruction were dropped almost immediately after introduction, and CMPXCHG was quickly moved to a different opcode (0F B0 and 0F B1), and Intel has left 0F A6/A7 unassigned since. (VIA/Zhaoxin processors have assigned them to the VIA PadLock encryption instruction set extension, which has in turn later been augmented with Chinese crypto by Zhaoxin. )
  • The 0F 05 and 0F 07 opcodes. In modern processors, they're assigned to SYSCALL and SYSRET; in older processors, they were famously the undocumented LOADALL instructions (0F 05 being the 286 LOADALL and 0F 07 being the 386 LOADALL).
  • The recently-discovered 286-only SAVEALL (F1 0F 04), where F1 is working as a prefix rather than the standalone "int1" instruction it became from 386 onwards.

I suppose the question then becomes - which, if any, of these, should Zydis recognize?

@flobernd flobernd self-assigned this Apr 28, 2021
@flobernd flobernd added A-decoder Area: Decoder C-enhancement Category: Enhancement of existing features P-medium Priority: Medium labels Apr 28, 2021
@flobernd
Copy link
Member

Thanks for the detailed issue.

At the moment, sadly, Zydis lacks the option to select a specific chip. Because of that we decided to assume the most modern chips in case of ambiguous instructions (even in cases where previously valid instructions are invalid nowdays).

Some of the instructions (e.g. Padlock) could be supported by adding a new decoder mode - like you suggested in your other issue, for other ones it might be more difficult. I will have to look at it in detail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-decoder Area: Decoder C-enhancement Category: Enhancement of existing features P-medium Priority: Medium
Projects
None yet
Development

No branches or pull requests

2 participants