From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-73729-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 50024 invoked by alias); 5 Oct 2016 14:27:06 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 50009 invoked by uid 89); 5 Oct 2016 14:27:05 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Marks, Maxim, maxim, San
X-HELO: mx1.redhat.com
Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the
 same time.
To: Maxim Ostapenko <m.ostapenko@samsung.com>,
        GNU C Library <libc-alpha@sourceware.org>
References: <57CDAB08.8060601@samsung.com>
Cc: Kostya Serebryany <kcc@google.com>, Yuri Gribov <tetra2005@gmail.com>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <93b470fc-0a1f-684f-065a-109ee6534f12@redhat.com>
Date: Wed, 05 Oct 2016 14:27:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <57CDAB08.8060601@samsung.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SW-Source: 2016-10/txt/msg00089.txt.bz2

On 09/05/2016 07:27 PM, Maxim Ostapenko wrote:
> Although fortify is good thing as it (and it's enabled by default on
> some major distros e.g. Ubuntu and Gentoo), people still complain about
> {A, M}San vs fortify interaction, see e.g.
> https://github.com/google/sanitizers/issues/689. One possible solution
> would be to extend {A, M}San to support foo_chk() functions, but this
> would increase the complexity of sanitizer tools with quite small benefit.

I'm not sure if there is a small benefit.  Based on Mark's feedback on 
valgrind's capabilities compared to source fortification, I ran an 
experiment.

Consider this example program:

#include <stdlib.h>
#include <string.h>

struct foo {
   int a;
   char b[4];
   void *c;
};

int
main (int argc, char **argv)
{
   struct foo *p = malloc (sizeof (*p));
   strcpy (p->b, argv[1]);
   asm volatile ("" ::: "memory");
   free (p);
}

Compiled with -D_FORTIFY_SOURCE=2, passing a four-character string yields:

$ ./a.out aaaa
*** buffer overflow detected ***: ./a.out terminated
[…]

But compiling with clang 3.8 and -fsanitize=address (without source 
fortification), I can pass a longer string before Address Sanitizer 
detects the overflow:

$ ./a.out aaaaaaaaaaa
$ ./a.out aaaaaaaaaaaa
=================================================================
==21921==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60200000f000 at pc 0x000000488d77 bp 0x7ffe8eb00d50 sp 0x7ffe8eb00500

Depending on the application, intra-object overflows can be quite 
relevant.  Is this perhaps a sufficient case for Address Sanitizer using 
this data as well?

Thanks,
Florian