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

Indirect jumps lead to incorrect assumptions #351

Open
bmourad01 opened this issue Nov 29, 2021 · 2 comments
Open

Indirect jumps lead to incorrect assumptions #351

bmourad01 opened this issue Nov 29, 2021 · 2 comments

Comments

@bmourad01
Copy link
Contributor

bmourad01 commented Nov 29, 2021

Consider the following BIL program:

{
  if (f1) {
    #56 := v1
    jmp #56
  }
  else {
    v1 := mem[sp + 8, el]:u64
  }
  #1 := mem[sp, el]:u64
  sp := sp + 8
  #56 := #1
  jmp #56
}

We would expect that the final value of #56 will be conditional, summarized by the postcondition:

(ite (= init_f10 #b0)
     (concat (select init_mem0 (bvadd #x0000000000000007 init_sp0))
             (select init_mem0 (bvadd #x0000000000000006 init_sp0))
             (select init_mem0 (bvadd #x0000000000000005 init_sp0))
             (select init_mem0 (bvadd #x0000000000000004 init_sp0))
             (select init_mem0 (bvadd #x0000000000000003 init_sp0))
             (select init_mem0 (bvadd #x0000000000000002 init_sp0))
             (select init_mem0 (bvadd #x0000000000000001 init_sp0))
             (select init_mem0 init_sp0))
     init_v10) 

However, this is not how WP treats it in BIR:

00000016: sub sub_%00000016()


00000007:
0000000d: when f1 goto %00000008
0000000e: goto %00000009

00000009:
0000000a: v1 := mem[sp + 8, el]:u64
00000011: goto %0000000f

00000008:
0000000b: #56 := v1
0000000c: goto #56
00000010: goto %0000000f

0000000f:
00000012: #1 := mem[sp, el]:u64
00000013: sp := sp + 8
00000014: #56 := #1
00000015: goto #56

And indeed, it seems to treat the goto #56 at tid 0000000c as a no-op, which results in our goal above being refuted.

A solution would be to tighten assumptions about the behavior of indirect jumps (perhaps here?)

@bmourad01
Copy link
Contributor Author

On second thought, maybe it's an issue with the Bil_to_bir implementation:

It seems to insert the goto %0000000f in the block 00000008 even though 0000000f is not reachable from this block.

Perhaps a fix would be to just run a pass on the generated blocks and remove all jump terms that occur after an unconditional jump within a given block.

@codyroux
Copy link
Contributor

Yes, indirect jumps are treated as a "goto exit" currently. I built in a handler for them (here:

Env.get_indirect_handler env t_exp env post t_exp false
), but I'm not sure what the best way to populate it is.

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

No branches or pull requests

2 participants