From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12623 Path: news.gmane.org!.POSTED!not-for-mail From: "dgutson ." Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: #define __MUSL__ in features.h Date: Thu, 15 Mar 2018 16:42:41 -0300 Message-ID: References: <20180315183939.GI1436@brightrain.aerifal.cx> <20180315185358.GJ1436@brightrain.aerifal.cx> <20180315193747.GL1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1227f8e9803f056778b193" X-Trace: blaine.gmane.org 1521142873 23167 195.159.176.226 (15 Mar 2018 19:41:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 19:41:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12637-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 20:41:09 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ewYkO-0005wR-ON for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 20:41:08 +0100 Original-Received: (qmail 5436 invoked by uid 550); 15 Mar 2018 19:43:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5231 invoked from network); 15 Mar 2018 19:42:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=S43ZuAMsENpna9bm2ALHz5egxizTiKKUK+Dr5mVG1zY=; b=lmrj3NJTHaFkgS1fneLXQm7J32uuGQygl8WJ4b/v2DKY2bXvHQoENO7jczue1/ziWt artHRVLzLHa4u/IvYva/yYabpWl5HZTF1z6qifGVLZXZEXSzrlFcehEMoIs1i8mD6YM1 7pLS3fEFuWTNPytG2ZV2m06VQmYNhXEce1QRNPahTrk0j73ZZsFxiKb7hdggdB9ofmqJ sATZhKICbBE+b5g3P1S5XmM7A+M6dfG8Oo8ccyMNSRKojwr2wBF3lO1Z59wXxrVwIvoZ ZLmcGfWF+2XZr7kQEL4E7QSu5Yq7KRxLCnZP7dAcuaGMFQoRz+E4dvwSb1lv2ACIZwFc KXTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=S43ZuAMsENpna9bm2ALHz5egxizTiKKUK+Dr5mVG1zY=; b=Yf2/pzEa+824uJkkeNrJqWeDdsTxHctxx27jQczaKi755lS6EASi/J9fU5+UX6fvka ECdPV1rIK2M4m7OWpUf6k9UzS9CPGeDjsvwfx1Ln9QYpt/rhKkBt4+AuRD6yrEqfldRF 7Rcujhw8uSLh88PMXXVKpkU4IoNA7UgFpfIH7ZGZ3dQZt6ONjhHiWyAPX2Tt5twM5P+6 JCLAup89Za1CtfWXEOZQtSJs6n+dK4tq4zTucMhCGnskTtX9jy++AFw4bvyzSsC/YV2d boM1WYFty3WVSUcdBWyTqYwsRnwlhmYDSlgVYDeVp1lQiU/ZQm/udwHF07BBPgY8Et5e Bsvw== X-Gm-Message-State: AElRT7GAUTb/fVLHdxgzZubwuqU9US+Rp/EuKIRrSalxCxSzY9qMS2Bw nJhQ5eLffNfOoTeb939IRJZ2kLrsxtAPSE6X+0Y= X-Google-Smtp-Source: AG47ELsmraAoxmVaHHgvAmAIJTyse/Lu59se0qMM2DTt0GwemXspBh+/BEUcmhPxQx8gTYT8IvdppFB4qrhJGc0SzHw= X-Received: by 10.237.38.2 with SMTP id z2mr8069588qtc.44.1521142962157; Thu, 15 Mar 2018 12:42:42 -0700 (PDT) In-Reply-To: <20180315193747.GL1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12623 Archived-At: --94eb2c1227f8e9803f056778b193 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2018 at 4:37 PM, Rich Felker wrote: > On Thu, Mar 15, 2018 at 04:00:37PM -0300, dgutson . wrote: > > On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker wrote: > > > > > On Thu, Mar 15, 2018 at 03:48:32PM -0300, Martin Galvan wrote: > > > > 2018-03-15 15:39 GMT-03:00 Rich Felker : > > > > >> (e.g. the FD* issue reported by Martin Galvan). > > > > > > > > > > That's not a bug. It's compiler warnings being wrongly produced > for a > > > > > system header, probably because someone added -I/usr/include or > > > > > similar (normally GCC suppresses these). > > > > > > > > I'm certain we didn't add -I/usr/include or something similar. Coul= d > > > > you test this yourself to confirm it's not a bug? > > > > > > In any case it's not a bug in musl. The code is perfectly valid C. If > > > the compiler is producing a warning for it, either ignore it or ask > > > the compiler to stop. > > > > > > > The compiler warnings aren't being wrongly produced. musl will inde= ed > > > > perform a signed-to-unsigned conversion here. > > > > > > Because that's how the C language works. > > > > > > > it is a potential vulnerability: > > https://cwe.mitre.org/data/definitions/195.html > > https://wiki.sei.cmu.edu/confluence/display/c/INT31-C.+ > Ensure+that+integer+conversions+do+not+result+in+ > lost+or+misinterpreted+data > > https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+ > Ensure+that+unsigned+integer+operations+do+not+wrap > > > > Can you ensure it is rocksolid and the signed integer will NEVER be a > > negative value? > > FD_* have undefined behavior if the argument is outside the range of > FD_SETSIZE. We could trap this (and if you use fortify headers, they > do) but doing so breaks applications that wrongly allocate larger > space for fd_set buffers for the sake of intentionally using larger fd > values than are possible with the select API. > > The behavior of the code with or without the cast to unsigned added is > _exactly the same_. There is no bug here that is fixed by the proposed > patch. The warning is telling you that, if you don't understand how > You are talking to the wrong guy. I did not propose the patch and I did not propose the cast. > integer promotions work in C, the code might not do what you expected > it to do. The fact that you seem to think adding a cast "fixes a bug" > is demonstrating how harmful the whole cult around compiler warnings > is: it's not about using them as hints to check your code and make > sure it's doing what you want, but instead about making the warning go > away without actually changing anything. > > Rich > --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck? --94eb2c1227f8e9803f056778b193 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 15, 2018 at 4:37 PM, Rich Felker <dalias@libc.org> wrote:
On Thu, Mar = 15, 2018 at 04:00:37PM -0300, dgutson . wrote:
> On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker <dalias@libc.org> wrote:
>
> > On Thu, Mar 15, 2018 at 03:48:32PM -0300, Martin Galvan wrote: > > > 2018-03-15 15:39 GMT-03:00 Rich Felker <dalias@libc.org>:
> > > >> (e.g. the FD* issue reported by Martin Galvan).
> > > >
> > > > That's not a bug. It's compiler warnings being = wrongly produced for a
> > > > system header, probably because someone added -I/usr/in= clude or
> > > > similar (normally GCC suppresses these).
> > >
> > > I'm certain we didn't add -I/usr/include or somethin= g similar. Could
> > > you test this yourself to confirm it's not a bug?
> >
> > In any case it's not a bug in musl. The code is perfectly val= id C. If
> > the compiler is producing a warning for it, either ignore it or a= sk
> > the compiler to stop.
> >
> > > The compiler warnings aren't being wrongly produced. mus= l will indeed
> > > perform a signed-to-unsigned conversion here.
> >
> > Because that's how the C language works.
> >
>
> it is a potential vulnerability:
> https://cwe.mitre.org/data/definitions/195.= html
> https://wiki.sei.cmu.edu/confluenc= e/display/c/INT31-C.+Ensure+that+integer+conversions+do+not+resul= t+in+lost+or+misinterpreted+data
> https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+Ensure+that+unsigned+integer+operations+do+not+wrap
>
> Can you ensure it is rocksolid and the signed integer will NEVER be a<= br> > negative value?

FD_* have undefined behavior if the argument is outside the range of=
FD_SETSIZE. We could trap this (and if you use fortify headers, they
do) but doing so breaks applications that wrongly allocate larger
space for fd_set buffers for the sake of intentionally using larger fd
values than are possible with the select API.

The behavior of the code with or without the cast to unsigned added is
_exactly the same_. There is no bug here that is fixed by the proposed
patch. The warning is telling you that, if you don't understand how
=

You are talking to the wrong guy. I did no= t propose the patch and I did not propose the cast.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> integer promotions work in C, the code might not do what you expected
it to do. The fact that you seem to think adding a cast "fixes a bug&q= uot;
=C2=A0
is demonstrating how harmful the whole cult around compiler warnings
is: it's not about using them as hints to check your code and make
sure it's doing what you want, but instead about making the warning go<= br> away without actually changing anything.

Rich



--
Who=E2= =80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
= Who=E2=80=99d never, ever start an argument?
Who never shows a bit of te= mperament?
Who's never wrong but always right?
Who'd never dr= eam of starting a fight?
Who get stuck with all the bad luck?
--94eb2c1227f8e9803f056778b193--