Fwd: Use of the PC value in interrupt/exception handlers

[Konstantin Belousov]

On Fri, Aug 02, 2013 at 07:08:08PM +0900, Piyus Kedia wrote:
> Dear all,
> 
> We are working on developing a dynamic binary translator for the kernel.
> Towards this, we wanted to confirm if the interrupted PC value pushed on
> stack by an interrupt/exception is used by the interrupt/exception
> handlers? For example, is the PC value compared against a fixed address to
> determine the handler behaviour (like
> Linux's page fault handler compares the faulting PC against an exception
> table, to allow functions like copy_from_user to fault).
> 
> Basically, we are wondering if it is safe to replace the pushed PC value on
> stack by another value. This would be safe if the PC value is only used for
> returning from interrupt, or for reading contents at that PC address (e.g.,
> to decode the instruction at current PC). It would be unsafe if the value
> of the address itself is meaningful to the handler.
> 
> We found that in FreeBSD segment-not-present exception handler checks the
> trapped PC value against some fixed kernel PC by looking at the code,
> except that it is only used for debugging purposes. It would be nice if
> somebody could also confirm this.

You did not specified which architecture you are talking about. There
are subtle differences between i386 and amd64 in this area, and I have
no knowledge of other architectures. The answer to your question if very
machine-specific.

Yes, the most obvious place where the instruction pointer is replaced if
the trap(). There, one case is when saved %rip points to the predefined
list of the instructions which might fault because their operations are
inherently non-safe.  This list is mostly populated with addresses from
the interrupt return sequence.

Another mechanism, implemented in the trap() but actually used by other
code, in particular, the copyin/copyout, but also other functions, is
the pcb_onfault handler. If e.g. page fault happens during the copying,
the control stream is passed to the handler specified in pcb_onfault.
Look at the support.s for examples.  I am not sure if this use is relevant
to you.

The ddb looks for the special rip values to properly step over the trap
or interrupt frames, since these frames do not follow the 'normal' kernel
frame layout (not quite normal, because we deviate from the ABI-mandated
backtrace interface in the kernel).

Are you only interested in the kernel side of things ? Usermode with the
signal delivery/sigreturn(2), ucontext(2) and ptrace(2) could be also
the interesting situation to consider.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130802/770f633b/attachment.sig>