From owner-freebsd-arch@FreeBSD.ORG Fri Apr 17 13:46:38 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEF142B7 for ; Fri, 17 Apr 2015 13:46:38 +0000 (UTC) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91DFC324 for ; Fri, 17 Apr 2015 13:46:38 +0000 (UTC) Received: by pabsx10 with SMTP id sx10so125863261pab.3 for ; Fri, 17 Apr 2015 06:46:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=bQRn7Kzz/+Fc2XPUxREtdSr61KWHhNExGdUjaSmwvcg=; b=g0xyfe7om5ZqVrG/EQD4jfG2M3hvFKdK7aFumhNzZwYV0DoTFeg0zZwpYYftndpGhr 6598S0cI22tWddtbrJOZGo26NjCihnSKoii6Y3Wm2dDG6PzcR4x73eEDCjyw6VPhKAdw sXs5meVA0ugErXgb2Cxi/eeQvDu1IGGHOpYFSkCIUbZdbGrxi3z1EAYLQk+ih1L4eVim tR+o3HJKUuIj+iXCfMwypsXhx1xb+bPk9T1WsHpRtaw12aDzWab8lEvlvIx7ld2LafIx M9KiBATr9b7YCUIuAKCgqV/Ut0lRP0Atv2O9UI/zJCf1hxeHLa3qZh6uLvg6S9IT+3jJ pT9w== X-Gm-Message-State: ALoCoQkPrxA19avuM0rBa1JL/BXs1qtEy6ChXpECs2fXZ57S/zAGHag+GbyuxkhAHpsTI4BsCU+Z X-Received: by 10.70.53.40 with SMTP id y8mr5668721pdo.61.1429278392701; Fri, 17 Apr 2015 06:46:32 -0700 (PDT) Received: from [10.64.24.57] ([69.53.236.236]) by mx.google.com with ESMTPSA id do6sm10244706pdb.72.2015.04.17.06.46.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Apr 2015 06:46:32 -0700 (PDT) Sender: Warner Losh Subject: Re: Situations about PC values in kernel data segments Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C4A5E184-8E8A-49AF-A629-C6F22D6BC994"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: <20150417134348.GR2390@kib.kiev.ua> Date: Fri, 17 Apr 2015 07:46:29 -0600 Cc: John Baldwin , Yue Chen , freebsd-arch@freebsd.org Message-Id: <53A884B1-3F07-40EE-BFBB-16EBC39DAF7A@bsdimp.com> References: <6048769.xVxqkDkTGK@ralph.baldwin.cx> <20150417134348.GR2390@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 13:46:38 -0000 --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 = 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--