top | item 43388218

History of Null Pointer Dereferences on macOS

87 points| voxadam | 1 year ago |afine.com | reply

21 comments

order
[+] pjmlp|1 year ago|reply
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
[+] pajko|1 year ago|reply
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
[+] mrpippy|1 year ago|reply
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.

[+] VogonPoetry|1 year ago|reply
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)
[+] jisnsm|1 year ago|reply
> 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.

[+] dented42|1 year ago|reply
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? ;)
[+] derefr|1 year ago|reply
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?)

[+] jeroenhd|1 year ago|reply
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.

[+] dagmx|1 year ago|reply
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.

[+] usrnm|1 year ago|reply
How large is the protected memory area? In my experience it's often not zero but some offset from zero that is accessed
[+] DonHopkins|1 year ago|reply
How things change! Page zero was extremely important on the Apple ][.
[+] nomad41|1 year ago|reply
Very interesting. Can you expand on why? Or point to some relevant sources. Thank you in advance.