search

lifting-bits / remill

Library for lifting machine code to LLVM bitcode
Apache License 2.0
1.27k stars 145 forks source link

X87 last instruction opcode recording #337

Open tathanhdinh opened 5 years ago

tathanhdinh commented 5 years ago

Hello all,

The Intel's document (vol1. sec 8.1.9) says that the FOP recording happens with x87 non-control instruction only but fnop is a control instruction (sec 8.3.11), so I wonder if the lifting of fnop is correct: https://github.com/trailofbits/remill/blob/12dc96a59c5cd20128f5318e7f1a8dabb3d000bd/remill/Arch/X86/Semantics/X87.cpp#L379-L382

where: https://github.com/trailofbits/remill/blob/12dc96a59c5cd20128f5318e7f1a8dabb3d000bd/remill/Arch/X86/Semantics/X87.cpp#L53-L59

but it seems that the FOP recording is disabled, because of the comment: https://github.com/trailofbits/remill/blob/12dc96a59c5cd20128f5318e7f1a8dabb3d000bd/tests/X86/Run.cpp#L668-L670

I'm still frustrated in tracking the X87 state and not sure if FOP recording is activated in current Intel's/AMD's CPU or not?

Many thanks for any help.

pgoodman commented 5 years ago

I maybe have had a reason for this, but I don't fully remember. Do you have access to hardware or a kernel that configures the hardware to actually do FOP recording? It may be that I observed it being recorded, and added it in there for that reason. In retrospect I should have documented this.

You are right that XED seems to think it's a control instruction

910 FNOP FNOP X87_ALU X87 X87 ATTRIBUTES: NOP NOTSX X87_CONTROL
tathanhdinh commented 5 years ago

@pgoodman thanks you for the response.

I've debugged the fcos on my machine (Intel i7-7700K CPU) but cannot see the FOP is changed:

print $native->x87.fxsave64.fop

gives 0.

If I'm reading the Intel's doc (sec 8.1.9.1) correctly, the FOP recording is in FOPcode compat mode, and this mode can be activated/deactivated by setting the bit 2 of IA32_MISC_ENABLE_MSR but only on Pentium 4 and Intel Xeon CPUs.

Moreover in the last phrase of the section:

More recent Intel 64 processors do not support fopcode compatibility mode and do not allow software to set bit 2 of the IA32_MISC_ENABLE MSR.

pgoodman commented 5 years ago

So, I'm happy to accept removal of FOP tracking for FPU_NOP. The better question is, do you want FOP tracking at all?

tathanhdinh commented 5 years ago

do you want FOP tracking at all?

No.

So will we drop FOP tracking on all FPU instructions? I can make a PR if you want.

pgoodman commented 5 years ago

Sure.

pgoodman commented 5 years ago

Actually, can do make it so that the macros and everything can continue to work?

pgoodman commented 5 years ago

That is, from remill/Arch/X86/Arch.cpp, make it so that a macro, like #define ENABLE_X86_FOP_TRACKING 0 is set, and similarly in the semantics somewhere. Then we can mostly leave code as is I think.

tathanhdinh commented 5 years ago

Actually, can do make it so that the macros and everything can continue to work?

I will do that.

Just profit the discussion to ask you an irrelevant thing, why in DecodeXED:https://github.com/trailofbits/remill/blob/12dc96a59c5cd20128f5318e7f1a8dabb3d000bd/remill/Arch/X86/Arch.cpp#L340-L351

you've used XED_CHIP_INVALID for setting input chip, it would be rather XED_CHIP_ALL, no?

pgoodman commented 5 years ago

Good point. Go for it.

tathanhdinh commented 5 years ago

So should it be XED_CHIP_ALL?

pgoodman commented 5 years ago

May as well try it out.