Date: Fri, 17 Apr 2015 07:46:29 -0600 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: John Baldwin <jhb@freebsd.org>, Yue Chen <ychen.contact@gmail.com>, freebsd-arch@freebsd.org Subject: Re: Situations about PC values in kernel data segments Message-ID: <53A884B1-3F07-40EE-BFBB-16EBC39DAF7A@bsdimp.com> 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
[-- Attachment #1 --] > On Apr 17, 2015, at 7:43 AM, Konstantin Belousov <kostikbel@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVMQ61AAoJEGwc0Sh9sBEAv5UP/29Efbs4GPlHNXMksdWbQbiC jVAQOLkdakb3/XByViQ7/txOZeHCLzY5+d8v+8IgKGvdnzHjgADJqcUmgYUgJ6Dl JukRhC2jar0ePemJqR9oVwTMY/rwoaNYOJBPiDZdyJdMyt4Nlt4WaT+ONg4Hp2f8 AOw+qz2yv9LrtASP45VVvJJ72ULs9LrownJFGf3rg0cdTB9ZY/Zt/n1bRtNI8l8f OwqpCzrKVC0OS29iXY/dH+UTSOeyN1Qz+OFnWaQNl0DJmhcFYH1DCzhJ4qaYqJZz NpHMPLtHS5xxagcw/TpvXgNnsMeohm5XHa/cpKtX+3jKJvO/A9ayHhJCqRlAzR/P hu/5IQRJdQtO3pDmPFFCpGWDmkBbB7FTdFhFt0/sqQeuj77IgNumpWtyW8BrXeHJ 2l5Es8kBJExhePYO/IaKJ5By8TQ0jCYAYdl0om162u4VxcaI120Gf5KGXd1rvoHs 5Tv53zw7Kh9Wnk5SqWLdeOEs141IzwVbIQQEF57YmZWkZrGxiTzZ+PsFMYrMWUP5 ZFHQ/BzcM3UkeIZxDculI0fXfwwK9owz1ohaE4OssxkRJPt3i6x0dou+DseXkIGU jUOv6AlUh1G2UyG88fqj8H/AAm+KPiS8QhqwocS77jjZKjdLphTQKdtzSc6yUQt8 j6PFpcIVJvPoWxC9laEh =GeTM -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53A884B1-3F07-40EE-BFBB-16EBC39DAF7A>