From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12618 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:13:44 -0300 Message-ID: References: <20180315183939.GI1436@brightrain.aerifal.cx> <20180315185358.GJ1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114c519465628b0567784a10" X-Trace: blaine.gmane.org 1521141232 7139 195.159.176.226 (15 Mar 2018 19:13:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 19:13:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12632-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 20:13:48 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 1ewYJw-0001ks-BR for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 20:13:48 +0100 Original-Received: (qmail 28060 invoked by uid 550); 15 Mar 2018 19:14:05 -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 27885 invoked from network); 15 Mar 2018 19:13:57 -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=tySqCLVIqYiu1jLdE2Pyv5AiD6Ob4M2Iv+7ftnLak8Q=; b=DYkdqAiJbSaa/oOBZuC6XgyoZrYC+l5qt64EiT/KCJNBZU4T2CtAHhzAfXqywwnUpW 8gop9mC0DfmFiwa5uCp+x3eqrM68XCX/z2S9V4OjZtPaRHeJz8+UQiTae0J3su1tSzR1 AFQDX8cb2TWyoY3LpaYOalldQbn6XZ13NTBch1s39EfoRG3wbJKUH/eBcwy5Aag9KGR+ /+D5A4FmZ4NsZrfSrWVQBAPV5RpBqBOQNi+WzVg80JQ05bVL5EJLk6zWnTgkUjfEoCA8 NeadLNRQ0CmipltAGZIo5WSbcNrdvFkWYl3b/yBHsl6WriRvUpTe3LQ0MhKKcnnyvNi1 gU4A== 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=tySqCLVIqYiu1jLdE2Pyv5AiD6Ob4M2Iv+7ftnLak8Q=; b=mWIjVT0tE/Z9jUNLN3kBbFccXrXtB4uVQgqTt2pPEqA+VS0C3dwHRK0LUP7nKfVbl2 vx5fHcP4zO7at6xkD6gF0yfhscqllxhAkrFh8RqJgZ5M5vouog1xPepEx0RHR6qo4uoE 6RkQcY4ySkVHttM4YixI5sEKv1BD1hEK+CpaHfBJIAnzXXETty0+cFPX/ZkK32Hhehm1 zvEEdFiuYn8kFbM3bTH9MvcZkfPsVffjWroj2D9npib8v/empT9vmJdNfcLRpuQ6byKp 0JBmJloNgZsbu0DJBVoMJbfTGFJw7MXGkNeyIMMNKgpexMnNu4pmwv8+hjAU1aHprcEx qFEA== X-Gm-Message-State: AElRT7F96SxWuER90KxsW+ChL75ocJdDwOtPnK2HoJ69ynd50QIgTziS htb5+gsk2uudBkvaaTTR3OnC2AtUiNZK8Kh230o= X-Google-Smtp-Source: AG47ELuS3Z13oc4oelBw62BGYVomMnkZgejGa/fjGe02Sv3FckWLTPE4jK1g7GVpc3ZdSxePTtY2XPUYc6jlFn8XwvU= X-Received: by 10.55.6.140 with SMTP id 134mr11111929qkg.232.1521141225446; Thu, 15 Mar 2018 12:13:45 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12618 Archived-At: --001a114c519465628b0567784a10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2018 at 4:00 PM, 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. 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 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 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/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 > Just to add: the code doesn't not comply with MISRA 2004 because it violates 6.10.3. IOW, at least this issue turns musl MISRA non-compliant. > > > Can you ensure it is rocksolid and the signed integer will NEVER be a > negative value? > > >> >> > > The musl policy regarding not having a macro like __MUSL__ is doing >> > > exactly what it's intended to do: encouraging developers and package >> > > maintainers to come to us (or investigate on their own) and fix the >> > > underlying portability problems (and sometimes musl bugs) rather tha= n >> > > writing hacks to a specific version of musl that will be wrong a few >> > > versions later. >> > >> > So whenever we find a bug on musl we should just stop all our >> > development until you've fixed the bug? >> >> No. As noted above, if you need to support systems that might have bug >> X, you write a test (configure-time or run-time as appropriate) to >> detect bug X and handle it. >> >> 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 temperament? > Who's never wrong but always right? > Who'd never dream of starting a fight? > Who get stuck with all the bad luck? > --=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? --001a114c519465628b0567784a10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 15, 2018 at 4:00 PM, dgutson . <danielgutson@gmail.co= m> wrote:
=

On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker <dalias@libc.org><= /span> wrote:
On Thu, Mar 15, 2018 at 03:48:32PM -030= 0, 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 pr= oduced 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.= 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 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 ind= eed
> perform a signed-to-unsigned conversion here.

Because that's how the C language works.
it is a potential vulnerability:
<= /div>

Just to add: the code doesn't not= comply with MISRA 2004 because it violates 6.10.3. IOW, at least this issu= e turns musl MISRA non-compliant.
=C2=A0


Can you ensure it is rocksolid= and the signed integer will NEVER be a negative value?
=C2=A0

> > The musl policy regarding not having a macro like __MUSL__ is doi= ng
> > exactly what it's intended to do: encouraging developers and = package
> > maintainers to come to us (or investigate on their own) and fix t= he
> > underlying portability problems (and sometimes musl bugs) rather = than
> > writing hacks to a specific version of musl that will be wrong a = few
> > versions later.
>
> So whenever we find a bug on musl we should just stop all our
> development until you've fixed the bug?

No. As noted above, if you need to support systems that might have b= ug
X, you write a test (configure-time or run-time as appropriate) to
detect bug X and handle it.
<= br> 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 show= s a bit of temperament?
Who's never wrong but always right?
Who&#= 39;d never dream of starting a fight?
Who get stuck with all the bad luc= k?



--
Who=E2=80=99s got t= he 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 starti= ng a fight?
Who get stuck with all the bad luck?
--001a114c519465628b0567784a10--