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).