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

Remove illegal instruction from tests #210

Merged
merged 5 commits into from
Dec 23, 2017

Conversation

ranweiler
Copy link
Contributor

@ranweiler ranweiler commented Dec 23, 2017

Tests pass locally for me, but CI fails right now, likely due to #187 being hidden by #205.

The code segment (CS) register cannot be explicitly loaded, unlike the
other segment registers. The instruction `mov cs, rax` is thus illegal,
and triggered a SIGILL for each test case, causing all tests to
spuriously succeed.
The commit that first added this included an illegal instruction, which
caused false positives and hid the fact that this is redundant.
This reverts commit 9a9f370.

The bug in lifting-bits#205 is what made it seem like the underlying issue here had
been addressed.
@pgoodman
Copy link
Collaborator

I'm seeing lots of failures for fcmov-related instructions on Travis, e.g.

E1223 02:31:53.966231 10449 Run.cpp:566] States did not match for FCMOVNU_1 with ARG1=0x0 and CF=0 PF=0 AF=0 ZF=0 SF=0 DF=0 OF=0
/home/travis/build/trailofbits/remill/tests/X86/Run.cpp:568: Failure
Value of: !"Lifted and native states did not match."
  Actual: false
Expected: true

@pgoodman
Copy link
Collaborator

I think what is happening is that the DEF_FPU_SEM macro is updating the fpu cs, and that maybe is not quite right anymore?

@ranweiler
Copy link
Contributor Author

@pgoodman I just did one last double-check on my local box right now with fully-rebuilt Docker images, and actually am getting some of the CI errors— I think I had some stale state when locally testing the last commit. I'm going to try it (a) without checking the CS register, (b) without saving any segment registers.

@pgoodman
Copy link
Collaborator

This could be an artefact of the test runner being a 64-bit program, even when running the 32-bit tests. Specifically, we'll need to figure out if the running fxsave in a 32-bit program saves the cs, where the equivalent fxsave in a 64-bit program doesn't.

@pgoodman
Copy link
Collaborator

What I'm getting at is that, the fxsave64 format doesn't record the cs, so maybe behind the scenes, 64-bit mode doesn't record the cs either, and so it just zeroes it out when using fxsave.

@ranweiler
Copy link
Contributor Author

@pgoodman that's consistent with what I see locally on a totally fresh image: I'm saving all the segment registers except CS, and all tests pass. I could amend the last commit to save all the seg registers except CS, and we could open a separate issue for the 32/64-bit(?) CS situation.

@ranweiler
Copy link
Contributor Author

Okay, not including the CS register gets rid of almost all of the CI test failures (on that run, anyway). Locally, I observe no test failures if I exclude the CS register.

@ranweiler
Copy link
Contributor Author

I've amended the last commit to exclude CS, which ensures we have only CI failures for now.

@ranweiler ranweiler force-pushed the remove-illegal-test-instr branch 2 times, most recently from 37566e9 to bd3779c Compare December 23, 2017 04:22
@pgoodman
Copy link
Collaborator

I figure this is the source of the issue:
image

I think the "right" thing to do is re-add your saving of cs in the PrintSaveState.cpp, and then perhaps in the Run.cpp, what we can do is a cpuid check on whether or not we should bother checking cs in the fxsave, and if not, zero out the lifted version (which does save it).

// CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 1
//
// Where "bit 13" is a 0-based index.
static bool AreFCSAndFDSDeprecated() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(void) as param list.

@@ -458,6 +490,14 @@ static void RunWithFlags(const test::TestInfo *info,
memset(lifted_state->x87.fxsave.st, 0, kill_size);
memset(native_state->x87.fxsave.st, 0, kill_size);

#if 32 == ADDRESS_SIZE_BITS
// If FCS and FDS are deprecated, don't compare them.
if (AreFCSAndFDSDeprecated()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (32 == ADDRESS_SIZE_BITS && ...), that way we don't get a compiler warning about AreFCSAndFDSDeprecated being unused.

@@ -458,6 +490,14 @@ static void RunWithFlags(const test::TestInfo *info,
memset(lifted_state->x87.fxsave.st, 0, kill_size);
memset(native_state->x87.fxsave.st, 0, kill_size);

#if 32 == ADDRESS_SIZE_BITS
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant to remove the #if and just depend on the actual if :-P

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that makes more sense (-:

The reason I used #if is because the referenced fields don't exist in 64-bit mode, so you get a compiler error.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh duh! I didn't make that connection.. lol. So then the additional check in the if is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently not? One moment...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, yes, the #if is necessary, I just assumed you were talking about some other warning I missed. Reverting the redundant expression.

@pgoodman pgoodman merged commit b50d29f into lifting-bits:master Dec 23, 2017
@ranweiler ranweiler deleted the remove-illegal-test-instr branch December 23, 2017 23:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

More accurate floating-point rounding in X86 FMA extension instructions False positives in tests
2 participants