On Fri, May 7, 2010 at 10:48 AM, Dale Farnsworth <
dale@farnsworth.org>wrote:
> kitepilot wrote:
> [ some code showing that null pointer dereference on Linux results in
> a seg fault, while it just returns 0 on AIX.]
>
> Yes, that is indeed the way it works. On the PDP-11, where much of
> the early (not earliest) UNIX code was written, there was no hardware
> support for separate instruction and data mapping. Code was loaded
> at virtual address 0. On most machines, a null-pointer dereference
> simply loads the contents of address 0. It happened that the first
> byte of crt0.o on the PDP-11 had the value 0. So, on the PDP-11,
> a null pointer dereference returned 0. This resulted in some applications
> dereferencing null pointers and expecting a 0 value and not a seg fault.
> When UNIX was ported to other machines, on some a null pointer dereference
> would seg fault and on others it would return a non-zero value.[1] Both
> of these required additional effort to fix the bug in the original
> application code. However, some of these bugs didn't show up until
> the applications had shipped. Other bugs were in customer code. In
> both cases, customers viewed it as a porting issue. My program didn't
> have any problems when I ran it on PDP-11 UNIX, but it breaks when I
> recompile it and run it on AIX on your hardware.
>
> As a result, IBM modified AIX to return a 0 on a null-pointer in order
> to be bug-compatible with UNIX on a PDP-11. Other vendors did the
> same. On the Motorola 680XX-based systems that I developed UNIX for
> during that timeframe, by default, a null pointer reference would
> seg fault. However, if an otherwise unused bit was set in the executable
> file's header, a null pointer would return 0 as a workaround, so customers
> didn't have to debug their broken programs.
>
> -Dale
>
> [1] I remember an amusing example in the source code to the cpio program
> for System III UNIX, IIRC. The original code had a check for a null
> pointer. Instead of doing:
> if (p != NULL)
> it used
> if (*p != '\0')
> When that code was ported to another machine, that code no longer worked
> and was changed to
> if (*p != '\0' && *p != 'G')
> and that was the way I found the code. Apparently, on the machine to
> which the program had been "ported", a null pointer dereference of a
> (char *) would return the character G instead of 0. Yes, I had a good
> laugh when I found that one.
> ---------------------------------------------------
>
The stuff of a thousand exploits....NULL Deference pointers.
--
Office: (480)307-8707
AT&T: (503)754-4452
Systems Engineer
www.ivedaxpress.com
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)