From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29447 invoked by alias); 3 May 2013 03:15:50 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 29402 invoked by uid 89); 3 May 2013 03:15:50 -0000 X-Spam-SWARE-Status: No, score=-9.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 03 May 2013 03:15:49 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r433Flor016760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 May 2013 23:15:47 -0400 Received: from [10.3.113.52] (ovpn-113-52.phx2.redhat.com [10.3.113.52]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r433FjfY016941; Thu, 2 May 2013 23:15:45 -0400 Message-ID: <51832BE1.8020303@redhat.com> Date: Fri, 03 May 2013 03:15:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: KOSAKI Motohiro CC: libc-alpha , "libc-ports@sourceware.org" Subject: Re: [PATCH 2/5] __FD_ELT: Implement correct buffer overflow check References: <1365900451-19026-1-git-send-email-kosaki.motohiro@gmail.com> <1365900451-19026-3-git-send-email-kosaki.motohiro@gmail.com> <518080FD.1090402@redhat.com> <518176FC.5030906@gmail.com> In-Reply-To: <518176FC.5030906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00026.txt.bz2 On 05/01/2013 04:11 PM, KOSAKI Motohiro wrote: >>> Does compiling ruby (or similar code) with this header >>> result in calls to __fdelt_buffer_warn or __fdelt_buffer_chk? >> >> Unfortunately, No. __builtin_object_size() require compiler know the >> buffer size. >> In the other words, it doesn't work if an allocate function and >> FD_{SET,CLR} functions >> doesn't exist in the same place. This is the same limitation with >> other string buffer >> overflow checks. > > I inspected several other project codes. Thank you very much for looking at these examples. They are quite informative. [snip] > Summary: alomost software only need to add alloc_size() annotation to xmalloc() or > similar in almost case. but there are several exceptions. some software have a complicated > fd size management and can't use __builtin_object_size(). but that's ok. In this case, the > software correctly expand buffers by realloc() or similar, so there is no chance to happen > buffer overflow. So with your patch we enhance the number of cases that the check is correct by using __bos0, and that's forward progress. I know that it is less progress than you would like, but it is good progress. We keep _FORTIFY_SOURCE working usefully, even though it still yields false positives. The question as always with these checks is: Do you prefer false positives or buffer overflows? What's more harmful? The ecosystem thinking glibc and the tools are "wrong" or buffer overflows leading to security issues? As a conservative project, and given the goal of _FORTIFY_SOURCE, it seems like we have to leave the existing checks in place. Cheers, Carlos.