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;
}
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
pjmlp 15 hours ago [-]
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.
2 days ago [-]
mrpippy 1 days ago [-]
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 20 hours ago [-]
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)
derefr 1 days ago [-]
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?)
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 17 hours ago [-]
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 2 days ago [-]
How large is the protected memory area? In my experience it's often not zero but some offset from zero that is accessed
TazeTSchnitzel 2 days ago [-]
4GiB
jisnsm 1 days ago [-]
> 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.
vardump 12 hours ago [-]
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.
How things change! Page zero was extremely important on the Apple ][.
nomad41 2 days ago [-]
Very interesting. Can you expand on why? Or point to some relevant sources. Thank you in advance.
0x0 2 days ago [-]
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.
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).
On ARM64, PAGEZERO's size cannot be made smaller than 4 GiB.
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?)
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.
Idk if the xnu kernel will adopt those but it seems most likely.
There is nothing in the standard that says that NULL must be 0.
We don't code for things like PDP-11 or Honeywell mainframes all that often.
https://c-faq.com/null/machexamp.html
See https://www.nesdev.org/obelisk-6502-guide/addressing.html
Edit: Seems good half an hour later!