From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14859 invoked by alias); 1 May 2013 20:32:03 -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 14812 invoked by uid 89); 1 May 2013 20:32:02 -0000 X-Spam-SWARE-Status: No, score=-3.8 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-ye0-f173.google.com (HELO mail-ye0-f173.google.com) (209.85.213.173) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 01 May 2013 20:32:01 +0000 Received: by mail-ye0-f173.google.com with SMTP id l8so336242yen.4 for ; Wed, 01 May 2013 13:32:00 -0700 (PDT) X-Received: by 10.236.97.4 with SMTP id s4mr2845402yhf.151.1367440320132; Wed, 01 May 2013 13:32:00 -0700 (PDT) Received: from dhcp-191-132.bos.redhat.com ([66.187.233.206]) by mx.google.com with ESMTPSA id p31sm7749061yhm.10.2013.05.01.13.31.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 13:31:56 -0700 (PDT) Message-ID: <51817BBB.5010104@gmail.com> Date: Wed, 01 May 2013 20:32:00 -0000 From: KOSAKI Motohiro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carlos O'Donell CC: KOSAKI Motohiro , 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> <518129C7.2020808@redhat.com> In-Reply-To: <518129C7.2020808@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00020.txt.bz2 >>> 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. > > Then we need a flag, and ruby needs to use the flag to disable the > check on Linux. > > The fundamental truth is that glibc implements POSIX, not "Linux." > And in POSIX there is a limit of FD_SETSIZE. > > The default checking should be for POSIX. > > We should provide a way to disable _FORTIFY_SOURCE checks that > are POSIX-only. > > I still think your current macro is *better* because if __bos0 > works then you have a dynamic check that is better than a static > check. > > Thus the final solution is a combination of your new __bos0 > changes and a flag to disable the check in the event that __bos0 > fails. > > What do you think? Hmmm.... I'm puzzuled why you started to talk about ruby again. In ruby case, recompilation and flag are ok. That's no problem. But, as we've alread seen, several other software also uses the same technique. and if not disable, Ubuntu need to recompile all of their packages. Do you suggest to recompile all? Moreover, IMHO fallbacking static check is completely useless because compiler always can know the exact buffer size when using fd_set on stack. That's easy task to distingush static array size form point of compiler view. In the other hands, if compipler need to fall back, the buffer was allocated from heap in 99% case. and when using buffers allocated from heap, the size is larger than 1024 in almost all case. Then evetually, static check fallbacks makes false positive aborting in almost all case. Do you disagree? I guess my conservative and your conservative are slightly different. My conservative meant not to make false positive aborting. Your conservative seems preserve old behavior as far as possible. In general, I agree with you. but in this case, I don't think __bos0() fails to preserve to detect wrong FD_SET usage for buffers on stack. Do you have any specific (and practical) examples that my code fails to work? # I know several hacky code _can_ trick my code. but I have not found practical and real world # example. But again, It's ok from ruby POV and I'm not argue if you really want to do it.