1

In the page fault handler of the linux kernel using some opcode disassembly I am seeing that on the x86 architecture the CALL or 0xE8 instruction occasionally throws a write fault and ESI and EDI are both NULL. I was wondering if there is a specific reason for this as CALL takes a memory address and just changes EIP to that value and that doesn't require a page since it's just EIP + relative_offset. If anyone could clear this up it would be much appreciated.

Jesus Ramos
  • 22,940
  • 10
  • 58
  • 88

1 Answers1

8

The call instruction doesn't just change eip - it also has to write the current eip (updated to point to the next instruction) to the stack before that change. A jmp-type instruction would act as you suggest but call is slightly different in that you have to be able to ret to the current location later on.

I can't be sure since you haven't given us the code, full register contents and page tables (that would be a large amount of information for a question), but it seems to me the likeliest explanation is that the stack is currently switched out and needs to be bought back in.

The other possibility I originally thought of was that the address you were jumping to was non-resident but I don't think that would cause a fault on the call itself.

It would cause a fault very quickly afterwards as the CPU tried to fetch the next instruction but I don't think that's what your description indicates, since:

  • you state it's happening on the call; and
  • that would be a read fault, not a write one.

The esi and edi values are a non-issue - they take no part in a call.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • So writing the value of EIP to the stack for the RET would seem to cause this then. Thanks, I had forgotten about that and thought that because of the locality that the stack would be in memory but since it happens so little it might just be because the page is pte_none and has to expand the stack. – Jesus Ramos Jun 23 '11 at 20:43
  • It doesn't write eip to the stack. It writes next instruction's address to the stack – BlackBear Jun 23 '11 at 20:48
  • @BlackBear, the IP will almost certainly have already been updated inside the CPU as part of the instruction read so I'm claiming correctness on a technicality :-) Although, with today's massively-pipelined CPU's, who really knows for sure? I'll adjust the answer to clarify. Thanks. – paxdiablo Jun 23 '11 at 20:57
  • EIP gets incremented before it gets written to the stack so that should be correct as far as I know. – Jesus Ramos Jun 23 '11 at 21:11
  • EIP is a pseudo-register and is actually reconstructed in modern processors at the time of the call from the state of the pipeline when the pipeline resolves for writeback. The concept of whether it happens "before" or "after" the call is meaningless, since most processors operate an out-of-order pipeline. – SecurityMatt Dec 05 '12 at 22:02