qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Daniele Buono <dbuono@linux.vnet.ibm.com>
To: Alexander Bulekov <alxndr@bu.edu>, Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH 2/2] configure: add support for Control-Flow Integrity
Date: Thu, 2 Jul 2020 11:43:27 -0400	[thread overview]
Message-ID: <f3cf9017-3da5-d6d4-f463-3864ab1f43c6@linux.vnet.ibm.com> (raw)
In-Reply-To: <20200702133830.f3mlqli2bxtvk2z4@mozz.bu.edu>

Hey Alex!

I agree, in most cases (possibly all of them), a wrong indirect function 
call will end up with something that is catched by ASan or UBSan.
This way, however, you may catch it earlier and it may make debug easier 
(especially with --enable-cfi-debug which is printing an error with the 
calling and, most times, the called function).

UBSan does have a similar feature, -fsanitize=function, but 
unfortunately it works only on C++ code, and therefore is not good in 
the QEMU case.

And, of course, it will also be used to weed out missing functions in 
the CFI filter.

On 7/2/2020 9:38 AM, Alexander Bulekov wrote:
> Can't wait to try this out!
> 
> On 200702 1459, Paolo Bonzini wrote:
>> On 02/07/20 14:50, Daniele Buono wrote:
>>> I also wonder if this is something that could be put in the fuzzing
>>> environment. It would probably also help in finding coding error in
>>> corner cases quicker.
>>
>> Yes, fuzzing and tests/docker/test-debug should enable CFI.  Also,
>> tests/docker/test-clang should enable LTO.
>>
>> Paolo
> 
> I believe CFI is most-useful as an active defensive measure. I can't
> think of many cases where a fuzzer/test could raise a CFI alert that
> wouldn't also be caught by something like canaries, ASan or UBsan,
> though maybe I'm missing something. Maybe testing/fuzzing with CFI could
> be useful to weed out any errors due to e.g. an incomplete
> cfi-blacklist.txt
> 
> -Alex
> 


  reply	other threads:[~2020-07-02 15:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02  5:49 [PATCH 0/2] Add support for Control-Flow Integrity Daniele Buono
2020-07-02  5:49 ` [PATCH 1/2] check-block: enable iotests with cfi-icall Daniele Buono
2020-07-02  5:49 ` [PATCH 2/2] configure: add support for Control-Flow Integrity Daniele Buono
2020-07-02  9:45   ` Paolo Bonzini
2020-07-02 12:19     ` Daniele Buono
2020-07-02  9:52   ` Daniel P. Berrangé
2020-07-02 12:50     ` Daniele Buono
2020-07-02 12:59       ` Paolo Bonzini
2020-07-02 13:38         ` Alexander Bulekov
2020-07-02 15:43           ` Daniele Buono [this message]
2020-08-10 19:01             ` Daniele Buono
2020-08-10 19:39               ` Paolo Bonzini
2020-08-10 21:33                 ` Alexander Bulekov
2020-08-13 14:00                   ` Daniele Buono
2020-07-02 13:12       ` Daniel P. Berrangé
2020-07-02 15:02         ` Daniele Buono
2020-07-16 21:57     ` Daniele Buono

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=f3cf9017-3da5-d6d4-f463-3864ab1f43c6@linux.vnet.ibm.com \
    --to=dbuono@linux.vnet.ibm.com \
    --cc=alxndr@bu.edu \
    --cc=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --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).