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 296 days 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.
297 days ago [-]
mrpippy 297 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 297 days 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)
jisnsm 297 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 296 days 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.
whats going on here, I dont know enough C++ to understand
296 days ago [-]
dented42 291 days ago [-]
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 297 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 296 days 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 297 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 297 days ago [-]
4GiB
DonHopkins 297 days ago [-]
How things change! Page zero was extremely important on the Apple ][.
nomad41 297 days ago [-]
Very interesting. Can you expand on why? Or point to some relevant sources. Thank you in advance.
0x0 297 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.
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
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.
See https://www.nesdev.org/obelisk-6502-guide/addressing.html
Edit: Seems good half an hour later!