using a self decompressing image can lead to a an invalid IA and stop the cpu

[flaviojs]

Test Scenario:

• start dynamips with a c2600 image that self decompresses
  • ./path/to/dynamips.exe -P 2600 [-j] c2600-image.bin
• somehow the execution goes to an invalid IA after decompression
• the cpu stops

I'm using a x86 cygwin stable build.

NOTE: with no instructions being processed the console is obviously unresponsive, so this problem might be perceived as the console hanging

Test Configurations:

Tried each configuration 3 times.

• jit, memwatch:
  • after decompression I get the error Invalid IA 0x00000005
• nojit, memwatch:
  • all ok
• jit, no memwatch:
  • after decompression I get the error Invalid IA 0x00000005

It's unrelated, but the cygwin console doesn't work properly after killing the dynamips process.

~~Initial Suspicion:~~

• ~~the memory page with the self decompression code is compiled in JIT~~
• ~~the self decompression code writes data to it's own page~~
• ~~somehow the jit code of the page isn't invalidated (critical part)~~
• ~~finally, an out of date instruction (jit code) is executed, leading to unpredictable results~~

Current State:

• since it doesn't manifest with jit disabled and i'm using a x86 stable build, it's related to the x86 jit code
• since it doesn't manifest in the unstable branch, which has new tcb code, it's probably related to that code
• there is also a memory leak of x86 jit ops somewhere (haven't been able to track it down yet), so it might be related to that

Related Topics:

TODO

[grossmj]

I confirm this never worked for c2600 IOS images. We have always recommended users to decompress c2600 IOS images themselves before using them in GNS3/Dynamips.

[flaviojs]

Investigation results:

• I'm unfamiliar with ppc assembly, so I wasted a lot of time trying to find out which instructions write to memory. They are the STW instruction and variants. =~~
• how a STW instruction is compiled:
  • DECLARE_INSN(STW) calls ppc32_emit_memop_fast
  • goes to the /* === Slow lookup === */ section for COW and EXEC pages (our case)
  • calls the ppc32_stw function
• the ppc32_stw function calls ppc32_mem_access:
  • this function has a section to invalidate the jit code
  • the stable and unstable code is different (further investigation postponed)
  • */!* a particular difference stands out, the unstable code calls cpu_exec_loop_enter for self modifying pages (our case)

Not calling cpu_exec_loop_enter can be the cause of this bug, assuming it continues execution in the next jit compiled instruction, now out of date.

This also suggests that unstable doesn't have this issue. Testing time... is tomorrow. =)

[flaviojs]

Unstable doesn't have this issue. Merging the code for self modifying pages from unstable isn't enough to fix it, so the investigation will continue.

[flaviojs]

No leads on the cause. I'll try merging unstable stuff to stable (in my fork) until there is a change in behavior.