From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu4ML-0007cT-7i for qemu-devel@nongnu.org; Wed, 04 Nov 2015 15:08:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zu4MG-0002Zs-7x for qemu-devel@nongnu.org; Wed, 04 Nov 2015 15:08:41 -0500 Received: from relay68.bu.edu ([128.197.228.148]:40475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu4MG-0002Zl-4l for qemu-devel@nongnu.org; Wed, 04 Nov 2015 15:08:36 -0500 Received: from BU-AUTH (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by relay68.bu.edu (8.14.3/8.13.8) with ESMTP id tA4K7p2E002853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Nov 2015 15:07:51 -0500 From: "Jhong Chung, Juan" Message-ID: <563A6597.3040907@bu.edu> Date: Wed, 4 Nov 2015 15:07:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Implementing a Runtime Shadow Stack List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi qemu-devel, I=E2=80=99m trying to start a project and I need some guidance. I want to= =20 develop a runtime shadow stack for any binary executed under qemu=20 regardless of the guest or host architecture. This will be a proof of=20 concept for a course project. For now I don=E2=80=99t need to worry about= =20 overhead or optimization. The basic functionality that I'm trying to implement in QEMU is to to=20 save the stack pointer when I enter a function and when a function=20 returns, compare the current stack pointer to the saved one in case it=E2= =80=99s=20 been modified. I apologize in advance for my limited knowledge of QEMU development.=20 Newbie here. I've been reading the documentation as much as I can. What I understand is that for any binary executed in qemu, the guest=20 architecture instructions are turned into tiny code by the TCG. Tiny=20 code operations are then able to run in the host architecture. I have two ideas to implement a runtime shadow stack: 1. Modify the binary running under QEMU and add extra guest instructions=20 to save the stack pointer after =E2=80=9Ccall=E2=80=9D and add a compare = instructions=20 after =E2=80=9Cret=E2=80=9D. After that the TCG will take care of transla= te my newly=20 added instructions to tiny code and in theory they will be executed with=20 no problem in the host. Does QEMU allow modifying binaries? 2. Modify the TCG: Is it possible to modify the TCG so that when a=20 =E2=80=9Ccall=E2=80=9D instruction is encounted, it generates tiny code a= s usual, but it=20 also adds an extra function to save the stack pointer? The same idea=20 applies to when the TCG encounters a =E2=80=9Cret=E2=80=9D guest instruct= ion. I want to=20 add an additional function that compares the return address and the=20 saved stack pointer. Which approach do you think is better/easier or possible to begin with?=20 I=E2=80=99m leaning toward making changes to the TCG. My team and I will = open=20 source this project. Any pointers are appreciated! Thanks! Juan Jhong-Chung