Situations about PC values in kernel data segments

[Warner Losh]

> On Apr 17, 2015, at 7:43 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> On Fri, Apr 17, 2015 at 09:22:43AM -0400, John Baldwin wrote:
>> 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.
> 
> Wasn't bpf enhanced to compile filters to the native code, on x86 ?
> Also, what about BIOS code ? Esp. since the spread of UEFI and hope that
> our kernel starts using UEFI runtime services one day.  My point is that
> _relying_ on enumeration of the text segments for kernel and modules to
> determine all executable memory is not correct.

Yes. That ‘one day’ will be quite soon… I have patches in my patch queue
which should do the right thing.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20150417/b3e128fe/attachment.sig>