Re: null pointers are bad. :)

Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
Mon, 29 Jun 1998 00:25:28 +0200 (CEST)


On Sun, 28 Jun 1998, Elijah L. Wright wrote:
> Geert said:
> >> Linux version 2.1.107 (kraxel@bogomips) (gcc version 2.7.2.1) #2 Sun
> >> Jun 28 17:55:25 MEST 1998
> >> kmem_alloc: NULL ptr (name=unknown)
> >> fb0: VGA frame buffer device, using 32K of video memory
> >> kmem_alloc: NULL ptr (name=unknown)
> >
> >These NULL ptrs are harmless.
>
> "harmless" isn't a word i'd use :)

Yes it is. The result of them is never used if it's NULL. It's not 100% clean,
but I don't know how to get rid of it easily.

> So what exactly in the fbcon code is causing those? In my mind, at least,
> an error is either a sign of A) sloppy/careless code or B) a Security
> hole from hell. I'm moderately worried that some genius hacker will come
> up with an exploit and use it to have some midnight fun :)

It's caused by setting the default color palette. That part of the code wants
to do a kmalloc(), which fails because the memory system wasn't initialized
yet.

> Just to voice an opinion, fixing those would suuuure make me more likely
> to trust the stability and security of the fbcon layer. :) if the rest
> of the kernel isn't griping and it compiles cleanly, then it "probably"
> works fairly well. :)

It's already `fixed' in the vger tree. Well, fixed is not the correct word for
this. In the vger tree, the initialization order in init/main.c is different.
E.g. memory and PCI are initialized before the console. So the console can use
kmalloc(), and video drivers can probe for PCI video boards.

IMHO this is The Right Thing(tm) to do, not only on non-ia32. These days
graphics boards are almost always on PCI (or AGP), so PCI should be initialized
before the console.

Besides, people are already asking how to use e.g. atyfb (a frame buffer device
for ATI Mach64 graphics boards on PPC (CHRP and PowerMac) and m68k (Atari)) on
ia32. This requires PCI probing being available at console initialization time.

> then again, i'm probably being a little bit anal about this, and should
> probably reinsert my foot in my mouth. :)

No problem. If there would be no suspicious people, there would be more kernel
bugs :-)

Greetings,

Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu