History of Null Pointer Dereferences on macOS | Hacker News Reader

History of Null Pointer Dereferences on macOS

afine.com

87 pointsvoxadam21 comments

Thanks to the wonders of UB, the sample on the article when compiled with optimization on, it actually reduces to,

   //clang -o null_dereference null_dereference.c
   #include <stdio.h>

   int main() {
      int *ptr = NULL;  // Initialize a pointer to NULL
      int value = *ptr; // Attempt to dereference the NULL pointer 

      printf("Value: %d\n", value); // This line will reached, because the previous will be optimized away.

    return 0;
    }

Example, https://godbolt.org/z/Kv3rcz1ch

What do you mean? There is nothing optimized away. If there would be an if statement to check for a NULL pointer, yes, that most likely would be optimized away due to UB (if something is undefined, it is not NULL, so the check can be removed...). To make it implementation defined, the -fno-delete-null-pointer-checks parameter can be used: https://news.ycombinator.com/item?id=39463804

Look at the generated assembly, only printf remains, the assignments preceding it were removed, thus execution reaches printf and fails elsewhere, not at the point shown on the article.

On macOS x86_64, the size of PAGEZERO cannot be set to 0, but it can be set to 0x1000 (4 KiB) instead of the default 4 GiB. Wine does this to support running Windows EXEs which need to load at a fixed address.

On ARM64, PAGEZERO's size cannot be made smaller than 4 GiB.

The default 4GiB setup is done to very quickly catch poorly written / ported 32-bit code that promotes a 32-bit integer to a pointer. In 64bit mode, such a promotion will create a pointer with the top bits set to zero. Any de-reference of this sort of promotion will cause a SEGFAULT. This might happen if some sort of mixed mode compilation happened for a 64bit process where some of the code was still compiled and linked assuming 32bit mode. (mixed mode Intel code mostly)

> A NULL pointer dereference occurs when software attempts to access memory at address 0 (the NULL address) via a pointer set to NULL.

There is nothing in the standard that says that NULL must be 0.

When's the last time you've seen a non zero NULL pointer?

We don't code for things like PDP-11 or Honeywell mainframes all that often.

https://c-faq.com/null/machexamp.html

Here is a non-zero null pointer: https://gcc.godbolt.org/z/Po5r5Pa36

whats going on here, I dont know enough C++ to understand

We’re covering the history of null pointers on the Mac and not mentioning that in the early days null de-referencing was totally allowed and the system didn’t do anything to stop it? ;)

On a tangent re: memory safety in operating systems —

We hear a lot these days from the (very much in-the-open) debate over how much (if any) of the Linux kernel should be rewritten in Rust for memory safety.

But does anyone know if a similar debate is also going on inside Apple re: XNU/Darwin, or within Microsoft re: NTOS? (Maybe not using Rust in particular, but some other memory-safe systems language?)

Microsoft is hard at work rewriting risky C code into Rust (old presentation mentioned here: https://www.bleepingcomputer.com/news/microsoft/new-windows-...). They're also actively working on things like their Rust framework for Windows drivers.

I don't know about Apple. I'd expect them to go for Swift rather than Rust, but Darwin doesn't seem to include any such code yet.

Linux is full of C developers who don't want anything to do with Rust actively working against the current Rust for Linux experiment. I expect Linux to end up lagging behind Apple and Microsoft in this area because of the difference in organisational structure and priorities.

Apple have both a memory safe dialect of C (called firebloom) and are working on making a subset of Swift for safe, embedded use.

Idk if the xnu kernel will adopt those but it seems most likely.

How large is the protected memory area? In my experience it's often not zero but some offset from zero that is accessed

4GiB

How things change! Page zero was extremely important on the Apple ][.

Very interesting. Can you expand on why? Or point to some relevant sources. Thank you in advance.

Probably because the 6502 CPU had instructions for optimized access to the zero page (first 256 bytes of RAM), this would also apply to C64 and NES etc. If you want to use "Indirect Indexed" memory accesses then I think it also has to go through an address held in the zero page.

See https://www.nesdev.org/obelisk-6502-guide/addressing.html

The AVR architecture puts its registers starting from address 0 of its data memory. As a twist, the program memory also starts at 0 (due to the Harvard architecture).

Hugged to death?

Edit: Seems good half an hour later!

https://archive.ph/p86V1

Reply on news.ycombinator.com