From patchwork Mon Jun 4 08:34:21 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Weimer X-Patchwork-Id: 162676 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id C9AC2B6FD3 for ; Mon, 4 Jun 2012 18:35:00 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1339403701; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=phFX1XKIQ/7dPXwtkK+wUNgRb9k=; b=mER1MfaofJc/Pps htZWPTdEdKTjLWaJc8OQotGBg5+TldevmX3H6eXAa8X/Q+wDUPXrtgvyuAGWTE9L afoGjot59YV/Gh2feRTLMWY2fFC68hkYnUxkmWN7znYD4713mZoWaqnFW51Ld5qB Rs4QPhbw4QpC22H992TlG/fzvpew= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=k1Osg4IqARqh4hFUJVddU4pjakWuYX4I4mPBZy9taEQY7YKLaKHFwM8XZYKRkw bO/txMkHVZpkRlRwOozmLEz7rvMl3+5h8ba+WERkB0JzlAYuEs6AvPQH5u7AJ5K3 GeHneXBaUijL1PA26rl7jaXtrv7yeLDTNTwjhYQJY+7Hw=; Received: (qmail 20946 invoked by alias); 4 Jun 2012 08:34:52 -0000 Received: (qmail 20309 invoked by uid 22791); 4 Jun 2012 08:34:48 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 Jun 2012 08:34:31 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q548YUZb001230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Jun 2012 04:34:30 -0400 Received: from dhcp-5-241.str.redhat.com (ovpn-116-64.ams2.redhat.com [10.36.116.64]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q548YMVN019715 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 04:34:29 -0400 Message-ID: <4FCC730D.4000803@redhat.com> Date: Mon, 04 Jun 2012 10:34:21 +0200 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jakub Jelinek CC: gcc-patches@gcc.gnu.org Subject: Re: [Doc] Add caveat to __builtin_object_size References: <4FCC6EA7.4060507@redhat.com> <20120604082334.GW24904@tucnak.redhat.com> In-Reply-To: <20120604082334.GW24904@tucnak.redhat.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 06/04/2012 10:23 AM, Jakub Jelinek wrote: > On Mon, Jun 04, 2012 at 10:15:35AM +0200, Florian Weimer wrote: >> --- gcc/doc/extend.texi (revision 187951) >> +++ gcc/doc/extend.texi (working copy) >> @@ -7376,8 +7376,15 @@ >> @findex __builtin___vfprintf_chk >> >> GCC implements a limited buffer overflow protection mechanism >> -that can prevent some buffer overflow attacks. >> +that can prevent some buffer overflow attacks. GNU libc uses it >> +in the implementation of the @code{_FORTIFY_SOURCE} functionality. >> >> +This protection mechanism is only a last resort. As a programmer, you >> +must not rely on its presence, but use explicit buffer length checks >> +to avoid buffer overflows. GCC may not be able to determine buffer >> +sizes accurately, and the accuracy depends on compiler version and >> +optimization level (currently, at least @option{-O2} is required). > > That isn't true, at -O1 or -Os it should work just fine too, and > to some extent on the compiler side even at -O0. Fold needs to run. Without it, __builtin_object_size constantly returns (size_t)-1. The documentation doesn't say which optimization level enables fold, so I have to guess. -O0 apparently doesn't. > So I'd just replace optimization level.*\. with compiler options. Okay. What about this? Index: gcc/doc/extend.texi =================================================================== --- gcc/doc/extend.texi (revision 187951) +++ gcc/doc/extend.texi (working copy) @@ -7376,8 +7376,15 @@ @findex __builtin___vfprintf_chk GCC implements a limited buffer overflow protection mechanism -that can prevent some buffer overflow attacks. +that can prevent some buffer overflow attacks. GNU libc uses it +in the implementation of the @code{_FORTIFY_SOURCE} functionality. +This protection mechanism is only a last resort. As a programmer, you +must not rely on its presence, but use explicit buffer length checks +to avoid buffer overflows. GCC may not be able to determine buffer +sizes accurately, and the accuracy depends on compiler version and +options. + @deftypefn {Built-in Function} {size_t} __builtin_object_size (void * @var{ptr}, int @var{type}) is a built-in construct that returns a constant number of bytes from @var{ptr} to the end of the object @var{ptr} pointer points to