Re: Weird kernel 2.6.17.[67] behaviour

Re: Weird kernel 2.6.17.[67] behaviour

[Sébastien Bernard]

seb@frankengul.org a écrit :
> I got a perfectly workable kernel 2.6.17.1 using mkinitramfs on my U60.
> 
> I applied 2 days ago the patches to update the kernel to the 2.6.17.7.
> And to my surprise when rebooting, the boot process hanged for now
> reason.
> 
> More surprising is that when boot continues if I press one key on the
> keyboard or one button on the mouse.
> 
> The hangs happens several times in the start process and each time the
> boot resume when I press a key or a button.
> 
> I never saw such a behaviour and was looking forward the change that
> caused this.
> 
> It is not the compiler since it is the same version used for building
> the 2.6.17.1 and this one is working.
> 
> It is not the mkinitramfs tools since I tried the yaird to regenerate a
> new initrd and it hangs in the same way.
> 
> Can you shed some lights on this dark corner of linux ?
> 
> 	Seb
> 
> 

I have searched which patch is the culprit.
I appears that the 2.6.17.3 kernel is OK and the 2.6.17.4 is showing the
problem..


diff --git a/kernel/sys.c b/kernel/sys.c
index 0b6ec0e..59273f7 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1991,7 +1991,7 @@ asmlinkage long sys_prctl(int option, un
                        error = current->mm->dumpable;
                        break;
                case PR_SET_DUMPABLE:
-                       if (arg2 < 0 || arg2 > 2) {
+                       if (arg2 < 0 || arg2 > 1) {
                                error = -EINVAL;
                                break;
                        }

I've checked and this is really the culprit.
Recompiling the 2.6.17.7 whith the patch reversed got the kernel on
track again.

I can't figure why this cause the problem.
Can you have an explanation for this ?

Re: Weird kernel 2.6.17.[67] behaviour

[Adam Henley]

On 27/07/06, Sébastien Bernard <seb@frankengul.org> wrote:
> seb@frankengul.org a écrit :
> > I got a perfectly workable kernel 2.6.17.1 using mkinitramfs on my U60.
> >
> > Can you shed some lights on this dark corner of linux ?
> >
> >       Seb

I can't shed any more light on it, but I can look too :o)

The original mailing of the patch to the list is below:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0607.1/1694.html

[snip>
The prctl() system call should never allow to set "dumpable" to the
value 2. Especially not for non-privileged users.

This can be split into three cases:
  1) running as root -- then core dumps will already be done as root,
     and so prctl(PR_SET_DUMPABLE, 2) is not useful
  2) running as non-root w/setuid-to-root -- this is the debatable case
  3) running as non-root w/setuid-to-non-root -- then you definitely
     do NOT want "dumpable" to get set to 2 because you have the
     privilege escalation vulnerability
<snip]

Is it that something else is misbehaving and trying to dump core as root?

Re: Weird kernel 2.6.17.[67] behaviour

[seb]

On Thu, Jul 27, 2006 at 12:41:56AM +0100, Adam Henley wrote:
> On 27/07/06, Sébastien Bernard <seb@frankengul.org> wrote:
> >seb@frankengul.org a écrit :
> >> I got a perfectly workable kernel 2.6.17.1 using mkinitramfs on my U60.
> >>
> >> Can you shed some lights on this dark corner of linux ?
> >>
> >>       Seb
> 
> I can't shed any more light on it, but I can look too :o)

:). It was just a poetic licence.

> 
> The original mailing of the patch to the list is below:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0607.1/1694.html
> 
> [snip>
> The prctl() system call should never allow to set "dumpable" to the
> value 2. Especially not for non-privileged users.
> 
> This can be split into three cases:
>  1) running as root -- then core dumps will already be done as root,
>     and so prctl(PR_SET_DUMPABLE, 2) is not useful
>  2) running as non-root w/setuid-to-root -- this is the debatable case
>  3) running as non-root w/setuid-to-non-root -- then you definitely
>     do NOT want "dumpable" to get set to 2 because you have the
>     privilege escalation vulnerability
> <snip]
> 
> Is it that something else is misbehaving and trying to dump core as root?
> 

Well, I'm not arguing that the fix is a wrong fix.

I'm seeing that, on sparc64-smp arch with debian etch, this patch causes
a very strange sideeffect I was describing in my first mail.

The boot hangs, the cursor (in the framebuffer) stops blinking, nothing
is displayed, and the machine seems frozen until I hit a key or a button
mouse (which is on sparc causing the same interruption), and then the
machine resume the boot sequence as if nothing really happened.

I've been able to isolate that line to be the origin of this behaviour
but it could be as well a bug revealed by this modification.

	Seb

Re: Weird kernel 2.6.17.[67] behaviour

[Jan Engelhardt]

>
>The boot hangs, the cursor (in the framebuffer) stops blinking, nothing
>is displayed, and the machine seems frozen until I hit a key or a button

Hm. Does this happen if you disconnect the monitor and keyboard and instead 
boot with serial console?


Jan Engelhardt
-- 

Re: Weird kernel 2.6.17.[67] behaviour

[Adam Henley]

On 27/07/06, seb@frankengul.org <seb@frankengul.org> wrote:
> On Thu, Jul 27, 2006 at 12:41:56AM +0100, Adam Henley wrote:
> > On 27/07/06, Sébastien Bernard <seb@frankengul.org> wrote:
> > >seb@frankengul.org a écrit :
> > >> I got a perfectly workable kernel 2.6.17.1 using mkinitramfs on my U60.
> > >>
> > >> Can you shed some lights on this dark corner of linux ?
> > >>
> > >>       Seb
> >
> > I can't shed any more light on it, but I can look too :o)
>
> :). It was just a poetic licence.

Me too :)

> Well, I'm not arguing that the fix is a wrong fix.

And I'm *definitely* not ruling it out as a cause of your problems :)
I don't have the know-how,  just trying to be helpful.Unfortunately I
don't have access to your arch of choice, otherwise I wouldn't be busy
installing Quake on my box in prep. for a company LAN party.

---
adam