Situations about PC values in kernel data segments

[John Baldwin]

On Saturday, April 11, 2015 05:18:28 AM Yue Chen wrote:
> Dear all,
> 
> We are working on a project about OS security.
> We wonder in which situations the program counter (PC) value (e.g., the
> value in %RIP on x86_64, i.e, instruction address) could be in kernel
> (module) data segments (including stack, heap, etc.).
> 
> Here we mainly care about the address/value that are NOT function entry
> points since there exist a number of function pointers. Also, we only
> consider the normal cases because one can write arbitrary values into a
> variable/pointer. And we mainly consider i386, AMD64 and ARM.
> 
> Here are some situations I can think about:
> function/interrupt/exception/syscall return address on stack; switch/case
> jump table target; page fault handler (pcb_onfault on *BSD); restartable
> atomic sequences (RAS) registry; thread/process context structure like Task
> state segment (TSS), process control block (PCB) and thread control block
> (TCB); situations for debugging purposes (e.g., like those in ``segment not
> present'' exception handler).
> 
> Additionally, does any of these addresses have offset formats or special
> encodings? For example, on x86_64, we may use 32-bit RIP-relative
> (addressing) offset to represent a 64-bit full address. In glibc's
> setjmp/longjmp jmp_buf, they use a special encoding (PTR_MANGLE) for saved
> register values.

For i386 and amd64, I think all of the code that is executed does live in a
.text segment.  When pcb_onfault is used it is set to point to code in a .text
segment, not anywhere else.  Similarly, fault and exception handlers as well
as the stub for new threads/processes after fork/thread_create is in .text
as well.  There are multiple text segments present when modules are loaded
of course, but you should be able to enumerate all of those in the linker.

-- 
John Baldwin