From: Daniele Buono <dbuono@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
dbuono@linux.vnet.ibm.com
Subject: [PATCH v2 0/4] Add support for SafeStack
Date: Fri, 29 May 2020 16:51:18 -0400 [thread overview]
Message-ID: <20200529205122.714-1-dbuono@linux.vnet.ibm.com> (raw)
LLVM supports SafeStack instrumentation to protect against stack buffer
overflows, since version 3.7
From https://clang.llvm.org/docs/SafeStack.html:
"It works by separating the program stack into two distinct regions: the
safe stack and the unsafe stack. The safe stack stores return addresses,
register spills, and local variables that are always accessed in a safe
way, while the unsafe stack stores everything else. This separation
ensures that buffer overflows on the unsafe stack cannot be used to
overwrite anything on the safe stack."
Unfortunately, the use of two stack regions does not cope well with
QEMU's coroutines. The second stack region is not properly set up with
both ucontext and sigaltstack, so multiple coroutines end up sharing the
same memory area for the unsafe stack, causing undefined behaviors at
runtime (and most iochecks to fail).
This patch series fixes the implementation of the ucontext backend and
make sure that sigaltstack is never used if the compiler is applying
the SafeStack instrumentation. It also adds a configure flag to enable
SafeStack, and enables iotests when SafeStack is used.
Changes since v1:
- CONFIG_SAFESTACK is now set up in configure, and not in the code
- Added option for a --disable-safe-stack in configure
- Configure checks if SafeStack is enabled by default in the compiler,
and set the CONFIG_SAFESTACK accordingly
- Updated some comments in the code and the commit log
NOTE: I kept configure as Patch #3.
The reason is that the code changes will not be enabled without the
configure, making the code fully functional if only Patches #1 or #2 are
applied.
On the other hand, the configure patch will produce incorrect code if we
request SafeStack and the other patches are not applied.
Daniele Buono (4):
coroutine: support SafeStack in ucontext backend
coroutine: add check for SafeStack in sigaltstack
configure: add flags to support SafeStack
check-block: enable iotests with SafeStack
configure | 73 ++++++++++++++++++++++++++++++++++++
include/qemu/coroutine_int.h | 5 +++
tests/check-block.sh | 12 +++++-
util/coroutine-sigaltstack.c | 4 ++
util/coroutine-ucontext.c | 26 +++++++++++++
5 files changed, 119 insertions(+), 1 deletion(-)
--
2.26.2
next reply other threads:[~2020-05-29 20:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 20:51 Daniele Buono [this message]
2020-05-29 20:51 ` [PATCH v2 1/4] coroutine: support SafeStack in ucontext backend Daniele Buono
2020-05-29 20:51 ` [PATCH v2 2/4] coroutine: add check for SafeStack in sigaltstack Daniele Buono
2020-05-29 20:51 ` [PATCH v2 3/4] configure: add flags to support SafeStack Daniele Buono
2020-05-29 20:51 ` [PATCH v2 4/4] check-block: enable iotests with SafeStack Daniele Buono
2020-06-15 12:58 ` [PATCH v2 0/4] Add support for SafeStack Daniele Buono
2020-06-17 18:43 ` Stefan Hajnoczi
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=20200529205122.714-1-dbuono@linux.vnet.ibm.com \
--to=dbuono@linux.vnet.ibm.com \
--cc=berrange@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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).