Date: Fri, 2 Aug 2013 21:40:53 +0900 From: Piyus Kedia <piyuskedia@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: Fwd: Use of the PC value in interrupt/exception handlers Message-ID: <CAFqkpAYbbH_EPNf4s=yeboXVN4Kjo_VdGX-XcLbf6csoZsx9FA@mail.gmail.com> In-Reply-To: <20130802120405.GY4972@kib.kiev.ua> References: <CA%2BmWYFvbcRc=Hh1B2OFvadkJWFmwCXF-%2BBF2zzk7ZeO8YF=B9A@mail.gmail.com> <CAFqkpAY1yBrHfutanF=h7Ke=jVCV95Rzg397okhKw6JYQ_PgUA@mail.gmail.com> <20130802120405.GY4972@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks, that helped a lot. On Fri, Aug 2, 2013 at 9:04 PM, Konstantin Belousov <kostikbel@gmail.com>wrote: > 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFqkpAYbbH_EPNf4s=yeboXVN4Kjo_VdGX-XcLbf6csoZsx9FA>