[RFC] Null pointer trap?

[Carl-Daniel Hailfinger]

v3 does not have any mechanism to detect NULL pointers used by accident.

I propose to fill the zero page (0x0-0xfff) with a special POISON_BYTE,
maybe 0x6b. Furthermore, I'd like to make sure passing a NULL pointer
(or something near it) to as a string to printk will be very visible in
the logs.
*(char *)0 = "ERROR NULL POINTER DEREFERENCE!\n";
The C statement above would cause a nice print everytime someone
referenced the first 32 bytes in %s.

Another way to do this is extending the non-NULL check in printk to
cover the whole zero page.

Regards,
Carl-Daniel

[Jordan Crouse]

Carl-Daniel Hailfinger wrote:
> v3 does not have any mechanism to detect NULL pointers used by accident.
>
> I propose to fill the zero page (0x0-0xfff) with a special POISON_BYTE,
> maybe 0x6b.

I'm not sure what problem you are trying to solve here?  Are you trying 
to responsibly catch NULL pointers and report information, or are you 
trying to just be able to identify the situation on a debugger?

Jordan

[Carl-Daniel Hailfinger]

On 07.11.2008 16:04, Jordan Crouse wrote:
> Carl-Daniel Hailfinger wrote:
> > v3 does not have any mechanism to detect NULL pointers used by accident.
> >
> > I propose to fill the zero page (0x0-0xfff) with a special POISON_BYTE,
> > maybe 0x6b.
>
> I'm not sure what problem you are trying to solve here?  Are you
> trying to responsibly catch NULL pointers and report information, or
> are you trying to just be able to identify the situation on a debugger?

Catching NULL pointers immediately and reporting information would be
really cool, but for most hardware I fear that looking at a RAM image
after the fact is the only thing we can do.
You're right, though, this RFC was mostly a monkey-see-problem
monkey-do-something post, intended to get others to offer their insight
on that problem area.

Regards,
Carl-Daniel

[ron minnich]

we can't do this well until we start turning on paging. If you want to
argue that we should poison memory used by coreboot, I'm good with
that.

ron

[Carl-Daniel Hailfinger]

On 07.11.2008 17:15, ron minnich wrote:
> we can't do this well until we start turning on paging.

True.
> If you want to argue that we 
> should poison memory used by coreboot, I'm good with that.

Poisoning as a default-off option will be forthcoming as a patch.
Default off because it will interfere with Suspend-to-RAM. But for other
cases, it may provide valuable hints. For one, it does make stack size
detection a lot more reliable.

Regards,
Carl-Daniel

[ron minnich]

On Fri, Nov 7, 2008 at 8:24 AM, Carl-Daniel Hailfinger
 wrote:
> Poisoning as a default-off option will be forthcoming as a patch.

no, if it is default off and would interfere with suspend to ram,
that's a non starter.

We need a new slogan.

"We're not an OS" :-)

thanks

ron