Date: Fri, 2 Aug 2013 15:04:05 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Piyus Kedia <piyuskedia@gmail.com> Cc: Sorav Bansal <sbansal@cse.iitd.ernet.in>, freebsd-arch@freebsd.org Subject: Re: Fwd: Use of the PC value in interrupt/exception handlers Message-ID: <20130802120405.GY4972@kib.kiev.ua> In-Reply-To: <CAFqkpAY1yBrHfutanF=h7Ke=jVCV95Rzg397okhKw6JYQ_PgUA@mail.gmail.com> References: <CA%2BmWYFvbcRc=Hh1B2OFvadkJWFmwCXF-%2BBF2zzk7ZeO8YF=B9A@mail.gmail.com> <CAFqkpAY1yBrHfutanF=h7Ke=jVCV95Rzg397okhKw6JYQ_PgUA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--64C3cv1XTIf1+2px Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 02, 2013 at 07:08:08PM +0900, Piyus Kedia wrote: > Dear all, >=20 > 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). >=20 > 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 f= or > returning from interrupt, or for reading contents at that PC address (e.g= =2E, > to decode the instruction at current PC). It would be unsafe if the value > of the address itself is meaningful to the handler. >=20 > 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. --64C3cv1XTIf1+2px Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR+6A1AAoJEJDCuSvBvK1BGw8P/AtUM1aWnDviNAUeaY658SJu uuo8W0eYXoTLgTe4vHxI5N/vF0OA28N97pPHrK0+2ns9JrlXxdszk9qLGUwAtOL7 VOff3qwxJdw1ahflvyCDuwFVp9BUYju/VFLwhBzNtXUsc0+Iv0x0NrkcZ0aZU9ax tD+x3wxic/qOM/M6yHcFs1r4Ts27ZHarQtCjfJckCIWI4+2RPLeT3J7g8zsauy4j lUpeqBUmRBASOg7pD3FDTWYx/M87GlPpwQS8lLrbPnwnEoAimyE3lDkh4yq/tywR aI63ejn9q/1Qo4FAQ04GRa3QzpaofKVjiRSdv97zuZgyHdz5knt+PpfFu3qq4B/A ws89nOl3Lrxb1jwDzprOUg48U/jLCAc+ROayIT0x7pl8gz7ibu7uo/olX65y/qO8 ty4/cnGLO5QoJjE4OmQ16hXJN2GqJFf+CuAY8gp6o7YvDbNAnsUr+ff0N6VydrV+ yxgIGPzuS+hipmN6IMjlBLoxjEKM1YmgH9ZKHnl+XZnMpXkEvb0TEIs+6LfBVkwH /4ayhD7GSSY77OLpwPqv+999VuszW2JHEv5DiY37s9TH2yeLdKIlTjZ/V0taM0hU GNkarRHpN/e5Tj/PenUceyZ35u4l2cxc+2p+2ZxjST+IesolinIz4z2MSyMFwxZQ uNAX/sIGtAubtTbVC23H =vHVz -----END PGP SIGNATURE----- --64C3cv1XTIf1+2px--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130802120405.GY4972>