Date: Mon, 20 Apr 2015 11:00:27 -0400 From: John Baldwin <jhb@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arch@freebsd.org, Yue Chen <ychen.contact@gmail.com> Subject: Re: Situations about PC values in kernel data segments Message-ID: <2177000.nIlZYR4khO@ralph.baldwin.cx> In-Reply-To: <20150417134348.GR2390@kib.kiev.ua> References: <CAKtBrB6g5fR_tvT=KwrER4_VGfYB-fF-2DWmm1vMDpZ55qb2qg@mail.gmail.com> <6048769.xVxqkDkTGK@ralph.baldwin.cx> <20150417134348.GR2390@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, April 17, 2015 04:43:48 PM Konstantin Belousov 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. It depends on the scope. If this is for a graduate research project to build a prototype to see if this is feasible, then some cavets are acceptable if they are known. One could be to disallow the bpf JIT option (I believe it is not in GENERIC)? EFI is actually fairly easily handled since the EFI memory map gives you the bounds of the executable code and you can just treat that as an additional .text segment. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2177000.nIlZYR4khO>