From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25093 invoked by alias); 1 May 2013 22:13:25 -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 25074 invoked by uid 89); 1 May 2013 22:13:25 -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-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 01 May 2013 22:13:24 +0000 Received: by mail-yh0-f45.google.com with SMTP id f43so373340yha.18 for ; Wed, 01 May 2013 15:13:22 -0700 (PDT) X-Received: by 10.236.1.233 with SMTP id 69mr3139634yhd.127.1367446402553; Wed, 01 May 2013 15:13:22 -0700 (PDT) Received: from dhcp-191-132.bos.redhat.com ([66.187.233.206]) by mx.google.com with ESMTPSA id c67sm8310806yhh.16.2013.05.01.15.13.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 15:13:12 -0700 (PDT) Message-ID: <51819377.3040403@gmail.com> Date: Wed, 01 May 2013 22:13: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 1/5] __fdelt_chk: Removed range check References: <1365900451-19026-1-git-send-email-kosaki.motohiro@gmail.com> <1365900451-19026-2-git-send-email-kosaki.motohiro@gmail.com> <51807D13.9090706@redhat.com> <51812A69.6000004@redhat.com> In-Reply-To: <51812A69.6000004@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00021.txt.bz2 >>> That means that we would have to recompile all of the >>> applications again in order to get checking again using >>> the new symbols proposed in PATCH #2? >> >> Right. Because, unfortunately, __fdelt_chk() doesn't have >> buffer size argument, so we can't implement buffer overflow >> checks on top of this interface. >> >> Then, I made new __fdelt_buffer_chk() function at patch #2. >> >> The rest problem is, how should we treat old interfaces? From >> point of Ubuntu and OpenSUSE view, it should be disable, at least, >> by default. Otherwise all applications need to recompile for disabling. >> >> >>> This is not sufficiently conservative. We want it the other >>> way around. A simple recompile of ruby should result in >>> a ruby that no longer needs to disable _FORTIFY_SOURCE >>> to work around FD_SETSIZE checks. >> >> If anyone have an alternative and better implementation idea, that's >> welcome. I definitely agree this is ideal result. > > I don't think we want to disable the check. > > We added it for good reasons and it matches POSIX behaviour. > > At the end of the day we implement POSIX behaviour by default. Could you clarify me my two questionsn? 1) If not disabling, Ubuntu/OpenSUSE need to recompile ALL of affected packages. Do you suggest to recompile all of them? Dear Ubuntu and OpenSUSE guys, please tell me your opinion. This patch doesn't affect Fedora/RHEL/Debian. So I want to know which is close to your desire. 2) I think my code correctly catch buffer overflow of posix codes too. Do you disagree it? In the other words, what kind of application wants to static checks? > Ruby has already worked around this by disabling _FORTIFY_SOURCE > in their code to avoid the assert. Right. I don't mind ruby case. > What we want to do is prevent them from needing to disable > *ALL* of _FORTIFY_SOURCE and provide a macro that allows them > to have finer grained control over the checks that apply to their > code. It can. but I want to understand which is better and why before to do.