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

[Konstantin Belousov]

On Fri, Aug 02, 2013 at 09:31:33AM -0600, Ian Lepore wrote:
> On Fri, 2013-08-02 at 19:08 +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.
> > 
> > Thanks,
> > Piyus
> 
> For the ARM architectures which use Restartable Atomic Sequences (RAS)
> to implement atomic operations, examining the value of the saved PC and
> possibly modifying it is how RAS works.  See the PUSHFRAMEINSVC macro in
> sys/arm/include/asmacros.h.  
> 
> In  a nutshell, the RAS code works by having userland code store the
> begin/end addresses of a small block of code that must be executed to
> completion without interruption to be correct.  If an exception or
> interrupt happens while the PC is in that range, the exception-entry
> code implemented by PUSHFRAMEINSVC modifies the saved PC so that on
> return to userland, execution resumes at the beginning of the atomic
> sequence.

This reminds of me the following MIPS code:
http://svnweb.freebsd.org/base?view=revision&revision=226517
-------------- 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/a13a9123/attachment.sig>