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 a
On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <[EMAIL PROTECTED]> 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
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
On Wed, Mar 5, 2008 at 10:34 PM, H. Peter Anvin <[EMAIL PROTECTED]> 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
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
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 <[EMAIL PROTECTED]> 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.
T
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
>
On Wed, Mar 5, 2008 at 10:43 PM, Joe Buck <[EMAIL PROTECTED]> 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.
> > >
> >
> >
Richard Guenther a écrit :
> On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <[EMAIL PROTECTED]> 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 res
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 f
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 overlappi
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 kerne
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.
> > >
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
> > > >th
From: "Richard Guenther" <[EMAIL PROTECTED]>
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 report
From: Michael Matz <[EMAIL PROTECTED]>
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."
From: Adrian Bunk <[EMAIL PROTECTED]>
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'
On Wed, Mar 05, 2008 at 02:16:22PM -0800, David Miller wrote:
> From: "Richard Guenther" <[EMAIL PROTECTED]>
> 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 s
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 trampoli
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
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
From: Michael Matz <[EMAIL PROTECTED]>
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 mor
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
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.
On Wed, Mar 05, 2008 at 03:10:12PM -0800, David Miller wrote:
> From: Michael Matz <[EMAIL PROTECTED]>
> 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 agr
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
> whil
Olivier Galibert wrote:
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
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?
Th
Chris Lattner a écrit :
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 en
Chris Lattner 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"? Pro
On Mar 5, 2008, at 4:47 PM, H. Peter Anvin wrote:
Chris Lattner 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 ke
Chris Lattner wrote:
Upon return to userspace, the modified state kicks in. Thus the
signal handler is entered with DF from userspace at trap time, not DF=0.
So it's an asynchronous state leak from one piece of userspace to
another.
Fine, it can happen either way. In either case, the dis
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Not quite, but fixing it in the kernel is easy.
>
> Still breaks for running on all old kernels.
Many more things break on old kernels. I guess it's not worse than
a (local) root exploit, is it?
*-stable and distributions should take care of it, as
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 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()?
That was the state with older gcc, but with ne
On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > 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 in
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> It's a kernel bug, and it needs to be fixed. The discussion is about
> what to do in the meantime.
While it is known that 32-bit glibc memmove and also inlines
for memmove and memrchr use std; some string op; cld;, 64-bit glibc d
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere else. And in gcc for blindl
Olivier Galibert wrote:
> On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
>> Olivier Galibert wrote:
>>> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
>>> I'm not convinced. It's been that way for 15 years, it's tha
Olivier Galibert wrote:
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere el
On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> >>It's a kernel bug, and it needs to be fixed.
> >
> >I'm not convinced. It's been that way for 15 years, it's that way in
> >the BSD kernel
On Wed, Mar 05, 2008 at 03:21:43PM -0800, David Daney wrote:
> Olivier Galibert wrote:
> >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
Olivier Galibert wrote:
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere el
Jakub Jelinek wrote:
On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
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 overl
On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> > It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The b
I agree with it. There is no right or wrong here Let's start from
scratch and figure out
what is the best way to handle this, assuming we are defining a new psABI.
H.J.
On Thu, Mar 6, 2008 at 7:37 AM, NightStrike <[EMAIL PROTECTED]> wrote:
>
> On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote
H.J. Lu wrote:
I agree with it. There is no right or wrong here Let's start from
scratch and figure out
what is the best way to handle this, assuming we are defining a new psABI.
No, I believe the right way to approach this is by applying the good
old-fashioned principle from Ask Mr. Protocol
NightStrike wrote:
On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote:
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a fea
Olivier Galibert wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>> It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The bug is in the
> documentation, n
On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> H.J. Lu wrote:
> >I agree with it. There is no right or wrong here Let's start from
> >scratch and figure out
> >what is the best way to handle this, assuming we are defining a new psABI.
BTW, just tested icc and icc doesn't genera
Hi,
On Thu, Mar 6, 2008 at 6:23 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> > H.J. Lu wrote:
> > >I agree with it. There is no right or wrong here Let's start from
> > >scratch and figure out
> > >what is the best way to han
Another story, the sad story of the intel chip (I think it was
the 80188) where Intel made use of Int 5, which was documented
as reserved. Unfortunately, Microsoft/IBM had used this for
print screen or some such. Intel was absolutely right that
their documentation was clear and it was wrong to h
On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> > H.J. Lu wrote:
> > >I agree with it. There is no right or wrong here Let's start from
> > >scratch and figure out
> > >what is the best way to handle t
H.J. Lu wrote:
On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> H.J. Lu wrote:
> >I agree with it. There is no right or wrong here Let's start from
> >scratch and figure out
> >what is the best way to
On Thu, Mar 6, 2008 at 9:06 AM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> H.J. Lu wrote:
> > On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> >> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> >> > H.J. Lu wrote:
> >> > >I agree with it. There i
H.J. Lu wrote:
So that is the bug in the Linux kernel. Since fixing kernel is much easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
Fixing a bug in the Linux kernel is not "much easier". You are taking
a purely engineering viewpoint,
Robert Dewar wrote:
H.J. Lu wrote:
So that is the bug in the Linux kernel. Since fixing kernel is much
easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
Fixing a bug in the Linux kernel is not "much easier". You are taking
a purely e
H.J. Lu wrote:
Not a fix, an (optional) workaround for a system bug.
So that is the bug in the Linux kernel. Since fixing kernel is much easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
The problem is, you're going to have to be a
On Thu, Mar 6, 2008 at 9:17 AM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
> >>
> >> Not a fix, an (optional) workaround for a system bug.
> >
> > So that is the bug in the Linux kernel. Since fixing kernel is much easier
> > than providing a workaround in compilers, I think k
Robert Dewar wrote:
Sounds good, but has almost nothing to do with the real world. I
remember back in Realia COBOL days, we had to carefully copy IBM
bugs in the IBM mainframe COBOL compiler. Doing things right and
fixing the bug would have been the right thing to do, but no one
would have use
On Thu, Mar 06, 2008 at 03:12:21PM +0100, Olivier Galibert wrote:
> On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
> > Olivier Galibert wrote:
> > >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> > >>It's a kernel bug, and it needs to be fixed.
> > >
> > >I'm not c
On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote:
> If the kernel allows state to leak from one process to another,
> for example from a process running as root to a process running as an
> ordinary user, it's a bug, with possible security implications.
I don't think that it is relevant in
Olivier Galibert wrote:
On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote:
If the kernel allows state to leak from one process to another,
for example from a process running as root to a process running as an
ordinary user, it's a bug, with possible security implications.
I don't think
On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> A process can send a signal via kill. IOW, a malicious process can
> *control when the process would be interrupted* in order to get it into
> the signal handler with DF=1.
If the malicious process can send a signal to another pro
On 3/6/08, Jack Lloyd <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> > A process can send a signal via kill. IOW, a malicious process can
> > *control when the process would be interrupted* in order to get it into
> > the signal handler with DF=1.
H. Peter Anvin wrote:
Robert Dewar wrote:
H.J. Lu wrote:
So that is the bug in the Linux kernel. Since fixing kernel is much
easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
Fixing a bug in the Linux kernel is not "much easier". You
H.J. Lu wrote:
Icc has been following psABI for years on Linux and it doesn't stop people
using icc on Linux. On the other hand, it may be a good idea to provide a
workaround in gcc and enables it by default. OSVs can fix thekernel and
disable it by default.
How widely is icc used? I ask bec
Jack Lloyd wrote:
On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
A process can send a signal via kill. IOW, a malicious process can
*control when the process would be interrupted* in order to get it into
the signal handler with DF=1.
If the malicious process can send a signal
If the malicious process can send a signal to another process, it
could also ptrace() it. Which is more useful, if you wanted to be
malicious?
And more to the point, it can happen before GCC 4.3.0.
Yes, and that's why the kernel should just fix it, and the fix should be
backported and trea
On Thu, Mar 06, 2008 at 08:43:27PM +0100, Paolo Bonzini wrote:
> Jack Lloyd wrote:
> >On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> >>A process can send a signal via kill. IOW, a malicious process can
> >>*control when the process would be interrupted* in order to get it into
Robert Dewar wrote:
Not really, it's just a matter of time. Typical distro cycles are on
the order of 3 years.
-hpa
again, in the real world, there are MANY projects that are nothing
like this interactive when it comes to moving to new versions of
operating systems.
This is true, but
Jack Lloyd wrote:
> But still: so the threat here is of a malicious process with the
> ability to send arbitrary signals to any process using CAP_KILL (since
> in any other case when a process can send a signal, it can do much
> more damage in other ways), which could leverage that into
> (potentia
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Robert Dewar wrote:
>> H.J. Lu wrote:
>>
>>> So that is the bug in the Linux kernel. Since fixing kernel is much
>>> easier
>>> than providing a workaround in compilers, I think kernel should be fixed
>>> and no need for icc/gcc fix.
>>
>> Fixing a bu
* Robert Dewar:
> again, in the real world, there are MANY projects that are nothing
> like this interactive when it comes to moving to new versions of
> operating systems.
Sure, but how many of those get to see software compiled with GCC 4.3?
If this has any real impact, it's more likely to sho
On Mar 6, 2008, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> It's extremely rare, no doubt about it. It's just that it *yells*
> security issue in the making. It's not a source bug, i.e. not easily
> reviewable. It's related to signal handlers which are the mark of a
> server and/or more fail
74 matches
Mail list logo
