From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29024 invoked by alias); 3 May 2013 03:15: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 28977 invoked by uid 89); 3 May 2013 03:15:40 -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:39 +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 r433FbRj025095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 May 2013 23:15:37 -0400 Received: from [10.3.113.52] (ovpn-113-52.phx2.redhat.com [10.3.113.52]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r433FaJW027424; Thu, 2 May 2013 23:15:36 -0400 Message-ID: <51832BD7.1020204@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> <518129C7.2020808@redhat.com> <51817BBB.5010104@gmail.com> In-Reply-To: <51817BBB.5010104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00025.txt.bz2 On 05/01/2013 04:31 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. >> >> 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. It's just an example. > 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? Unfortunately yes, otherwise we devalue _FORTIFY_SOURCE. > 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 am worried that __bos0 will fail in a lot of cases, and yes, that will yield a false positive, however it is *better* than what we had before, and that's good. I think this is a choice the distributions made, and _FORTIFY_SOURCE makes. The application developers want Linux/BSD-style support, but _FORTIFY_SOURCE by definition adheres to the stricter standard of POSIX. I don't see a way to win other than: * Attempt dynamic check. * Attempt static check. or * Disable with flag. You are suggesting: * Attempt dynamic check. * Skip check. That devalues _FORTIFY_SOURCE. I would like to keep _FORTIFY_SOURCE as strict as possible. Let the distributions make a choice about enabling it, and give the packagers some options for loosening checks. > 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? There is some code somewhere that will cause __bos0() to fail. In that situation *I* would rather a false positive than an overflow. If you don't care about security don't compile with _FORTIFY_SOURCE? > # 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. I think your code is a better version of the existing code. Cheers, Carlos.