Over-riding symbols in the Kernel causes Kernel Panic

Over-riding symbols in the Kernel causes Kernel Panic

[Ashutosh Naik]

Hi,

I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
kernel and booted the kernel. Next I compiled e1000 as a module (
e1000.ko ), and tried to insmod it into the kernel( which already had
e1000 a compiled as a part of the kernel). I observed that
/proc/kallsyms contained two copies of all the symbols exported by
e1000, and I also got a Kernel Panic on the way.

Is this behaviour natural and desirable ?

Regards and Thanks
-A

Re: Over-riding symbols in the Kernel causes Kernel Panic

[linux-os (Dick Johnson)]

On Wed, 23 Nov 2005, Ashutosh Naik wrote:

> Hi,
>
> I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> kernel and booted the kernel. Next I compiled e1000 as a module (
> e1000.ko ), and tried to insmod it into the kernel( which already had
> e1000 a compiled as a part of the kernel). I observed that
> /proc/kallsyms contained two copies of all the symbols exported by
> e1000, and I also got a Kernel Panic on the way.
>
> Is this behaviour natural and desirable ?
>
> Regards and Thanks
> -A

When the new module interface was implemented, new bugs were
introduced. You just found another one!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Over-riding symbols in the Kernel causes Kernel Panic

[Bill Davidsen]

Ashutosh Naik wrote:
> Hi,
> 
> I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> kernel and booted the kernel. Next I compiled e1000 as a module (
> e1000.ko ), and tried to insmod it into the kernel( which already had
> e1000 a compiled as a part of the kernel). I observed that
> /proc/kallsyms contained two copies of all the symbols exported by
> e1000, and I also got a Kernel Panic on the way.
> 
> Is this behaviour natural and desirable ?

No, trying to insert a module into a kernel built with the functionality 
compiled in is a vile perverted act, and probably illegal in Republican 
states! ;-)

The other day I mentioned that reiser4 will find bugs because people 
will do bizarre things with it when it is more widely used. I think you 
have hit a "no one would ever do that" bug in the module loader, and 
demonstrated my point in the process.

The panic isn't desirable, but I'm not sure what "correct behaviour" 
would be, I can't imagine that this is intended to work. The issues of 
removing such a module gracefully are significant.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Over-riding symbols in the Kernel causes Kernel Panic

[Jesper Juhl]

On 11/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
> Ashutosh Naik wrote:
> > Hi,
> >
> > I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> > kernel and booted the kernel. Next I compiled e1000 as a module (
> > e1000.ko ), and tried to insmod it into the kernel( which already had
> > e1000 a compiled as a part of the kernel). I observed that
> > /proc/kallsyms contained two copies of all the symbols exported by
> > e1000, and I also got a Kernel Panic on the way.
> >
> > Is this behaviour natural and desirable ?
>
> No, trying to insert a module into a kernel built with the functionality
> compiled in is a vile perverted act, and probably illegal in Republican
> states! ;-)
>
> The other day I mentioned that reiser4 will find bugs because people
> will do bizarre things with it when it is more widely used. I think you
> have hit a "no one would ever do that" bug in the module loader, and
> demonstrated my point in the process.
>
> The panic isn't desirable, but I'm not sure what "correct behaviour"
> would be, I can't imagine that this is intended to work. The issues of
> removing such a module gracefully are significant.

Wouldn't the desired behaviour be that when the kernel attempts to
load a module it checks if it is already present build-in and if so
simply refuse to load it at all?

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Over-riding symbols in the Kernel causes Kernel Panic

[Bill Davidsen]

Jesper Juhl wrote:
> On 11/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
> 
>>Ashutosh Naik wrote:
>>
>>>Hi,
>>>
>>>I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
>>>kernel and booted the kernel. Next I compiled e1000 as a module (
>>>e1000.ko ), and tried to insmod it into the kernel( which already had
>>>e1000 a compiled as a part of the kernel). I observed that
>>>/proc/kallsyms contained two copies of all the symbols exported by
>>>e1000, and I also got a Kernel Panic on the way.
>>>
>>>Is this behaviour natural and desirable ?
>>
>>No, trying to insert a module into a kernel built with the functionality
>>compiled in is a vile perverted act, and probably illegal in Republican
>>states! ;-)
>>
>>The other day I mentioned that reiser4 will find bugs because people
>>will do bizarre things with it when it is more widely used. I think you
>>have hit a "no one would ever do that" bug in the module loader, and
>>demonstrated my point in the process.
>>
>>The panic isn't desirable, but I'm not sure what "correct behaviour"
>>would be, I can't imagine that this is intended to work. The issues of
>>removing such a module gracefully are significant.
> 
> 
> Wouldn't the desired behaviour be that when the kernel attempts to
> load a module it checks if it is already present build-in and if so
> simply refuse to load it at all?

It doesn't look to be quite as easy to check for built-in as to check 
for "already loaded" without some global state tracking, and handling 
the case where it just wasn't built at all, and may have other stuff 
missing. Add to this not breaking existing out of tree code and the 
implementation looks like a non-trivial exercise.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Over-riding symbols in the Kernel causes Kernel Panic

[Ashutosh Naik]

On 11/24/05, Bill Davidsen <davidsen@tmr.com> wrote:

>>I've not looked at what it would take to do that, nor what measures
>>are currently in place, *at all*, but as I see it, all it would take
>>would be some "tag" present for each message stating if it was "build
>>in", or "currently loaded as a module", then on each module load check
>>the "tag" of the to-be-loaded module against the list of current
>>in-kernel tags, then reject if already on the list.
>>I can't see why there would be a catch...

> It doesn't look to be quite as easy to check for built-in as to check
> for "already loaded" without some global state tracking, and handling
> the case where it just wasn't built at all, and may have other stuff
> missing. Add to this not breaking existing out of tree code and the
> implementation looks like a non-trivial exercise.

I am currently working on a preliminary patch which addresses this
issue. A module wont be able to load any symbol, which already exists
in the kernel symbol table.

Regards
Ashutosh

Re: Over-riding symbols in the Kernel causes Kernel Panic

[Grant Coady]

On Wed, 23 Nov 2005 19:04:41 +0100, Jesper Juhl <jesper.juhl@gmail.com> wrote:

>On 11/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
>> Ashutosh Naik wrote:
>> > Hi,
>> >
>> > I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
>> > kernel and booted the kernel. Next I compiled e1000 as a module (
>> > e1000.ko ), and tried to insmod it into the kernel( which already had
>> > e1000 a compiled as a part of the kernel). I observed that
>> > /proc/kallsyms contained two copies of all the symbols exported by
>> > e1000, and I also got a Kernel Panic on the way.
>> >
>> > Is this behaviour natural and desirable ?
>>
>> No, trying to insert a module into a kernel built with the functionality
>> compiled in is a vile perverted act, and probably illegal in Republican
>> states! ;-)
>>
>> The other day I mentioned that reiser4 will find bugs because people
>> will do bizarre things with it when it is more widely used. I think you
>> have hit a "no one would ever do that" bug in the module loader, and
>> demonstrated my point in the process.
>>
>> The panic isn't desirable, but I'm not sure what "correct behaviour"
>> would be, I can't imagine that this is intended to work. The issues of
>> removing such a module gracefully are significant.
>
>Wouldn't the desired behaviour be that when the kernel attempts to
>load a module it checks if it is already present build-in and if so
>simply refuse to load it at all?

But that sounds just too easy to implement, what's the catch?  :o)
-- 
Grant.

Re: Over-riding symbols in the Kernel causes Kernel Panic

[Jesper Juhl]

On 11/23/05, Grant Coady <grant_lkml@dodo.com.au> wrote:
> On Wed, 23 Nov 2005 19:04:41 +0100, Jesper Juhl <jesper.juhl@gmail.com> wrote:
>
> >On 11/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
> >> Ashutosh Naik wrote:
> >> > Hi,
> >> >
> >> > I made e1000 ( or for that matter anything) a part of the 2.6.15-rc1
> >> > kernel and booted the kernel. Next I compiled e1000 as a module (
> >> > e1000.ko ), and tried to insmod it into the kernel( which already had
> >> > e1000 a compiled as a part of the kernel). I observed that
> >> > /proc/kallsyms contained two copies of all the symbols exported by
> >> > e1000, and I also got a Kernel Panic on the way.
> >> >
> >> > Is this behaviour natural and desirable ?
> >>
> >> No, trying to insert a module into a kernel built with the functionality
> >> compiled in is a vile perverted act, and probably illegal in Republican
> >> states! ;-)
> >>
> >> The other day I mentioned that reiser4 will find bugs because people
> >> will do bizarre things with it when it is more widely used. I think you
> >> have hit a "no one would ever do that" bug in the module loader, and
> >> demonstrated my point in the process.
> >>
> >> The panic isn't desirable, but I'm not sure what "correct behaviour"
> >> would be, I can't imagine that this is intended to work. The issues of
> >> removing such a module gracefully are significant.
> >
> >Wouldn't the desired behaviour be that when the kernel attempts to
> >load a module it checks if it is already present build-in and if so
> >simply refuse to load it at all?
>
> But that sounds just too easy to implement, what's the catch?  :o)

I've not looked at what it would take to do that, nor what measures
are currently in place, *at all*, but as I see it, all it would take
would be some "tag" present for each message stating if it was "build
in", or "currently loaded as a module", then on each module load check
the "tag" of the to-be-loaded module against the list of current
in-kernel tags, then reject if already on the list.
I can't see why there would be a catch...

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html