From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8050 invoked by alias); 1 May 2013 06:28:48 -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 8032 invoked by uid 89); 1 May 2013 06:28:47 -0000 X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 01 May 2013 06:28:46 +0000 Received: by mail-ob0-f173.google.com with SMTP id xn12so1100445obc.32 for ; Tue, 30 Apr 2013 23:28:45 -0700 (PDT) X-Received: by 10.182.105.227 with SMTP id gp3mr336969obb.81.1367389725372; Tue, 30 Apr 2013 23:28:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.143.67 with HTTP; Tue, 30 Apr 2013 23:28:25 -0700 (PDT) In-Reply-To: <518080FD.1090402@redhat.com> 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> From: KOSAKI Motohiro Date: Wed, 01 May 2013 06:28:00 -0000 Message-ID: Subject: Re: [PATCH 2/5] __FD_ELT: Implement correct buffer overflow check To: "Carlos O'Donell" Cc: libc-alpha , "libc-ports@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-05/txt/msg00006.txt.bz2 >> + ? __fdelt_buffer_warn(__d, __bos0 (s)) \ > > Space between function and bracket e.g. foo () not foo(). ah, ok. > >> + : __fdelt_buffer_chk(__d, __bos0 (s)) \ >> + : __d / __NFDBITS; \ > > I'm not happy that this isn't very conservative. > > If __bos0 fails should we fall back to static FD_SETSIZE checking > e.g. "__fdelt_buffer_warn (__d, FD_SETSIZE)"? > > It seems that that would be better than no checking. Hmm.. This doesn't cross my mind. All other buffer boundary checks of _FORTIFY_SOURCE fall back no checking. compiler may fails to determine a right buffer size in various reasons. at that time, I don't want to kill innocent applications. > I know why you want to fall back to no check, because that > way you don't require any kind of new flag to disable the > check in the event it triggers when you don't want it to > (when __bos0 fails). If you like flag, I'm not putting objection. but if making flag, a lot of libraries need to turn on "no check" mode because when a buffer is allocated from applications, library code can't know a buffer size at least at compile time. > 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.