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
--Apple-Mail=_C4A5E184-8E8A-49AF-A629-C6F22D6BC994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 17, 2015, at 7:43 AM, Konstantin Belousov <kostikbel@gmail.com> = wrote: >=20 > 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, >>>=20 >>> 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.). >>>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> 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. >>=20 >> 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. >=20 > 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 =E2=80=98one day=E2=80=99 will be quite soon=E2=80=A6 I have = patches in my patch queue which should do the right thing. Warner --Apple-Mail=_C4A5E184-8E8A-49AF-A629-C6F22D6BC994 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----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----- --Apple-Mail=_C4A5E184-8E8A-49AF-A629-C6F22D6BC994--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53A884B1-3F07-40EE-BFBB-16EBC39DAF7A>