Is there any relevance to the kernel ?
I found the folowing code here:
http://linux.solidot.org/article.pl?sid=07/11/19/0512218&from=rss
-------------------------------------------------------------------
int main( void )
{
int i=2;
if( -10*abs (i-1) == 10*abs(i-1) )
printf ("OMG,-10==10 in linux!\n");
else
printf ("nothing special here\n") ;
return 0 ;
}
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
>Is there any relevance to the kernel ?
>
>I found the folowing code here:
>http://linux.solidot.org/article.pl?sid=07/11/19/0512218&from=rss
>
>-------------------------------------------------------------------
>int main( void )
>{
> int i=2;
> if( -10*abs (i-1) == 10*abs(i-1) )
> printf ("OMG,-10==10 in linux!\n");
> else
> printf ("nothing special here\n") ;
>
> return 0 ;
>}
I think no. It is considered a bug in abs(), kernel, of course,
doesn't use glibc's abs().
Regards.
WANG Cong wrote:
> On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
>> Is there any relevance to the kernel ?
>>
>> I found the folowing code here:
>> http://linux.solidot.org/article.pl?sid=07/11/19/0512218&from=rss
>>
>> -------------------------------------------------------------------
>> int main( void )
>> {
>> int i=2;
>> if( -10*abs (i-1) == 10*abs(i-1) )
>> printf ("OMG,-10==10 in linux!\n");
>> else
>> printf ("nothing special here\n") ;
>>
>> return 0 ;
>> }
>
> I think no. It is considered a bug in abs(), kernel, of course,
> doesn't use glibc's abs().
>
Wrong.
abs() is internal to gcc, and the above is optimized out at compile
time, so any user of abs() as a function at all is vulnerable.
However, the Linux kernel defines abs() as a macro:
#define abs(x) ({ \
int __x = (x); \
(__x < 0) ? -__x : __x; \
})
... which means gcc never sees it. So the kernel isn't affected,
because it doesn't use *gcc's* abs().
-hpa
On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
>WANG Cong wrote:
>>On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
>>>Is there any relevance to the kernel ?
>>>
>>>I found the folowing code here:
>>>http://linux.solidot.org/article.pl?sid=07/11/19/0512218&from=rss
>>>
>>>-------------------------------------------------------------------
>>>int main( void )
>>>{
>>> int i=2;
>>> if( -10*abs (i-1) == 10*abs(i-1) )
>>> printf ("OMG,-10==10 in linux!\n");
>>> else
>>> printf ("nothing special here\n") ;
>>>
>>> return 0 ;
>>>}
>>
>>I think no. It is considered a bug in abs(), kernel, of course,
>>doesn't use glibc's abs().
>>
>
>Wrong.
>
>abs() is internal to gcc, and the above is optimized out at compile
>time, so any user of abs() as a function at all is vulnerable.
This is an urgent bug, I think.
And you mean abs() is not in glibc, then where is it? Built in gcc?
And what's more, why not put it in glibc?
Thanks.
>
>However, the Linux kernel defines abs() as a macro:
>
>#define abs(x) ({ \
> int __x = (x); \
> (__x < 0) ? -__x : __x; \
> })
>
>... which means gcc never sees it. So the kernel isn't affected,
>because it doesn't use *gcc's* abs().
Thanks for clarifying this!
Regards.
WANG Cong wrote:
>
> This is an urgent bug, I think.
>
> And you mean abs() is not in glibc, then where is it? Built in gcc?
> And what's more, why not put it in glibc?
>
If you need answers to this type of questions, this is not the place for it.
-hpa
WANG Cong wrote:
> On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
>> WANG Cong wrote:
>>> On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
>>>> Is there any relevance to the kernel ?
>>>>
>>>> I found the folowing code here:
>>>> http://linux.solidot.org/article.pl?sid=07/11/19/0512218&from=rss
>>>>
>>>> -------------------------------------------------------------------
>>>> int main( void )
>>>> {
>>>> int i=2;
>>>> if( -10*abs (i-1) == 10*abs(i-1) )
>>>> printf ("OMG,-10==10 in linux!\n");
>>>> else
>>>> printf ("nothing special here\n") ;
>>>>
>>>> return 0 ;
>>>> }
>>> I think no. It is considered a bug in abs(), kernel, of course,
>>> doesn't use glibc's abs().
>>>
>> Wrong.
>>
>> abs() is internal to gcc, and the above is optimized out at compile
>> time, so any user of abs() as a function at all is vulnerable.
>
> This is an urgent bug, I think.
>
> And you mean abs() is not in glibc, then where is it? Built in gcc?
> And what's more, why not put it in glibc?
>
Gcc optimises abs() to use gcc builtin-in abs(). So if we use -fno-builin,
we'll get the correct result. That is to say the bug has nothing to do with
glibc.
And this bug has been fixed just several days ago.
http://www.nabble.com/-PATCH--Fix-PR34130,-extract_muldiv-broken-t4826688.html
>
>> However, the Linux kernel defines abs() as a macro:
>>
>> #define abs(x) ({ \
>> int __x = (x); \
>> (__x < 0) ? -__x : __x; \
>> })
>>
>> ... which means gcc never sees it. So the kernel isn't affected,
>> because it doesn't use *gcc's* abs().
>
> Thanks for clarifying this!
>
> Regards.
>
On Tue, Nov 20, 2007 at 02:03:12PM +0800, Li Zefan wrote:
>WANG Cong wrote:
>> On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
>>> WANG Cong wrote:
>>>> On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
>>>>> Is there any relevance to the kernel ?
>>>>>
>>>>> I found the folowing code here:
>>>>> http://linux.solidot.org/article.pl?sid=07/11/19/0512218&from=rss
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> int main( void )
>>>>> {
>>>>> int i=2;
>>>>> if( -10*abs (i-1) == 10*abs(i-1) )
>>>>> printf ("OMG,-10==10 in linux!\n");
>>>>> else
>>>>> printf ("nothing special here\n") ;
>>>>>
>>>>> return 0 ;
>>>>> }
>>>> I think no. It is considered a bug in abs(), kernel, of course,
>>>> doesn't use glibc's abs().
>>>>
>>> Wrong.
>>>
>>> abs() is internal to gcc, and the above is optimized out at compile
>>> time, so any user of abs() as a function at all is vulnerable.
>>
>> This is an urgent bug, I think.
>>
>> And you mean abs() is not in glibc, then where is it? Built in gcc?
>> And what's more, why not put it in glibc?
>>
>
>Gcc optimises abs() to use gcc builtin-in abs(). So if we use -fno-builin,
>we'll get the correct result. That is to say the bug has nothing to do with
>glibc.
>
>And this bug has been fixed just several days ago.
>
>http://www.nabble.com/-PATCH--Fix-PR34130,-extract_muldiv-broken-t4826688.html
>
Good explanation! Thank you!
From: WANG Cong <[email protected]>
Date: Tue, 20 Nov 2007 13:39:05 +0800
> And you mean abs() is not in glibc, then where is it? Built in gcc?
> And what's more, why not put it in glibc?
Because the compiler knows things about the inputs and can
thus apply optimizations that a static implementation in glibc
that has to handle all forms of inputs cannot.
David Miller <[email protected]> wrote:
>
> Because the compiler knows things about the inputs and can
> thus apply optimizations that a static implementation in glibc
> that has to handle all forms of inputs cannot.
On an unrelated note, I wonder if distros will be treating this
with the same level of urgency as security vulnerabilities,
especially in light of Shamir's recent note on maths errors.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu wrote:
> David Miller <[email protected]> wrote:
>> Because the compiler knows things about the inputs and can
>> thus apply optimizations that a static implementation in glibc
>> that has to handle all forms of inputs cannot.
>
> On an unrelated note, I wonder if distros will be treating this
> with the same level of urgency as security vulnerabilities,
> especially in light of Shamir's recent note on maths errors.
>
This one is definitely messy. There is absolutely no way to know what
gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
affected, any others?
-hpa
On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
>
> This one is definitely messy. There is absolutely no way to know what
> gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
> affected, any others?
I just tested it here and gcc 3.3 is also affected so presumably
everything in between is too. Gcc 2.95 is not affected. I don't
have the intervening versions to test.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Nov 20, 2007 7:52 AM, Herbert Xu <[email protected]> wrote:
> On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
> >
> > This one is definitely messy. There is absolutely no way to know what
> > gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
> > affected, any others?
>
> I just tested it here and gcc 3.3 is also affected so presumably
> everything in between is too. Gcc 2.95 is not affected. I don't
> have the intervening versions to test.
Fedora 7's 4.1.2-27 is also affected.
--alessandro
"you feel the sweet breath of time
it's whispering, its truth not mine"
(Interpol, 'No I In Threesome')
On Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote:
> On Nov 20, 2007 7:52 AM, Herbert Xu <[email protected]> wrote:
> > On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
> > >
> > > This one is definitely messy. There is absolutely no way to know what
> > > gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
> > > affected, any others?
> >
> > I just tested it here and gcc 3.3 is also affected so presumably
> > everything in between is too. Gcc 2.95 is not affected. I don't
> > have the intervening versions to test.
>
> Fedora 7's 4.1.2-27 is also affected.
-m32:
2.7.2.3: /tmp/cc1EO0wg.s:14: Error: suffix or operands invalid for `push'
2.95.3: OK
3.0.4: broken
3.1.1: broken
3.2.3: broken
3.3.5: broken
3.4.6: broken
4.0.3: broken
-m32 and -m64:
gcc Red Hat 4.1.2-33: broken
4.2.2 20070909 (prerelease): broken
--
Do what you love because life is too short for anything else.
On 20 Nov 2007, H. Peter Anvin outgrape:
> This one is definitely messy. There is absolutely no way to know what
> gcc has miscompiled.
Actually, since this only affects abs() calls containing multiplications
or divisions by negative constants, you can at least make a pretty good
guess as to its prevalence with nothing more than grep (first grep -w
for abs, then grepping for "- *[0-9]" and filtering the rest by
eye). (This won't catch cases of macros using abs() which are then
called with negative constants, but it *will* catch those macros, and
one can check the calls to such things by hand. I've done that as well.)
I've grepped all the source on my system (1148 expanded upstream source
tarballs or git/cvs/svn trees including the Linux kernel, most of GNOME,
and all of KDE and X.org) and found that hits are extremely rare: not as
rare as calls to seekdir() and telldir() :) but rare. (Quite a lot of
things multiply by negative constants *inside* a call to abs(), but this
should be unaffected.)
Certain hits:
./nethack/3.4.3/src/cmd.c: else if(x < -2*abs(y))
./nethack/3.4.3/src/cmd.c: else if(y < -2*abs(x))
Possible hits (I'm not sure what the folder would do with this: the
extra level of brackets in the way might affect things but I don't think
so):
./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue - 2*(abs(Src[j+Pitch]-Src[j]));
./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue - 2*(abs(Src[j+1]-Src[j]));
./xmms/modules/projectM-0.94.20/main.c: wave_x_temp=-2*0.4142*(abs(abs(wave_mystery)-.5)-.5);
./xmms/modules/projectM-0.94.20/main.c: wave_x_temp=-2*0.4142*(abs(abs(wave_mystery)-.5)-.5);
None of these affected programs strike me as being exactly system-
critical. I think the impact of this bug is probably survivable. :)
I'd build a GCC with the patch and verify that these programs are
compiled differently with it, but they look unimportant enough that I'm
not really sure I care enough to do it...
--
`Some people don't think performance issues are "real bugs", and I think
such people shouldn't be allowed to program.' --- Linus Torvalds
Nix wrote:
> I've grepped all the source on my system (1148 expanded upstream source
> tarballs or git/cvs/svn trees including the Linux kernel, most of GNOME,
> and all of KDE and X.org) and found that hits are extremely rare: not as
> rare as calls to seekdir() and telldir() :) but rare. (Quite a lot of
> things multiply by negative constants *inside* a call to abs(), but this
> should be unaffected.)
I implemented a different approach: patched gcc with the official fix plus a
call to emit a warning (see below), and recompiled the whole LFS LiveCD (see the
list of packages at
http://wiki.linuxfromscratch.org/livecd/browser/trunk/packages). Only libtheora
emitted a warning.
> Certain hits:
>
> ./nethack/3.4.3/src/cmd.c: else if(x < -2*abs(y))
> ./nethack/3.4.3/src/cmd.c: else if(y < -2*abs(x))
Sure, this is a hit, but nethack is not on my LiveCD.
> Possible hits (I'm not sure what the folder would do with this: the
> extra level of brackets in the way might affect things but I don't think
> so):
>
> ./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue - 2*(abs(Src[j+Pitch]-Src[j]));
> ./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue - 2*(abs(Src[j+1]-Src[j]));
This did emit a warning, I have already reported it:
https://trac.xiph.org/ticket/1260
> ./xmms/modules/projectM-0.94.20/main.c: wave_x_temp=-2*0.4142*(abs(abs(wave_mystery)-.5)-.5);
> ./xmms/modules/projectM-0.94.20/main.c: wave_x_temp=-2*0.4142*(abs(abs(wave_mystery)-.5)-.5);
Not a hit, probably due to conversions between int and double.
--- trunk/gcc/fold-const.c 2007/11/17 13:46:53 130257
+++ trunk/gcc/fold-const.c 2007/11/17 14:22:42 130258
@@ -6095,6 +6095,9 @@
}
break;
}
+ /* If the constant is negative, we cannot simplify this. */
+ if (tree_int_cst_sgn (c) == -1)
+ { warning(0, "Unpatched gcc miscompiles this"); break; }
/* FALLTHROUGH */
case NEGATE_EXPR:
if ((t1 = extract_muldiv (op0, c, code, wide_type, strict_overflow_p))
--
Alexander E. Patrakov
I wrote:
> Nix wrote:
>> Possible hits (I'm not sure what the folder would do with this: the
>> extra level of brackets in the way might affect things but I don't think
>> so):
>>
>> ./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue -
>> 2*(abs(Src[j+Pitch]-Src[j]));
>> ./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue -
>> 2*(abs(Src[j+1]-Src[j]));
>
> This did emit a warning, I have already reported it:
> https://trac.xiph.org/ticket/1260
And on IRC, they explained that it is a piece of code that never gets called. So
not a hit.
--
Alexander E. Patrakov
On Wed, Nov 21, 2007 at 09:19:05PM +0500, Alexander E. Patrakov wrote:
> And on IRC, they explained that it is a piece of code that never gets
> called. So not a hit.
It's still a hit. If the code is never called it should not be there in
the first place.
--
Len Sorensen