Mailing List Archive

On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
>
>
> On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > Linux kernel is disabling red zone and use kernel code model, yet the
> > > ABI is not going to be adjusted for that.
> > >
> > > This is resonably easy to fix on kernel side in signal handling, or by
> > > removing std usage completely
>
> On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
> > That is true. But it requires updating the kernel to a fixed one if you
> > want to run your programs compiled by 4.3 :-/ Not something we'd like to
> > demand.
>
> I changed the title just for emphasis.
>
> I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
> platforms for both Linux and BSD systems will mysteriously (to the users)
> fail, and it doesn't matter whose fault it is.

We didn't yet run into this issue and build openSUSE with 4.3 since more than
three month.

Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Richard Guenther wrote:
>
> We didn't yet run into this issue and build openSUSE with 4.3 since more than
> three month.
>

Well, how often do you take a trap inside an overlapping memmove()?

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 5, 2008 at 10:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Richard Guenther wrote:
> >
> > We didn't yet run into this issue and build openSUSE with 4.3 since more than
> > three month.
> >
>
> Well, how often do you take a trap inside an overlapping memmove()?

Right. So this problem is over-exaggerated. It's not like
"any binary you create on that system will be broken on any
other existing system."

Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

There are already gcc 4.3.0 packages on the FTP site.

Sent from my iPhone

On Mar 5, 2008, at 13:20, Joe Buck <Joe.Buck@synopsys.COM> wrote:

>
>
> On Wed, 5 Mar 2008, Jan Hubicka wrote:
>>> Linux kernel is disabling red zone and use kernel code model, yet
>>> the
>>> ABI is not going to be adjusted for that.
>>>
>>> This is resonably easy to fix on kernel side in signal handling,
>>> or by
>>> removing std usage completely
>
> On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
>> That is true. But it requires updating the kernel to a fixed one
>> if you
>> want to run your programs compiled by 4.3 :-/ Not something we'd
>> like to
>> demand.
>
> I changed the title just for emphasis.
>
> I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
> platforms for both Linux and BSD systems will mysteriously (to the
> users)
> fail, and it doesn't matter whose fault it is.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin wrote:
> Richard Guenther wrote:
> >
> >We didn't yet run into this issue and build openSUSE with 4.3 since more
> >than
> >three month.
> >
>
> Well, how often do you take a trap inside an overlapping memmove()?

Also, would it be possible to produce an exploit? If you can get string
instructions to work "the wrong way", you might be able to overwrite data.

"We haven't seen a problem" isn't the right answer. Can someone
deliberately *create* a problem?

And if we aren't sure, we should err on the side of safety.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

On Wed, 5 Mar 2008, Joe Buck wrote:

>
>
> On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > Linux kernel is disabling red zone and use kernel code model, yet the
> > > ABI is not going to be adjusted for that.
> > >
> > > This is resonably easy to fix on kernel side in signal handling, or by
> > > removing std usage completely
>
> On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
> > That is true. But it requires updating the kernel to a fixed one if you
> > want to run your programs compiled by 4.3 :-/ Not something we'd like to
> > demand.
>
> I changed the title just for emphasis.
>
> I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
> platforms for both Linux and BSD systems will mysteriously (to the users)
> fail, and it doesn't matter whose fault it is.

FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
and happens seldomly if at all. And only on unfixed kernels. A program
needs to do std explicitely, which most don't do _and_ get hit by a signal
while begin in a std region. This happens so seldom that it didn't occur
in building the next openSuSE 11.0, and it continually builds packages
with 4.3 since months.

It should be worked around in 4.3.1 if at all.


Ciao,
Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 5, 2008 at 10:43 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
>
> On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin wrote:
> > Richard Guenther wrote:
> > >
> > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > >than
> > >three month.
> > >
> >
> > Well, how often do you take a trap inside an overlapping memmove()?
>
> Also, would it be possible to produce an exploit? If you can get string
> instructions to work "the wrong way", you might be able to overwrite data.
>
> "We haven't seen a problem" isn't the right answer. Can someone
> deliberately *create* a problem?
>
> And if we aren't sure, we should err on the side of safety.

Oh, you mean releasing a kernel security update? ;) What does ICC or
other compilers do?

Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Richard Guenther a écrit :
> On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
>>
>> On Wed, 5 Mar 2008, Jan Hubicka wrote:
>> > > Linux kernel is disabling red zone and use kernel code model, yet the
>> > > ABI is not going to be adjusted for that.
>> > >
>> > > This is resonably easy to fix on kernel side in signal handling, or by
>> > > removing std usage completely
>>
>> On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
>> > That is true. But it requires updating the kernel to a fixed one if you
>> > want to run your programs compiled by 4.3 :-/ Not something we'd like to
>> > demand.
>>
>> I changed the title just for emphasis.
>>
>> I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
>> platforms for both Linux and BSD systems will mysteriously (to the users)
>> fail, and it doesn't matter whose fault it is.
>
> We didn't yet run into this issue and build openSUSE with 4.3 since more than
> three month.
>

The problem can be easily reproduced by using a glibc built with gcc
4.3, with SBCL (the gcc version doesn't matter). The signal handler in
SBCL calls sigemptyset() which uses memset().


--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

On Wed, 5 Mar 2008, Chris Lattner wrote:

>
> On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
>
> >Richard Guenther wrote:
> > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > >than
> > >three month.
> >
> >Well, how often do you take a trap inside an overlapping memmove()?
>
> How hard is it to change the kernel signal entry path from "pushf" to
> "pushf;cld"? Problem solved, no?

The problem is with old kernels, which by definition stay unfixed.


Ciao,
Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Chris Lattner wrote:
>
> On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
>
>> Richard Guenther wrote:
>>> We didn't yet run into this issue and build openSUSE with 4.3 since
>>> more than
>>> three month.
>>
>> Well, how often do you take a trap inside an overlapping memmove()?
>
> How hard is it to change the kernel signal entry path from "pushf" to
> "pushf;cld"? Problem solved, no?

Not quite, but fixing it in the kernel is easy.

Still breaks for running on all old kernels.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> Hi,
>
> On Wed, 5 Mar 2008, Joe Buck wrote:
>
> >
> >
> > On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > > Linux kernel is disabling red zone and use kernel code model, yet the
> > > > ABI is not going to be adjusted for that.
> > > >
> > > > This is resonably easy to fix on kernel side in signal handling, or by
> > > > removing std usage completely
> >
> > On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
> > > That is true. But it requires updating the kernel to a fixed one if you
> > > want to run your programs compiled by 4.3 :-/ Not something we'd like to
> > > demand.
> >
> > I changed the title just for emphasis.
> >
> > I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
> > platforms for both Linux and BSD systems will mysteriously (to the users)
> > fail, and it doesn't matter whose fault it is.
>
> FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
> and happens seldomly if at all. And only on unfixed kernels. A program
> needs to do std explicitely, which most don't do _and_ get hit by a signal
> while begin in a std region. This happens so seldom that it didn't occur
> in building the next openSuSE 11.0, and it continually builds packages
> with 4.3 since months.
>
> It should be worked around in 4.3.1 if at all.

OK, I suppose that I over-reacted, and it seems that the ship has sailed
in any case.

I agree that it's obscure, and I think that the only reason to worry is
if it introduces a means of attack, which seems unlikely.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote:
> Hi,
>
> On Wed, 5 Mar 2008, Chris Lattner wrote:
>
> >
> > On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
> >
> > >Richard Guenther wrote:
> > > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > > >than
> > > >three month.
> > >
> > >Well, how often do you take a trap inside an overlapping memmove()?
> >
> > How hard is it to change the kernel signal entry path from "pushf" to
> > "pushf;cld"? Problem solved, no?
>
> The problem is with old kernels, which by definition stay unfixed.

Compiling older kernels with new gcc versions has never been supported.

You are e.g. aware that for many 32bit architectures (including i386)
and kernels up to and including 2.6.25-rc4 even the build fails with
gcc 4.3?

> Ciao,
> Michael.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: "Richard Guenther" <richard.guenther@gmail.com>
Date: Wed, 5 Mar 2008 22:40:59 +0100

> Right. So this problem is over-exaggerated. It's not like
> "any binary you create on that system will be broken on any
> other existing system."

I will be sure to hunt you down to help debug when someone reports
that once every few weeks their multi-day simulation gives incorrect
results :-)

This is one of those cases where the bug is going to be a huge
issue to people who actually hit it, and since we know about the
problem, knowingly shipping something in that state is unforgivable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Michael Matz <matz@suse.de>
Date: Wed, 5 Mar 2008 22:43:33 +0100 (CET)

> The error is arcane and happens seldomly if at all. And only on
> unfixed kernels.

Which translates right now into "all kernels."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Adrian Bunk <bunk@kernel.org>
Date: Thu, 6 Mar 2008 00:13:04 +0200

> On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote:
> > The problem is with old kernels, which by definition stay unfixed.
>
> Compiling older kernels with new gcc versions has never been supported.

Adrian we're talking about userland binaries compiled by
gcc-4.3, not the kernel.

Please follow the discussion if you'd like to contribute.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 02:16:22PM -0800, David Miller wrote:
> From: "Richard Guenther" <richard.guenther@gmail.com>
> Date: Wed, 5 Mar 2008 22:40:59 +0100
>
> > Right. So this problem is over-exaggerated. It's not like
> > "any binary you create on that system will be broken on any
> > other existing system."
>
> I will be sure to hunt you down to help debug when someone reports
> that once every few weeks their multi-day simulation gives incorrect
> results :-)
>
> This is one of those cases where the bug is going to be a huge
> issue to people who actually hit it, and since we know about the
> problem, knowingly shipping something in that state is unforgivable.

In this case, it appears that the 4.3.0 tarballs already hit the
servers before the issue was discovered.

It's not the end of the world; quite often .0 releases have some issue,
and we can patch the 4_3 branch and recommend that the patch be used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

On Wed, 5 Mar 2008, David Miller wrote:

> I will be sure to hunt you down to help debug when someone reports that
> once every few weeks their multi-day simulation gives incorrect results
> :-)

Give them a LD_PRELOADable DSO that intercepts signal() and sig_action(),
installing a trampoline that first does "cld" and then jumps to the real
handler. That ought to be a quick test if it's this or a different issue.
A hack, yes, but well... :)

> This is one of those cases where the bug is going to be a huge issue to
> people who actually hit it, and since we know about the problem,
> knowingly shipping something in that state is unforgivable.

Many bugs are a big issue to people who actually hit them, and we had (and
probably still have) far nastier corner case miscompilations here and
there and nevertheless released. It never was the end of the world :)

Let it be a data point that nobody noticed the problem which existed in
trunk since more than a year (since 2006-12-06 to be precise).


Ciao,
Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michael Matz wrote:
>
> Many bugs are a big issue to people who actually hit them, and we had (and
> probably still have) far nastier corner case miscompilations here and
> there and nevertheless released. It never was the end of the world :)
>

This is the sort of stuff that security holes are made from.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

On Wed, 5 Mar 2008, H. Peter Anvin wrote:

> Michael Matz wrote:
> >
> > Many bugs are a big issue to people who actually hit them, and we had (and
> > probably still have) far nastier corner case miscompilations here and there
> > and nevertheless released. It never was the end of the world :)
> >
>
> This is the sort of stuff that security holes are made from.

For security problems I prefer fixes over work-arounds. The fix lies in
the kernel, the work-around in gcc.


Ciao,
Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Michael Matz <matz@suse.de>
Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET)

> The fix lies in the kernel, the work-around in gcc.

This depends upon how you interpret this ABI situation.

There is at least some agreement that how things have
actually been implemented by these kernels for more
than 15 years trumps whatever a paper standard states.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Mar 06, 2008 at 12:07:39AM +0100, Michael Matz wrote:
> For security problems I prefer fixes over work-arounds. The fix lies in
> the kernel, the work-around in gcc.

Incorrect. The bugs are in the ABI documentation and in gcc, and the
fixes should be done there. Doing it in the kernel is the workaround.

OG.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Mar 06, 2008 at 12:13:04AM +0200, Adrian Bunk wrote:
> Compiling older kernels with new gcc versions has never been supported.

You read the thread too fast. It's not at all about compiling the
kernel.

OG.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 03:10:12PM -0800, David Miller wrote:
> From: Michael Matz <matz@suse.de>
> Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET)
>
> > The fix lies in the kernel, the work-around in gcc.
>
> This depends upon how you interpret this ABI situation.
>
> There is at least some agreement that how things have
> actually been implemented by these kernels for more
> than 15 years trumps whatever a paper standard states.

We had a similar argument about the undefinedness of signed int
overflow. That's what the standard says, yet code that assumes
otherwise is pervasive, including in gcc itself.

If a standard is widely violated in a very consistent way, the violation
in effect becomes standard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
> and happens seldomly if at all. And only on unfixed kernels. A program
> needs to do std explicitely, which most don't do _and_ get hit by a signal
> while begin in a std region. This happens so seldom that it didn't occur
> in building the next openSuSE 11.0, and it continually builds packages
> with 4.3 since months.

How would you know whether it has happened?

OG.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/