qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Jhong Chung, Juan" <jfjhong@bu.edu>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Implementing a Runtime Shadow Stack
Date: Wed, 4 Nov 2015 15:07:51 -0500	[thread overview]
Message-ID: <563A6597.3040907@bu.edu> (raw)

Hi qemu-devel,

I’m trying to start a project and I need some guidance. I want to 
develop a runtime shadow stack for any binary executed under qemu 
regardless of the guest or host architecture. This will be a proof of 
concept for a course project. For now I don’t need to worry about 
overhead or optimization.

The basic functionality that I'm trying to implement in QEMU is to to 
save the stack pointer when I enter a function and when a function 
returns, compare the current stack pointer to the saved one in case it’s 
been modified.

I apologize in advance for my limited knowledge of QEMU development. 
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 
architecture instructions are turned into tiny code by the TCG. Tiny 
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 
to save the stack pointer after “call” and add a compare instructions 
after “ret”. After that the TCG will take care of translate my newly 
added instructions to tiny code and in theory they will be executed with 
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 
“call” instruction is encounted, it generates tiny code as usual, but it 
also adds an extra function to save the stack pointer? The same idea 
applies to when the TCG encounters a “ret” guest instruction. I want to 
add an additional function that compares the return address and the 
saved stack pointer.

Which approach do you think is better/easier or possible to begin with? 
I’m leaning toward making changes to the TCG. My team and I will open 
source this project. Any pointers are appreciated!

Thanks!

Juan Jhong-Chung

                 reply	other threads:[~2015-11-04 20:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563A6597.3040907@bu.edu \
    --to=jfjhong@bu.edu \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).